This is a rather strange one. I got a test case via FreeBSD bug 212703 [1], where somebody encountered a clang 3.4.1 segfault, compiling some sample from openMVG [2]. This segfault is actually the assertion "(Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg", and it even reproduces with trunk r281149. For some reason, the build process targets x86_64, but then turns off SSE2, and this is the key to getting the assertion. The test case is extremely minimal, and optimization isn't even required: // compile with: clang -cc1 -triple x86_64 -S -target-feature -sse2 testcase.cpp void fn1(double); int main() { fn1(4.); } As far as I know, disabling SSE2 also disables all the higher forms of SSE, so I think it just can't find any x87 FP register at all, in this case? [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212703 [2] https://github.com/openMVG/openMVG
Duplicate of [Bug #10498]?
Is x86-64 without sse2 a configuration we try to support? As far as I know, x86-64 implies sse2 (and the x86-64 System V ABI certainly does).
(In reply to comment #2) > Is x86-64 without sse2 a configuration we try to support? Maybe not, though it would be better to simply refuse the -mno-sse and -mno-sse2 options on the command line then. > As far as I know, x86-64 implies sse2 (and the x86-64 System V ABI certainly > does). Could it just fall back to x87 floating point? Maybe that was the expectation in openMVG... Though reading its CMake files, it appears that it may simply fail to detect SSE2 properly, and then tries to disable it.
(In reply to comment #1) > Duplicate of [Bug #10498]? Yeah, it looks quite a bit like it; maybe the call to fn1() uses SSE registers, while the function itself expects x87 FP registers, or something like that.
(In reply to comment #3) > (In reply to comment #2) > > Is x86-64 without sse2 a configuration we try to support? > > Maybe not, though it would be better to simply refuse the -mno-sse and > -mno-sse2 options on the command line then. That's what I meant. > > > As far as I know, x86-64 implies sse2 (and the x86-64 System V ABI certainly > > does). > > Could it just fall back to x87 floating point? Not really. It could for computation, but not for the ABI - if the calling convention mandates returning in xmm0, there's no real fallback that makes sense. GCC appears to actually make this distinction, so it will only refuse to compile when it sees an actual ABI problem. So, say: float square(float f) { return f * f; } When built with GCC for x86-64 with -mno-sse, errors with: "SSE register return with SSE disabled". GCC is, however, perfectly willing to compile it with only SSE2 disabled.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > Is x86-64 without sse2 a configuration we try to support? > > > > Maybe not, though it would be better to simply refuse the -mno-sse and > > -mno-sse2 options on the command line then. > > That's what I meant. Let's do that. Users seem to keep bumping into impossibilities in x86_64 -mno-sse[2], and then clang asks them to file a bug report.
Maybe this can help: https://reviews.llvm.org/D27522.
(In reply to Francis Visoiu Mistrih from comment #7) > Maybe this can help: https://reviews.llvm.org/D27522. I landed a modified version of this patch. However, it's still possible to hit this assertion, so the issue is not fixed.
(In reply to Reid Kleckner from comment #8) > (In reply to Francis Visoiu Mistrih from comment #7) > > Maybe this can help: https://reviews.llvm.org/D27522. > > I landed a modified version of this patch. However, it's still possible to > hit this assertion, so the issue is not fixed. Reid, any ideas what kind of situation can still trigger that?
(In reply to Dimitry Andric from comment #9) > (In reply to Reid Kleckner from comment #8) > > (In reply to Francis Visoiu Mistrih from comment #7) > > > Maybe this can help: https://reviews.llvm.org/D27522. > > > > I landed a modified version of this patch. However, it's still possible to > > hit this assertion, so the issue is not fixed. > > Reid, any ideas what kind of situation can still trigger that? This test case was part of r302835, the revision that I forgot to note: +void take_double(double); +void pass_double(void) { + // FIXME: Still asserts. + //take_double(1.5); +}
(In reply to Dimitry Andric from comment #9) > (In reply to Reid Kleckner from comment #8) > > (In reply to Francis Visoiu Mistrih from comment #7) > > > Maybe this can help: https://reviews.llvm.org/D27522. > > > > I landed a modified version of this patch. However, it's still possible to > > hit this assertion, so the issue is not fixed. > > Reid, any ideas what kind of situation can still trigger that? The test case attached to https://bugs.llvm.org/show_bug.cgi?id=10498 still hits this assertion with trunk (r353878).
*** Bug 37067 has been marked as a duplicate of this bug. ***
*** Bug 48803 has been marked as a duplicate of this bug. ***
*** Bug 51468 has been marked as a duplicate of this bug. ***
We recently hit this assertion when investigating an issue internally when compiling with following code with -mno-sse2: void foo(...) { foo(4.0); }