This shows up on both powerpc-linux-gnu and powerpc-darwin.  Confirmed because it shows up in many different testresults.

*** Bug 33277 has been marked as a duplicate of this bug. ***

Well here it is for interfering with Mr Guenther doing the reasonable thing. This arbitrariness and unwarranted interference  led me to do this.

It is also interesting to look a the GCC.mailing.list for June and July to realize what is really going on within GCC

Mr. Mark Mitchell was overruled on his  misgivings regarding the status of gcc-4.2.0 . Hence gcc-4.2.0 is not really serviceable and can not even compile glibc on some architectures. The linux distributors are staying away from gcc-4.2.0 save for SUSE.  However,  SUSE  made it impossible to find out readily  which gcc version compiled their executables and libraries. Thus a statement that their latest available beta or release candidate compiler is gcc-4.2.x is not verifiable.

What follows is a verbatim  copy of PR33271 tentatively suppressed by Mr. Pinski, who appears to be a protege of Dr. Edelsohn.


The summary results are pretty obvious:

FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O1  (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -O3 -g  (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation,  -Os  (internal compiler
error)
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)

This are  __not__ the mayalias  failures which continue to fail with 4.3.0 and
are __not__
marked XFAIL

There is only on category, namely rs6000, both in the config tree and in the
MAINTAINERS LIST, so do expect the submitters to devine  any other name dujour.

Also if the supposedly scarce manpower available  can process hundreds of
pretty irrelevant GPL3 and whitespace elimination patches ( even for an already
released 4.2.x series) then submitters should not be harassed about submitting 
superfluous details.

GPL3 has been dismissed by the world. Just look at the trade press, slashdot,
dig, and others.

There is neither adequate management for the steering committee down nor other
than lip-service to quality control. This and recent submissions by the
Debian-gcc-team prove the point.

Just to gild the lily here goes:

#include <stdlib.h>
f (x)
     unsigned x;
{
  return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1;
}

main ()
{
  unsigned i;

  for (i = 0; i < 10000; i++)
    if (f (i) != i / 3)
      abort ();
  exit (0);
}


Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,fortran,c++ --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070901 (experimental) (GCC) 
 /usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
-Asystem=unix -Asystem=posix 930921-1.c -quiet -dumpbase 930921-1.c -mcpu=G4
-auxbase 930921-1 -O1 -version -o /tmp/ccCd2Hre.s
ignoring nonexistent directory
"/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/libffi
 /usr/local/include
 /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
 /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
 /usr/include
End of search list.
GNU C (GCC) version 4.3.0 20070901 (experimental) (powerpc-unknown-linux-gnu)
        compiled by GNU C version 4.3.0 20070901 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fe13efd375927cd9d7414827707b954b
930921-1.c: In function 'f':
930921-1.c:6: error: could not split insn
(insn 6 3 31 930921-1.c:4 (set (reg:SI 0 0 [123])
        (const_int 2863311531 [0xaaaaaaab])) 265 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 2863311531 [0xaaaaaaab])
        (nil)))
930921-1.c:6: internal compiler error: in final_scan_insn, at final.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


------- Comment #1 From Andrew Pinski 2007-09-02 11:36 [reply] -------

I saw this also asn asked about it on IRC.  Note please don't CC anyone unless
you know that they caused the bug.  They don't want to be getting all bug
reports.


------- Comment #2 From Andrew Pinski 2007-09-02 11:41 [reply] -------

[18:22] < apinski> 
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] < apinski> new failure
[18:23] < apinski> on ppc-linux-gnu
[18:23] < apinski> between 127935 and 128000

>GPL3 has been dismissed by the world.

WTF does this have to do with 930921-1.c ICE????  I am seriously thinking about
ignoring all the bug reports from you from now on because of this crap.  GCC is
owned (copyrighted) by the FSF and GPLv3 is th official license from them and
they get to decide on the license not us, we can influence somewhat but they
are the official word.


>This and recent submissions by the Debian-gcc-team prove the point.

You know, there are many different targets that GCC supports, sometimes the
patch does not cause any regression on one target can cause regressions on
others.  This happens all the time.  You need to understand the main reason why
we have the testsuite is so we easily see when a target has a regression or
not.  Now if you want to report bugs, please do so without this extra crap
because it gets in the way of actually fixing it and it makes people think you
are crazy and should not be listened to.


------- Comment #3 From Dominique d'Humieres 2007-09-02 13:42 [reply] -------

> [18:23] < apinski> between 127935 and 128000

Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
"regress", it can be narrowed between 127961 (working) and 127997 (non
working).  Note that the last change of final.c is 127941 (outside the range). 
From an uneducated guess, I'l say 127989, but I may be completely wrong.

