This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 Dec 2004 21:00:29 +0000 (UTC)
- Subject: Re: [PATCH] PR19100: truthvalue_conversion vs. TREE_CONSTANT_OVERFLOW
- References: <Pine.LNX.email@example.com>
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/
firstname.lastname@example.org (personal mail)
email@example.com (CodeSourcery mail)
firstname.lastname@example.org (Bugzilla assignments and CCs)