Bug 67789 - Bootstrap failure with java starting at rev 228022
Summary: Bootstrap failure with java starting at rev 228022
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on: 67788
  Show dependency treegraph
Reported: 2015-09-30 18:26 UTC by Pat Haugen
Modified: 2015-10-02 06:01 UTC (History)
4 users (show)

See Also:
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
Build: powerpc64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Pat Haugen 2015-09-30 18:26:01 UTC
Bootstrap started failing on 32-bit libjava build at r228022.

Configured as:

/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.
Comment 1 Andrew Pinski 2015-09-30 18:32:55 UTC
Most likely the same issue as PR67788.
Comment 2 Michael Meissner 2015-09-30 18:36:02 UTC
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.
Comment 3 Michael Meissner 2015-09-30 18:37:22 UTC
Yes, it looks like my issue is the one raised by PR67788, so I imagine they are the same issue.
Comment 4 Michael Meissner 2015-09-30 19:11:25 UTC
Here is the function that shows the error when compiled with -fPIC:

set_fpu_rounding_mode (int mode)
  int rnd_mode;

  switch (mode)
      case 2:
       rnd_mode = FE_TONEAREST;

      case 4:
        rnd_mode = FE_UPWARD;

      case 1:
        rnd_mode = FE_DOWNWARD;

      case 3:
        rnd_mode = FE_TOWARDZERO; 


  fesetround (rnd_mode);
Comment 5 Segher Boessenkool 2015-10-02 01:29:58 UTC
Author: segher
Date: Fri Oct  2 01:29:26 2015
New Revision: 228366

URL: https://gcc.gnu.org/viewcvs?rev=228366&root=gcc&view=rev
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
twice.  Boom.

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  <segher@kernel.crashing.org>

	PR target/67788
	PR target/67789
	* 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.
	(load_toc_v4_PIC_1_476): Ditto.

	PR target/67788
	PR target/67789
	* gcc.target/powerpc/pr67789.c: New testcase.

Comment 6 Segher Boessenkool 2015-10-02 06:01:01 UTC