>You know, there are many different targets that GCC supports, sometimes the
> patch does not cause any regression on one target can cause regressions on
> others.  This happens all the time.  You need to understand the main reason why
> we have the testsuite is so we easily see when a target has a regression or
> not.

Yes indeed! but the maintainers could look at the above URL to check that there
is no unexpected regression on untested platforms. If they have no access to
some of them, there could be a list of people to ask for details about the
failure (I volunteer for Darwin!).

Otherwise I fully agree with Andrew Pinski about what should not put in bug
reports.


------- Comment #4 From Andrew Pinski 2007-09-02 13:50 [reply] -------

Subject: Re:  [4.3 Regression] Bootstrap check failures ICE's

On 2 Sep 2007 13:42:42 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #3 from dominiq at lps dot ens dot fr  2007-09-02 13:42 -------
> > [18:23] < apinski> between 127935 and 128000
>
> Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
> "regress", it can be narrowed between 127961 (working) and 127997 (non
> working).  Note that the last change of final.c is 127941 (outside the range).
> From an uneducated guess, I'l say 127989, but I may be completely wrong.

From looking closer to the changes, the scheduler changes is not
likely because this happens at -O1 :)  I am more thinking it was:
2007-08-31  Richard Sandiford  <richard@codesourcery.com>

Which changed optabs which is part of the expansion.  The IV change
could not have cause this issue as there is no loop in that function
so the last change would be the optabs change.

-- Pinski


------- Comment #5 From michelin60@gmail.com 2007-09-02 15:23 [reply] -------

I am beginning to enjoy this:

There are about 34 hours between the first indication of failure on regress an
my  report. There are about 8 hours between my report and the first
acknowledgment by GCC. This came by master of obfuscation and arbitrariness: Mr
Pinski.

The management motto at GCC seems to be: "Do as I say, do not do as I do"

There is one person on the steering committee, who has real experience in
building and managing a grou of professionals. His name is Mark Mitchell of
Codesourcery.
There is another member, acting as chairman, who is decidedly mis-using GCC for
the interest of one company. His name is Dr. Edelsohn of IBM. This is not my
statement I posted, acknowledged by GGC, proof in an earlier posting  PR3316. 
That posting caused Mr. Pinski to flaunt a few more rules of comity, ownership
of intellectual property (the posting), etc. There is ample confirmation
provided for this misuse of GCC by using Google to for "Scott Handy IBM". Mr
Handy is pretty far up in IBM management.

Well as long as my name appears as poster of reporter I reserve the right to
say
whatever I please within the rules governing defamation and avoidance of foul
language like used habitually by Mr. Pinski.


------- Comment #6 From Andrew Pinski 2007-09-02 17:49 [reply] -------

Lets see, IBMers working on GCC: more than 11.
Intel folks working on GCC: ~3 or so.
AMDers working on GCC: at least 4 but growing (includes Michael Meissner).
Googlers: who knows any more :) (but at least 10).
Redhat: unknown anymore (at least 12 still)
Codesourcery: ~ 16
Novell (including Suse): ~14 (maybe more)

I don't know why you are dissing IBM here really, it is really becoming a joke.
 IBM is like any big company that supports open source in providing suport for
GCC.  If you want to look at some trend, then you should question goolge (then
again I would not).  Also there are many other companies support powerpc work
for GCC (including Sony for the Cell BEA [me] ).  Freescale has some problems
with their mangement to be able submitting stuff.  

The other thing you should be looking into is a cygnus conspiracy (then again
that conspiracy has been going since 1999 and does not go away every year).  

But seriously there is no conspiracy when it comes to either IBM or cygnus (aka
redhat).  The GCC SC is made up of a people who work for different companies
(and most of the time don't represent them during SC talk.  Also the SC does
not do day to day mangement of GCC. Maintainers do that.  And maintainers in
GCC come from all different companies.  I think you need to look into
MAINTAINERS file to see that.  Yes David is a maintainer for the rs6000 backend
but that does not mean he cause all the issues when it comes to the back-end. 
He does try to fix them every time something comes up and quicky at that.  Just
take a look at PR 33151 (within 4 days of the bug being opened the bug was
fixed).

The problem here though is not really target related except it only shows up on
rs6000 since the target independent changes caused it.

One should note that this is a long weekend in the US.


------- Comment #7 From Andrew Pinski 2007-09-02 17:53 [reply] -------

I just filed a new bug without any of the extra crap: PR 33283.

*** This bug has been marked as a duplicate of 33283 ***

Closing as offtopic stuff was added again.

Maybe I should mention something about 4.2.x, gentoo also decided to use it :).
And it is not a bad release, 4.2.1 is much better.  If glibc does not build with 4.2.1, that does not mean GCC is at fault really.  I think people should blaming GCC all the time when it comes to building code.
Kernel folks have the same issue.