[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

2018-10-26 Thread davidegrayson at gmail dot com
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

2018-10-31 Thread davidegrayson at gmail dot com
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

2018-10-31 Thread davidegrayson at gmail dot com
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'

2017-08-14 Thread davidegrayson at gmail dot com
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.