fatal error: error in backend: Stack overflow!

[llvmbot]

Bugzilla Link	15933
Version	trunk
OS	Linux
Attachments	Crash backtrace, preprocessed source, and associated run script. (Part 1), Crash backtrace, preprocessed source, and associated run script. (Part 2)
Reporter	LLVM Bugzilla Contributor

Extended Description

When compiling one of my libraries for the first time with clang, I stumbled across an internal compiler error.

I attached the preprocessed source(s) and associated run script(s), as well as the error trace.

My system is:

• Arch Linux, x86_64, running kernel 3.8.4-1
• $ clang --version
  clang version 3.2 (tags/RELEASE_32/final)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix

[llvmbot]

I tested the same code with clang's trunk version (3.3) and it is still present.

[Endilll]

We emit an error instead of crashing since Clang 10, but I'm not sure whether this addresses the root of the issue: https://godbolt.org/z/b7djE16Gq

example.cpp:12:16: error: SSE2 register return with SSE2 disabled
  cstr.value = atof();
               ^
1 error generated.

Reduced by C-Reduce:

class basic_string {
public:
  ~basic_string();
};
double atof();
struct InferiorConstraint {
  int value;
  basic_string name;
};
void stringToInferiorConstraint() {
  InferiorConstraint cstr;
  cstr.value = atof();
}

[llvmbot]

@llvm/issue-subscribers-backend-x86

[AaronBallman]

A smaller reproducer is:

double atof();
void func() {
  int i = atof();
}

https://godbolt.org/z/EjP93EMzj

This code should still compile even with sse2 disabled.

CC @topperc

[phoebewang]

The floating point arguments can only be passed/returned through SSE registers according to 64-bit ABI. So this is not compiler issue but a misuse.

[Endilll]

Which means the diagnostic we issue since 10 is spot-on. Thank you!

[AaronBallman]

Hmmm, it'd be nicer if we diagnosed this with a more actionable diagnostic; the current diagnostic wording is problematic because it doesn't help the user to correct the issue, it just says "we're doing a thing" with no indication of the actual issue.

However, why does -mno-sse2 imply no SSE registers? GCC doesn't complain: https://godbolt.org/z/nYcMoKKbe at least until you disable SSE entirely (https://godbolt.org/z/jsETnK6Gr) Even more interestingly, we don't complain about use of xmm0 with SSE3 disabled: https://godbolt.org/z/4ardjWYh8 So, I think this might be a bug -- I think -mno-sse2 should only disable SSE2 extensions and the use of xmm0 is fine unless passing -mno-sse. CC @phoebewang

[Endilll]

I agree that there is a room for improvement for wording. It didn't make much sense to me until @phoebewang explained, even though I have high-level understanding of calling conventions and SSE.

[Endilll]

#23119 is an example why users might want to disable SSE on x86_64 (FP arithmetic differences).

[phoebewang]

However, why does -mno-sse2 imply no SSE registers?

Because double instructions are supported on SSE2 and above. It's arguable if we can pass double with SSE. Anyway, I don't think we need to special handle for this since there's rare case user has SSE but no SSE2 nowadays.

we don't complain about use of xmm0 with SSE3 disabled

It's not a bug. 64-bit system will enable SSE2 by default. Disable SSE3 won't affect SSE2.

[AaronBallman]

However, why does -mno-sse2 imply no SSE registers?

Because double instructions are supported on SSE2 and above. It's arguable if we can pass double with SSE. Anyway, I don't think we need to special handle for this since there's rare case user has SSE but no SSE2 nowadays.

It seems that GCC handles this code appropriately; better than Clang does (IMO). Given how many bug reports we have around -mno-sse2 behavior with function returns, making this a nonconforming language dialect, are you arguing that we should remove support for -mno-sse2 because users don't need to use it?

we don't complain about use of xmm0 with SSE3 disabled

It's not a bug. 64-bit system will enable SSE2 by default. Disable SSE3 won't affect SSE2.

Ah! So SSE3 does not imply SSE2? I wasn't aware of that (I thought these accumulated the extensions).

[topperc]

Ah! So SSE3 does not imply SSE2? I wasn't aware of that (I thought these accumulated the extensions).

-msse3 implies -msse2
-mno-sse2 implies -mno-sse3

Phoebe was saying you can disable sse3 and leave sse2 enabled.

[jyknight]

I think emitting an error if you use -mno-sse2 and attempt to pass or return a double is entirely reasonable. Really, nobody should be doing that, and spending a bunch of effort on making it work better doesn't seem warranted. Of course the compiler shouldn't crash, though: if we fail to emit an error in some cases today, we should fix that by emitting the proper error.

I'd also note that GCC actually silently switches to a non-standard argument-passing ABI if you use -mno-sse on x86-64, which seems like a bad idea. (It emits an error for returns only.)

[AaronBallman]

Thanks for the discussion (here and on IRC)! I see now that this option is needed for kernels, where the current nonconforming behavior is reasonable so long as we emit an error instead of crashing (which we do). It's unfortunate that it's not a conforming mode, but oh well, not the end of the world -- it suits the needs of the folks who need the option.

[Endilll]

Related: #29774