Open Quuxplusone opened 7 years ago
Bugzilla Link | PR30426 |
Status | CONFIRMED |
Importance | P normal |
Reported by | Dimitry Andric (dimitry@andric.com) |
Reported on | 2016-09-17 06:44:05 -0700 |
Last modified on | 2021-11-01 17:31:48 -0700 |
Version | trunk |
Hardware | PC All |
CC | clang@evan.coeusgroup.com, coby.tayree@intel.com, douglas_yung@playstation.sony.com, emaste@freebsd.org, francisvm@yahoo.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, marina.yatsina@intel.com, mkuper@google.com, pengfei.wang@intel.com, rnk@google.com, spatel+llvm@rotateright.com, tstellar@redhat.com, yuri@tsoft.com, ziv.izhar@intel.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also | PR10498, PR22745, PR25260, PR25415, PR25823, PR26539, PR30503, PR32832, PR33004, PR41668 |
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); }