[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 David Grayson changed: What|Removed |Added CC||davidegrayson at gmail dot com --- Comment #14 from David Grayson --- To recap: there is an internal compiler error in ix86_compute_frame_layout when using rdrnd, C++, noexcept, and i686-w64-mingw32. And it probably affects x86_64-w64-mingw32 too, but I am most interested in the i686 case so I will focus on that. Here is a minimal test case the reproduces the issue: __attribute__((__target__("rdrnd"))) void f(unsigned int * b) noexcept { __builtin_ia32_rdrand32_step(b); } Here are some workarounds I found: 1) Remove the "noexcept" specifier from the function. 2) Don't use the rdrand built-ins. 3) Compile the function as C code. 4) I'm not sure if this is safe, but you can use the compiler option -mpreferred-stack-boundary=2, which tells GCC to prefer 4-aligning the stack. I am running GCC as a cross-compiler on Linux, targeting i686-w64-mingw32. I have seen this bug in GCC 7.3.0, 8.2.0, and the 8-20181019 snapshot. For the remainder of this bug report, I will just focus on the behavior of the 8-20181019 snapshot. Here is the command I use to compile the program above, and the full output of the compiler: $ ../prefix/bin/i686-w64-mingw32-g++ -c ../david.cpp during RTL pass: ira ../david.cpp: In function 'void f(unsigned int*)': ../david.cpp:3:1: internal compiler error: in ix86_compute_frame_layout, at config/i386/i386.c:11734 } ^ 0xe0b414 ix86_compute_frame_layout ../../gcc-8-20181019/gcc/config/i386/i386.c:11734 0xaf65ed set_initial_elim_offsets ../../gcc-8-20181019/gcc/reload1.c:3858 0xb0131f calculate_elim_costs_all_insns() ../../gcc-8-20181019/gcc/reload1.c:1562 0x9e536f ira_costs() ../../gcc-8-20181019/gcc/ira-costs.c:2249 0x9decc6 ira_build() ../../gcc-8-20181019/gcc/ira-build.c:3427 0x9d64e3 ira ../../gcc-8-20181019/gcc/ira.c:5295 0x9d64e3 execute ../../gcc-8-20181019/gcc/ira.c:5606 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The assertion that is failing in ix86_compute_frame_layout (i386.c, line 11734) is this one: gcc_assert (preferred_alignment <= stack_alignment_needed); By adding my own fprintf statement, I determined that in the problematic case we have: - preferred_alignment is 16 - stack_alignment_needed is 4 I did some experiments and I found that the problematic case (using an rdrand intrinsic in a noexcept C++ function) seems to be the only case where the preferred_alignment variable is affected by the -mpreferred-stack-boundary command-line option. In every other case, preferred_alignment is always just 4. Isn't that weird? Just looking at variable names, I would expect -mpreferred-stack-boundary to always affect crtl->preferred_stack_boundary and crtl->stack_alignment_needed (which are where the values in the assertion above come from). My guess is that someone decided to force the preferred_stack_boundary and stack_alignment_needed to 4 on Windows for some reason, and they succeeded in doing that for most cases, but they failed to do it for the rdrand/C++/noexcept case. Does anyone have an idea of how to fix this bug for real? What values should crtl->preferred_stack_boundary crtl->stack_alignment_needed really have on Windows, and should they be controllable from the command-line? Where do they get set? --David
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #27 from David Grayson --- Thanks to everyone who is working on this. I can confirm that the patch in comment #20 by Uroš Bizjak applies cleanly to GCC 7.3.0, and I successfully used the resulting toolchain targeting i686-w64-mingw32 to build Qt and several Qt GUI examples, all of which run correctly. Just in case it helps you find more bugs: I noticed there are several other places in the code (of gcc-8-20181019) where ctrl->preferred_stack_boundary gets updated without any obvious update of ctrl->stack_alignment_needed: gcc/explow.c:1247 in get_dynamic_stack_size gcc/explow.c:1595 in get_dynamic_stack_base gcc/calls.c:3811 in expand_call gcc/config/i386/i386.c:12593 in ix86_update_stack_boundary
[Bug c++/58372] internal compiler error: ix86_compute_frame_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372 --- Comment #33 from David Grayson --- Hello, Terry. I'd be happy to help. I hope you have access to a Linux computer. I've actually spent a lot of time working on build scripts for cross-compilers running on Linux and here's what I have come up with for you: https://gist.github.com/DavidEGrayson/d5ca447cca1ea23d5adca2f353dbb67a
[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31798 David Grayson changed: What|Removed |Added CC||davidegrayson at gmail dot com --- Comment #5 from David Grayson --- This bug is still present, at least in GCC 6.3.0. I have not tried a newer version. == Workarounds == For any GCC users getting an undefined reference error for "raise", you should try providing the "-static" option to GCC when you link your program. Alternatively, if you are compiling GCC yourself, you should find the definition of LINK_GCC_C_SEQUENCE_SPEC in GCC's source code and change it to be this: --start-group %G %L --end-group In my case, I am building a GCC 6.3.0 cross-compiler to target musl Linux, and the definition I had to change was in "gcc/config/gnu-user.h". You can see my build scripts here if you are interested in using GCC to build static programs targeting Windows and Linux: https://github.com/DavidEGrayson/nixcrpkgs == Comments == Thank you for diagnosing this correctly, Rich Felker. Also, your musl-cross-make project was useful to me. The core problem here is that LINK_GCC_C_SEQUENCE_SPEC is sometimes defined like this: %{static:--start-group} %G %L %{static:--end-group}%{!static:%G} You can run "gcc -dumpspecs" and look for "link_gcc_c_sequence" to see how it was defined in your version of GCC. The %G basically stands for "-lgcc" and the %L basically stands for "-lc". The problem with that line is that it is confusing two different concepts: A) The program is being linked with "-static". B) The libc and GCC libraries used by the program are static. A implies B, but B does not imply A. I am using GCC to build static applications so I don't have a shared version of libc or the GCC libraries, and I want my programs to compile and link correctly even if the "-static" argument is not supplied. Why was this marked as "WORKSFORME", which is defined in by this bug tracker to be "All attempts at reproducing this bug were futile, and ..."? From the conversation here it sure seems like there was no attempt to understand the configuration of the original poster's GCC and system libraries and actually reproduce the issue. If anyone wants help reproducing this issue, I can easily show you how to do it using my build scripts from the nixcrpkgs project. One of the advantages of Nix is that it's great for expressing how to build software and compositions of software in a reliable and predictable way, so if you have a Linux system you can just run a few commands and get the exact same error I was getting when I tried to build a "hello world" program for the Raspberry Pi.