This is the mail archive of the 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

Joseph S. Myers wrote:
On Tue, 21 Dec 2004, Mark Mitchell wrote:

I have a broader question.  In C, where signed overflow is
implementation-defined behavior, why don't we just define it to wrap, as with
unsigned arithmetic, in the usual modulo-2 way.  And then not set
TREE_CONSTANT_OVERFLOW at all?  What do we want with nodes that are zero, but
marked as having overflowed?

If an expression overflows then it violates the constraints on constant expressions, and so, for example, isn't a null pointer constant (which I think is why integer_zerop acts the way it does). DR#031 indicates that this applies if any subexpression (by implication from an example only evaluated subexpressions) overflows, so

#include <limits.h>
void f(void) { void *p = 0 * (INT_MAX + 1); }

involves a constraint violation (of the constraints on assignment to pointers, because the expression isn't an integer constant expression since it fails the constraints on those) which must be diagnosed.

In theory, the constant should only be marked as overflowing where undefined behavior has occurred if it gets evaluated, and so integer_zerop acting the way it does shouldn't cause other problems. Bugs such as this one may indicate the constant is wrongly marked as overflowing: conversions of out-of-range values to signed integer types are implementation-defined rather than undefined.

Thanks; I will revise my query. Roger, it seems to me that perhaps we should leave c_common_truthvalue_conversion alone, and instead not mark the conversion of 0x100 to signed char with TREE_CONSTANT_OVERFLOW. As Joseph says, this is just implementation-defined, and we may as well define it as just another way of writing zero.

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

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