Bootstrap started failing on 32-bit libjava build at r228022.
/home/pthaugen/src/gcc/trunk/gcc/configure --prefix=/home/pthaugen/install/gcc/trunk --enable-decimal-float --enable-lto --with-as=/opt/at8.0/bin/as --with-ld=/opt/at8.0/bin/ld --without-ppl --without-cloog --disable-libsanitizer --enable-languages=c,java --disable-bootstrap --with-cpu=power8
Failing portion of make cmd:
[pthaugen@tul80p1 libjava]$ pwd
[pthaugen@tul80p1 libjava]$ /home/pthaugen/work/build/gcc/trunk/./gcc/gcj -B/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/pthaugen/work/build/gcc/trunk/./gcc/ -B/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/bin/ -B/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/lib/ -isystem /home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/include -isystem /home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/sys-include -m32 -fclasspath= -fbootclasspath=/home/pthaugen/src/gcc/trunk/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/classpath/lib/classes -MT java/lang.lo -MD -MP -MF java/lang.deps @java/lang.list -fPIC -o java/.libs/lang.o -save-temps
ccWB6wRZjx.s: Assembler messages:
ccWB6wRZjx.s:18368: Error: symbol `.LCF369' is already defined
Adding -fno-shrink-wrap fixes the error. Appears the prolog is getting duplicated.
Most likely the same issue as PR67788.
I see similar failures, except it is in building the 32-bit module fpu.o in the libgfortran library on a 64-bit big endian power7 box. It is failing in building the 32-bit libraries. This is not seen in building little endian power8, since that system no longer does not have 32-bit support.
I believe the issue is the prologue for -fpic/-fPIC is not expecting the prologue to be cloned. It sets up the TOC address by calling to a label and then adjusting the address to get the TOC pointer. The label is created multiple times when the blocks are re-ordered. If -fno-reorder-blocks is given, it does not clone the label definition.
As I see it, there are several ways to solve this problem:
1) Simply disable shrink-wrapping/reorder-blocks if V.4 pic. This is probably just papering over the problem.
2) Add a target hook so the backend can say whether or not a particular function's prologue can be split. The static function in rs6000.c uses_TOC would return true if it shouldn't be split.
3) Recognize in shrink-wrap if labels are created in the prologue, and don't shrink wrap them.
Yes, it looks like my issue is the one raised by PR67788, so I imagine they are the same issue.
Here is the function that shows the error when compiled with -fPIC:
set_fpu_rounding_mode (int mode)
rnd_mode = FE_TONEAREST;
rnd_mode = FE_UPWARD;
rnd_mode = FE_DOWNWARD;
rnd_mode = FE_TOWARDZERO;
Date: Fri Oct 2 01:29:26 2015
New Revision: 228366
rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)
After the shrink-wrapping patches the prologue will often be pushed
"deeper" into the function, which in turn means the software trace cache
pass will more often want to duplicate the basic block containing the
prologue. This caused failures for 32-bit SVR4 with -msecure-plt PIC.
This configuration uses the load_toc_v4_PIC_1 instruction, which creates
assembler labels without using the normal machinery for that. If now
the compiler decides to duplicate the insn, it will emit the same label
It isn't so easy to fix this to use labels the compiler knows about (let
alone test that properly). Instead, this patch wires up a "cannot_copy"
attribute to be used by TARGET_CANNOT_COPY_P, and sets that attribute on
these insns we do not want copied.
2015-10-01 Segher Boessenkool <email@example.com>
* config/rs6000/rs6000.c (TARGET_CANNOT_COPY_INSN_P): New.
(rs6000_cannot_copy_insn_p): New function.
* config/rs6000/rs6000.md (cannot_copy): New attribute.
(load_toc_v4_PIC_1_normal): Set cannot_copy.
* gcc.target/powerpc/pr67789.c: New testcase.