------- Comment #3 from michelin60 at gmail dot com 2007-07-28 00:00 ------- Somewhat irritated by this plagiarizing the following come from my earlier PR32865
Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE. is_long_double_1221(ab) and is_long_double_144(ab) vfprintf.c:184: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. ------- Comment #1 From [EMAIL PROTECTED] 2007-07-23 13:48 [reply] ------- Created an attachment (id=13952) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13952&action=view) [edit] preprocessed vprintf.c from glibc-2.6 vprintf.c from glibc-2.6, glibc2.6.90, and glibc-2.5 differ in minor ways but cause the same SSA-Corruption ------- Comment #2 From [EMAIL PROTECTED] 2007-07-23 13:51 [reply] ------- Created an attachment (id=13953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13953&action=view) [edit] Partial *.s output ------- Comment #3 From Andrew Pinski 2007-07-23 17:22 [reply] ------- Stop changing the CC for this bug, the issue is a generic issue and most likely unrelated to any of the CC you added. This is more likely to be a PRE issue than anything else. When I get into work, I will look into it further to double check. ------- Comment #4 From [EMAIL PROTECTED] 2007-07-23 18:03 [reply] ------- (In reply to comment #3) > Stop changing the CC for this bug, the issue is a generic issue and most > likely > unrelated to any of the CC you added. This is more likely to be a PRE issue > than anything else. When I get into work, I will look into it further to > double check. > The three person CC'd are listed per MAINTAINERS as follows: rs600o port David Edelsohn c++ runtime libs Ulrich Drepper (also glibc) tree-ssa Andrew Macloed while spu port Andre Pinski (spu ?= playsation.sony.???) Doing a search of PR's filed I came up, surprise, with no remotely equivalent report and I chose people that matched what I reported. As the author of the report I think that I have the right to choose peple that match as provided by the MAINTAINER's list ------- Comment #5 From David Edelsohn 2007-07-23 18:05 [reply] ------- Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption >>>>> michelin60 at gmail dot com writes: michelin60> Doing a search of PR's filed I came up, surprise, with no remotely equivalent michelin60> report and I chose people that matched what I reported. As the author of the michelin60> report I think that I have the right to choose peple that match as provided by michelin60> the MAINTAINER's list No, you do not. You submitted the bug. Let the GCC developers decide how best to triage and analyse the bug. David ------- Comment #6 From [EMAIL PROTECTED] 2007-07-23 18:33 [reply] ------- (In reply to comment #5) > Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption > > No, you do not. You submitted the bug. Let the GCC developers > decide how best to triage and analyse the bug. > > David Well David here is an interesting quote: IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike. ------- Comment #7 From Andrew Pinski 2007-07-23 18:42 [reply] ------- (In reply to comment #6) > Well David here is an interesting quote: Lets put it this way, this quote is true but it is held hostage in a good way. You don't want broken code in your compiler do you? This is what David and AIX does for GCC, they prevent bad code from being in GCC. Have you looked into what has been found via compiling on AIX? Lots of bugs. Who wants bugs in their compiler? Anyways as I have mentioned before, I am 99% sure this is ___NOT___ related to the powerpc back-end at all. And next time please don't CC anyone unless you are sure at what patch caused the issue. Also don't you can't expect a response within 24 hours, GCC developers are busy with their day jobs. ------- Comment #8 From Andrew Pinski 2007-07-23 18:56 [reply] ------- Working on a reduced testcase but when I quickly looked into it, PRE was messing up the variables that have abnormal set so this is unrelated to the rs6000 back-end. ------- Comment #9 From Andrew Pinski 2007-07-23 21:31 [reply] ------- Generic (also ICEs on i686-linux-gnu) reduced testcase: void _IO_vfprintf_internal ( char *f ) { static const void *const step0_jumps[] = { &&do_form_unknown, &&do_flag_plus, &&do_form_float }; const void * ptr = step0_jumps[0]; do { char spec; spec = (*++f); goto *ptr; do_flag_plus: read_int (&f); do_number: _itoa_word (spec); do_form_float: if (ptr != ((void *)0)) { spec = 'x'; goto do_number; } if (spec != 'S') __strnlen (); return; do_form_unknown:; } while (*f != '\0'); } ------- Comment #10 From Andrew Pinski 2007-07-23 21:35 [reply] ------- Value numbering spec_28(ab) stmt = spec_28(ab) = PHI <spec_7(ab)(3)> Setting value number of spec_28(ab) to spec_7(ab) We should not value number this PHI node, yes it is a copy but a needed copy for abnormal edges. Note the reduced testcase is missing an optimization but that is already filed as PR 32810. ------- Comment #11 From [EMAIL PROTECTED] 2007-07-23 23:17 [reply] ------- Very interesting Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3. This led to further research prompting not only the CC's but also the quote. Dr. Edelsohn metioned triage but there are no triage officers in the MAINTERNER list. Also it might be useful to spell out the rights of submitters. It might discourage submissions which are quite onerous to conform to the already stated requirements. >From his webpage Mr. Berlin is a lawyer specializing in intellectual property and is also an author. He might want to provide some legal advice on conflicts of interest. The quote is specific to glibc and AIX. Potentially the AIX contortions forced upon glibc by Dr. Edelsohn could have caused the specific problem reported, not affecting i686. As an aside the officers of kernel.org (Torvalds, Morton) spell out quite clearly how they are not liable to any interpretation of conflict of interest. ------- Comment #12 From Andrew Pinski 2007-07-23 23:29 [reply] ------- > Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3. > This led to further research prompting not only the CC's but also the quote. If it does not fail on i686 with the non preprocessed source does not mean it is a target specific bug. The quote is offtopic really. >Dr. Edelsohn metioned triage but there are no triage officers in the MAINTERNER list. Right because I am the unofficial bug maintainer :). With response to the glibc issue, Uli is the one who is holding glibc hositage anyways. Anyways, to make this bug cleaner, I am going to close this bug and I opened a new one as PR 32873. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32873
