[PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR

Joseph S. Myers joseph@codesourcery.com
Fri Dec 2 18:07:00 GMT 2005


By way of illustration of real distinctions present in the code, here is 
the first problem with a blind unification which I found in a *few 
minutes' checking*.  Compile

int printf(const char *, ...);
void f(void) { printf((char *)(short)"%"); }

with -Wall; there is no format warning.  But if you make 
check_function_arguments_recurse allow CONVERT_EXPR as well as NOP_EXPR, 
there is a format warning (which is inappropriate; the conversions may be 
dodgy, but the format isn't in any way a constant string that can be 
format checked).

In this case, the proper fix from examining the code is to allow NOP_EXPR 
or CONVERT_EXPR but check that the conversion preserves the precision of 
integer/pointer types, or as a stronger condition only allow conversions 
between pointers.  In either case, a test like the above should be added 
to the testsuite to exercise the condition that not all conversions are 
OK.

To my mind, the *essence* of the unification of the tree codes is fixing 
all the places which treat them differently to use a better-defined 
condition, and the *boring mechanical part* is the actual unification.  
The essence should be done separately from the boring mechanical part.  
The essence can readily be split up; fixing 
check_function_arguments_recurse, with a new testcase as above, is 
independent of fixing the rest of the code.

The mechanical changes should be such that it is obvious that they cannot 
change how the observable behaviour of the compiler because before those 
changes there is nothing which cares whether a given tree is NOP_EXPR or 
CONVERT_EXPR.

As a minimum level of splitting up the essential changes I'd suggest that 
those for each front end, each back end, and the rest of the compiler be 
posted separately, but splitting them up further to the level of 
individual files or individual functions is fine as well.

-- 
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)



More information about the Java-patches mailing list