This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW


On Tue, 21 Dec 2004, Roger Sayle wrote:

> I think that not marking a conversion of 0x100 to signed char as
> TREE_CONSTANT_OVERFLOW would just be hiding the problem.  As shown
> by Joseph's example from DR#31 "0 * (MAX_INT+1)", its still the
> case the GCC can generate values that are zero but marked as overflow,
> and in these cases it's still wrong for truthvalue_conversion to
> convert them into "true" (C++) or "1" (C).

But 0 * (INT_MAX + 1) involves undefined behavior if executed, so such odd 
handling doesn't matter in that case.  Whereas conversion of 0x100 to 
signed char, both explicit and implicit, is implementation-defined rather 
than undefined (and we do document it in implement-c.texi).

It's true that long term the overflow markings (and null pointer constant 
checking) should be confined to the front ends so integer_zerop doesn't 
need to act in such a strange way, and in the interests of stability at 
present such local changes to truthvalue_conversion may make sense to 
handle the -fwrapv case although the example of this PR still shouldn't 
get the overflow marking.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]