Re: Potential fix for rdar://4658012

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 8/26/06, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> 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?)

Thanks,
Richard.