[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 11:41 --- [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. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- 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. 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
Re: [Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:50 --- Subject: Re: [4.3 Regression] Bootstrap check failures ICE's On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #5 from michelin60 at gmail dot com 2007-09-02 15:23 --- 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. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
