[PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR

[Joseph S. Myers]

On Fri, 2 Dec 2005, Giovanni Bajo wrote:

> I agree. But I doubt you will find someone with such a spare time. Also it
> depends on how much you are able to understand the problems without even
> trying to modify the code. Surely you are a C frontend maintainer and you
> understand well your frontend, but nobody understands well enough the whole
> compiler to do this auditing. For once, I don't have this familiarity being
> a spare time contributor.

Yes, global changes and cleanups can be hard and take a long time.  This 
doesn't mean we should rush them and introduce bugs in the process.  So 
post lists of the cases you don't understand on the mailing lists, seek 
advice on them from those who may understand the code or know its history, 
clean up the easy cases.  Get people to assist in the project by 
converting cases they understand, post every so often reduced lists of 
remaining cases you don't understand and haven't received help on.  And 
shout at anyone who posts patches adding new cases where NOP_EXPR and 
CONVERT_EXPR are distinguished, so that we move monotonically towards no 
distinction between them.  It may not be done for 4.2 - so what?  It won't 
improve the user experience to merge these tree codes, but each individual 
local change yields a cleaner compiler until eventually we can merge.

> Your plan is the theoretical perfection, but I think practicity beats purity
> in this case. I might have some time to prepare a mechanical patch and fix
> all regressions in the testsuite by debugging them, thus making the patch
> acceptable by our rules. I don't have time to understand all the uses of
> those expressions in the whole compiler to make sure there are no problems.

The rules don't distinguish regressions in and outside the testsuite.  
Lack of testsuite regressions is simply pragmatic evidence that a patch 
already audited by its authors and decided to be correct is indeed 
correct.  The rules specify minimal indivisible changes if there's a 
desire to consider parts separately: I want to consider the essential 
changes separately from the mechanical.  I don't see quickly trading one 
unknown set of bugs for another as preferable to more slowly eliminating 
the first set without introducing the second.

There's no *need* to merge these tree codes, certainly not to do so 
quickly, to justify rushing and introducing unknown bugs rather than 
proceeding with due caution until eventually we can be confident that a 
merge will make no change to the compiler's observable behaviour.

I say the *benefit* of this change is theoretical (a cleaner compiler, not 
a better one) and so avoiding the potential for regressions is the 
practical approach; rushing ahead with a cleanup and damning code it 
breaks is the theoretical one.

> If other regressions are subsequently submitted in Bugzilla, I'll take a

This is necessary *for any cases missed in a due diligence audit*, not a 
substitute for making best efforts to avoid such cases in the first place.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)