* [Bug tree-optimization/32873] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
2007-07-23 23:28 [Bug tree-optimization/32873] New: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption pinskia at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-07-27 21:06 ` pinskia at gcc dot gnu dot org
@ 2007-07-28 0:00 ` michelin60 at gmail dot com
2007-07-28 0:03 ` pinskia at gcc dot gnu dot org
2007-07-28 0:05 ` pinskia at gcc dot gnu dot org
5 siblings, 0 replies; 7+ messages in thread
From: michelin60 at gmail dot com @ 2007-07-28 0:00 UTC (permalink / raw)
To: gcc-bugs
------- 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 michelin60@gmail.com 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 michelin60@gmail.com 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 michelin60@gmail.com 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 michelin60@gmail.com 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 michelin60@gmail.com 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
^ permalink raw reply [flat|nested] 7+ messages in thread