[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