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.
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.
[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.
> [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.
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
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.
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.
I just filed a new bug without any of the extra crap: PR 33283. *** This bug has been marked as a duplicate of 33283 ***