[Bug c/30259] New: [4.1 branch] ICE on valid code

[Bug c/30259] New: [4.1 branch] ICE on valid code

[edmar at freescale dot com]

Starting on December 17, the 4.1 branch fails to build for target e500v2.
The comfiguration is:
--target=powerpc-unknown-linux-gnuspe --enable-e500_double

The failure is:
/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-branch_e500v2/./gcc/xgcc
-B/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-
branch_e500v2/./gcc/
-B/temp/gnu_toolchain/install_area/gcc-4_1-branch/gcc-4_1-branch-20061218-e500v2/powerpc-unknown-linux-gnuspe/bin/
-B/temp
/gnu_toolchain/install_area/gcc-4_1-branch/gcc-4_1-branch-20061218-e500v2/powerpc-unknown-linux-gnuspe/lib/
-isystem /temp/gnu_toolchain/instal
l_area/gcc-4_1-branch/gcc-4_1-branch-20061218-e500v2/powerpc-unknown-linux-gnuspe/include
-isystem
/temp/gnu_toolchain/install_area/gcc-4_1-branch/gcc-4_1-branch-20061218-e500v2/powerpc-unknown-linux-gnuspe/sys-include
-O2  -O2 -g -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-string
s -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -specs=ldblspecs -g -DHAVE_GTHR_DEFAULT -DIN_LIBGC
C2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../gcc-4_1-branch/gcc
-I../../gcc-4_1-branch/gcc/ -I../../gcc-4_1-branch/gcc/../include
-I../../gcc-4_1-branch/gcc/../libcpp/include
-I/proj/ppc/sysperf/sw/gnu_toolchain/gcc_support/linuxAMD64/include
-I/proj/ppc/sysperf/sw/gnu_toolchain/gcc_support/linuxAMD64/include -DL_multc3
-c ../../gcc-4_1-branch/gcc/libgcc2.c -o libgcc/./_multc3.o
../../gcc-4_1-branch/gcc/libgcc2.c: In function '__multc3':
../../gcc-4_1-branch/gcc/libgcc2.c:1702: error: unrecognizable insn:
(insn 1229 1228 15 0 ../../gcc-4_1-branch/gcc/libgcc2.c:1643 (set (reg:DF 23 23
[orig:145 d+8 ] [145])
        (mem/c/i:DF (plus:SI (reg/f:SI 1 1)
                (const_int 256 [0x100])) [3 d+8 S8 A32])) -1 (nil)
    (nil))
../../gcc-4_1-branch/gcc/libgcc2.c:1702: internal compiler error: in
extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake[3]: *** [libgcc/./_multc3.o] Error 1
gmake[3]: Leaving directory
`/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-branch_e500v2/gcc'
gmake[2]: *** [stmp-multilib] Error 2
gmake[2]: Leaving directory
`/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-branch_e500v2/gcc'
gmake[1]: *** [all-gcc] Error 2
gmake[1]: Leaving directory
`/temp/gnu_toolchain/build_area/gcc-4_1-branch/obj_gcc-4_1-branch_e500v2'
gmake: *** [all] Error 2


-- 
           Summary: [4.1 branch] ICE on valid code
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: edmar at freescale dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnuspe


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug c/30259] [4.1 branch] ICE on valid code

[joseph at codesourcery dot com]

------- Comment #1 from joseph at codesourcery dot com  2006-12-19 18:16 -------
Subject: Re:   New: [4.1 branch] ICE on valid code

On Tue, 19 Dec 2006, edmar at freescale dot com wrote:

> ./include  -fPIC -specs=ldblspecs -g -DHAVE_GTHR_DEFAULT -DIN_LIBGC

What's in ldblspecs?  If it's built by an unmodified t-ppccomm, and so 
-mlong-double-128 is being passed to cc1, that's never worked for E500 (v1 
or v2) as it would result in a libgcc with undefined references to TFmode 
functions.  I.e., building a functional libgcc for E500 has needed a 
modified t-ppccomm (to avoid passing -mlong-double-128) ever since 4.1, 
and will continue to do so until my long double support patch (now being 
tested for mainline) goes in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug c/30259] [4.1 branch] ICE on valid code

[edmar at freescale dot com]

------- Comment #2 from edmar at freescale dot com  2006-12-19 18:49 -------
Still, On December 16 I had a complete build, and on December 17 I have an ICE.
It feels more like a regression than moving forward...

Edmar


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug c/30259] [4.1 branch] ICE on valid code

[joseph at codesourcery dot com]

------- Comment #3 from joseph at codesourcery dot com  2006-12-19 21:34 -------
Subject: Re:  [4.1 branch] ICE on valid code

On Tue, 19 Dec 2006, edmar at freescale dot com wrote:

> Still, On December 16 I had a complete build, and on December 17 I have an ICE.
> It feels more like a regression than moving forward...

A complete build with, no doubt, all C++ tests failing with the problem 
you noted in <http://gcc.gnu.org/ml/gcc/2006-09/msg00126.html>.  Because 
such a build is not particularly useful, I have taken a base with 
t-ppccomm hacked to avoid building libgcc with -mlong-double-128 as the 
appropriate baseline for testing.

It might be possible to do such a hack more cleanly by changing

ifneq (,$findstring gnu,$(target))
...
endif

to

ifneq (,$findstring gnu,$(target))
ifeq (,$findstring gnuspe,$(target))
...
endif
endif

and this might be appropriate for 4.1 branch to allow a default build to 
complete cleanly.  There may also be a particular bit of my long double 
patch <http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01388.html> that would 
allow libgcc to build (but still be broken) without modifying t-ppccomm; 
in particular, I'd suggest trying the change to 
rs6000_legitimate_offset_address_p.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug target/30259] [4.1 branch] ICE on valid code

[edmar at freescale dot com]

------- Comment #4 from edmar at freescale dot com  2006-12-20 16:11 -------
(In reply to comment #3)
> Subject: Re:  [4.1 branch] ICE on valid code
> 
> On Tue, 19 Dec 2006, edmar at freescale dot com wrote:
> 
> > Still, On December 16 I had a complete build, and on December 17 I have an ICE.
> > It feels more like a regression than moving forward...
> 
> A complete build with, no doubt, all C++ tests failing with the problem 
> you noted in <http://gcc.gnu.org/ml/gcc/2006-09/msg00126.html>.  Because 
> such a build is not particularly useful, I have taken a base with 
> t-ppccomm hacked to avoid building libgcc with -mlong-double-128 as the 
> appropriate baseline for testing.
I disagree with that. First there is the C compiler, which is the most used by
our customers, second, the C++ problem was manageable. Those are dejagnu
results (C, C++, gfortran) from December 12:
# of expected passes            40225
# of unexpected failures        58
# of expected failures          81
# of unresolved testcases       94
# of untested testcases         28
# of unsupported tests          493
# of expected passes            13148
# of unexpected failures        43
# of unexpected successes       2
# of expected failures          65
# of unresolved testcases       40
# of unsupported tests          136
# of expected passes            15334
# of unexpected failures        94
# of expected failures          6
# of unresolved testcases       6
# of unsupported tests          91


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug target/30259] ICE on valid code

[guenter at roeck-us dot net]

------- Comment #5 from guenter at roeck-us dot net  2007-02-04 16:40 -------
Problem is seen with 4.1.2 release candidate. Build is successful with proposed
patch for bug 30270 applied.

Not really my call to make, but it appears that this is neither P3 nor severity
"normal". Also, the status of "unconfirmed" appears to be inappropriate, as the
problem is easy to reproduce.


-- 

guenter at roeck-us dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guenter at roeck-us dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

[Bug target/30259] ICE on valid code

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html