This is the mail archive of the
mailing list for the GCC project.
Re: Potential fix for rdar://4658012
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Richard Kenner" <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, jconner at apple dot com
- Date: Sat, 26 Aug 2006 11:48:11 +0200
- Subject: Re: Potential fix for rdar://4658012
- References: <44EF948E.email@example.com> <firstname.lastname@example.org> <10608260940.AA19284@vlsi1.ultra.nyu.edu>
On 8/26/06, Richard Kenner <email@example.com> wrote:
[I added the gcc list too since this is more than just a discussion about
a single patch.]
> > So, I went looking for an approach which would fix this in the C++
> > front-end instead. However, I discovered that the C front-end has a
> > similar problem.
> > And so, not changing the
> > middle-end would mean changing both C and C++ front-ends (note that this
> > isn't a gcc 3.x regression for C).
> Given that this fixes a quite serious regression and the Ada failure on
> Sparc was quite vague I would argue to put it in 4.3 and later backport
> it to 4.2.1 if this problem no longer occurs. Or to put that on the burden
> of Ada/Sparc completely.
I think it's a dangerous precedent to start judging patches by who the burden
is on if it breaks something or which is the smaller patch. If C and C++
have the same bug, that's hardly surprising given their common lineage.
I think we should be judging patches purely on technical grounds. It would
certainly be worth exhibiting the C/C++ patch so people could see if it was
correct. As to the middle-end patch, like any other similar patch, if you
remove code that says that something might be used in a certain way, you
bear the burden of proving that it can't be used in that way.
In this case, as I said, it might well be the case that this can no longer
happen. Indeed, a lot of the similar code for temporaries might not be
needed anymore. And I'd argue that now that we have GIMPLE, we could
arrange things so that NO temporaries are allocated by the middle-end and
that would be a good thing. I spent a lot of time in the old days dealing
with obscure bugs in that code and it would be good for it to all go away.
But I'm not comfortable with simply deleting a piece of it now without the
proper analysis. I agree the regression is serious, but let's see both
possibilities (middle-end and front-end) so a technical decision can be
made as to the best approach.
I completely agree. But only up to the point defining "proper analysis" -
bootstrapping and regtesting is required for a patch to be accepted and
I think it is a valid request from your side to require testing of Ada on Sparc
for this patch as you remember problems on that platform. Given that
this succeeds, requiring further "proper analysis" or proof or whatever is
putting the burden on the wrong side and not reasonable. (I don't know
if there is a way to do this Ada on Sparc testing with a cross compiler on
a more available platform - maybe you can suggest a target triple that
has a simulator available?)