User account creation filtered due to spam.
Building gcc for powerpc-eabispe target on mainline (combined tree):
../combined/configure --target=powerpc-eabispe --enable-languages=c,c++,objc
./xgcc -B./ -B/usr/local/powerpc-eabispe/bin/ -isystem /usr/local/powerpc-eabispe/include -
isystem /usr/local/powerpc-eabispe/sys-include -L/home/dara/mainline/objdir/gcc/../ld -O2 -
DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../../combined/gcc -I../../combined/gcc/. -I../../combined/gcc/config -I../../combined/gcc/
../include -DL_divdi3 -c ../../combined/gcc/libgcc2.c -fexceptions -fnon-call-exceptions -o
../../combined/gcc/libgcc2.c: In function `__divdi3':
../../combined/gcc/libgcc2.c:1066: internal compiler error: in ccr_bit, at config/rs6000/
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make: *** [libgcc/./_divdi3.o] Error 1
make: Leaving directory `/home/dara/mainline/objdir/gcc'
make: *** [stmp-multilib] Error 2
The testcase does not ICE if -O1 or lower is specified.
Created attachment 4638 [details]
fails with cross cc1 to powerpc-easbispe with -O2 or higher optimization.
I think this is a regression from 3.3.
Created attachment 4774 [details]
Since Zdenek reduced this, I am marking as confirmed.
The regression in PR 12028 was introduced or exposed by this patch:
--- gcc/gcc/ChangeLog ---
2003-05-03 Geoffrey Keating <firstname.lastname@example.org>
* config/rs6000/rs6000.c (scc_comparison_operator): Make equivalent
(ccr_bit): Check that sCOND conditions are actually a positive bit.
(print_operand): Remove %D substitution.
(rs6000_emit_sCOND): Generate complement operation to ensure that
sCOND input is a positive bit.
* config/rs6000/rs6000.md: Rearrange sCOND templates to be in the
same order as bCOND, and add the missing ones. Remove the %D
substitutions from the scc patterns.
* simplify-rtx.c (simplify_relational_operation): Add case for
! (fabs(x) < 0.0).
The regression hunt took place on i686-pc-linux-gnu with a cross compiler
for powerpc-eabispe, using the reduced test case from comment #3 with -O2.
The problem is part of the patch:
/* When generating a sCOND operation, only positive conditions are
if (scc_p && code != EQ && code != GT && code != LT && code != UNORDERED
&& code != GTU && code != LTU)
Down below that, there is case for NE (which is the code at this point).
Subject: Re: [3.4 Regression] powerpc-eabispe: ICE building __divdi3.o: in ccr_bit, at config/rs6000/rs6000.c:8136
"pinskia at gcc dot gnu dot org" <email@example.com> writes:
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2003-11-09 21:41 -------
> The problem is part of the patch:
> /* When generating a sCOND operation, only positive conditions are
> allowed. */
> if (scc_p && code != EQ && code != GT && code != LT && code != UNORDERED
> && code != GTU && code != LTU)
> abort ();
> Down below that, there is case for NE (which is the code at this point).
The check is clearly correct. In the SPE case, both 'EQ' and 'NE' are
'base_bit + 1', but for a sCOND operation the bit must be set when the
condition is true, and EQ and NE are mutually exclusive. So the
problem must be somewhere else, and removing the check would only
guarantee bad code generation.
This was caused by your patch are you going to fix it?
Subject: Bug 12028
Module name: gcc
Changes by: firstname.lastname@example.org 2004-02-10 03:45:04
gcc : ChangeLog
* config/rs6000/rs6000.c (ccr_bit): Don't let consistency check
failure stop compilation, just print helpful message.
The previous patch suppresses the build failure on the 3.4 branch. However, the underlying problem is
still there. I believe it has been there since the e500 port was added.
Should be fixed in 3.5.0 by Aldy's rewrite.
Fixed on 3.4 branch by http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01926.html