-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[X86] No support for fp stack in inline asm #1251
Comments
Can you please attach a ".i" file, generated according to these instructions: Thanks, -Chris |
Crashes llvm-gcc |
Here is a reduced testcase: double floor(double __x) { Basically this boils down to the fact that we don't support "t" constraints (fp stack) in inline asms. Unfortunately, I don't plan to implement this support in the near future, however, as a work-around, -Chris |
Here's a testcase from redhat FC5 headers: double %intcoord(double %X) { It would be good to support the simple case of this at least. -Chris |
This patch: |
*** Bug #1243 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#921 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#937 has been marked as a duplicate of this bug. *** |
Another simple testcase from Qt: inline double qCos_x86(double a) |
Here are some testcases: double floor(double __x) { // This has two inputs and pops one. register char __result; Unfortunately, this won't happen for 1.9. -Chris |
*** Bug llvm/llvm-bugzilla-archive#1051 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#1211 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#1272 has been marked as a duplicate of this bug. *** |
akor, could you try adding something like this to i386.h: builtin_assert("__NO_MATH_INLINES"); Somewhere in TARGET_CPU_CPP_BUILTINS. This should eliminate the worst part of this problem until we |
s/builtin_assert/builtin_define, sorry. |
Ok. Will try. |
I'm ok with the following patch: diff -r 4fe28e061ca4 gcc/config/i386/i386.h
#define TARGET_CPU_DEFAULT_i386 0 Btw, is it ok, that apple-related parts uses tabs for indentation? |
Thanks Anton, applied: I think this should significantly reduce the pain of this bug for linux users. |
Simple asms like that in Comment #9 now work: _qCos_x86: |
|
There are a bunch more examples here: |
'f' now works. 'u' doesn't. 't' does, but probably not in combination with 'f' yet. Slow progress. |
*** Bug llvm/llvm-bugzilla-archive#2901 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#3582 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#3690 has been marked as a duplicate of this bug. *** |
We at FreeBSD see the following crash when building our C library on i386: Assertion failed: (StackTop == 0 && "Stack should be empty after a call!"), function handleSpecialFP, file .../llvm/lib/Target/X86/X86FloatingPoint.cpp, line 952. Reduced testcase: double
} |
is there some progress on this? it seems to block quite a few projects |
No progress. :-( All the Apply guys are crazy busy with other projects. I don't know if there are folks in the community who are working on this. Is there a way to work around this at the source level? |
|
aKor says it might just work to turn 'u' to %st(1) in the frontend (clang). info gcc says this:
|
*** Bug llvm/llvm-bugzilla-archive#5505 has been marked as a duplicate of this bug. *** |
*** Bug llvm/llvm-bugzilla-archive#6252 has been marked as a duplicate of this bug. *** |
Just a comment on the FreeBSD build dependency. I can find two uses of "u" in the FreeBSD source tree: src/lib/libc/amd64/gen/ldexp.c:55: __asm ("fscale "
|
It's seems I can compile these code using clang 1.1 and llvm 2.7. the result assembly code is
ldexp:
Is that means this bug is fixed? |
The ldexp testcase works at >=-O1 but sill fails at -O0, clang r108078. |
Reverified. Jakob's work on the stackifier fixed at least one of these, but we still get some assertions, such as: Assertion failed: (RegMap[RegOnTop] < StackTop), function moveToTop, file X86FloatingPoint.cpp, line 200. |
To summarize the current state:
|
I received a small piece of sample code (basically a rint() function) int irint(double x) gcc produces: irint: while clang produces: irint: E.g, it loads the argument on the fp stack (fldl 8(%ebp)), but does not |
Fixed in r134018 Chris' tests now produce: _floor: ## @floor BB#0: ## %entry
_test: ## @test BB#0: ## %entry
_test2: ## @test2 BB#0: ## %entry
Roman's ldexp: _ldexp: ## @ldexp BB#0: ## %entry
Dimitry: _irint: ## @irint BB#0: ## %entry
|
Fantastic Jakob! |
mentioned in issue llvm/llvm-bugzilla-archive#937 |
Extended Description
Hi there,
I was compiling lame-3.95.1 with the new tar file llvm-1.8a.tar.gz and
llvm-gcc4-1.8-source on Fedora Core 5. I wanted to check some timings for .wav
to .mp3 encoding.
The lame package compiles fine using llvm-gcc and -O0 but it dies using -O3
(which is the default opt level in the makefile). Gcc 4.0.3 works fine with all
opt levels. Llvm-gcc dies on all opt levels, except -0O.
The compilation goes through the mpglib subdirectory fine but it dies in the
libmp3lame subdirectory with the following:
snip....
llvm-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I. -I../mpglib/ -I.. -Wall
-pipe -O3 -MT VbrTag.lo -MD -MP -MF .deps/VbrTag.Tpo -c VbrTag.c -fPIC -DPIC -o
.libs/VbrTag.o
VbrTag.c: In function 'PutLameVBR':
VbrTag.c:772: warning: pointer targets in passing argument 1 of
'__builtin_strncpy' differ in signedness
VbrTag.c: In function 'PutVbrTag':
VbrTag.c:1000: warning: pointer targets in passing argument 2 of
'CRC_writeheader' differ in signedness
cc1: SelectionDAGISel.cpp:2142: void
llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&): Assertion
`!Regs.Regs.empty() && "Couldn't allocate output reg!"' failed.
VbrTag.c: At top level:
VbrTag.c:1030: internal compiler error: Aborted
snip...
I don't know enough about llvm at present, to offer an intelligent guess as to
why this is happening. Sorry ;)
Lame source can be downloaded here:
http://prdownloads.sourceforge.net/lame/lame-3.95.1.tar.gz
Thanks,
Kelly
The text was updated successfully, but these errors were encountered: