This is the mail archive of the
mailing list for the GCC project.
Re: Potential fix for rdar://4658012
[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.