------- Comment #11 from joseph at codesourcery dot com 2007-03-23 13:41 ------- Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
On Fri, 23 Mar 2007, pinskia at gmail dot com wrote: > No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its That depends on an analysis of every caller of STRIP_SIGN_NOPS to work out what semantics they require and whether removing conversions changing the value is correct in that case. Only then can you determine whether STRIP_SIGN_NOPS should have the present semantics and some subset of callers should be changed to work with those semantics, or whether the semantics of STRIP_SIGN_NOPS would better be changed. On the whole I think that references to the mode in STRIP_NOPS and STRIP_SIGN_NOPS are rather doubtful - mode should not be of relevance at this level of tree optimizations - and mode is probably being used as a proxy for precision. The general sequence of integer type conversions can be represented in the form "truncate to M bits, sign-extend to N bits and then zero-extend to the width of the outer type", maybe this should be represented somehow; then it would be defined exactly what such conversions can be removed by these macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136