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, Mark Mitchell wrote:
> Joseph S. Myers wrote:
> > 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.

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

I'm also concerned that the effects of non-marking truncated values
as having overflowed in force_fit_type and friends, is potentially
much more destabilizing as it unclear how many parts of the compiler
rely on the TREE_CONSTANT_OVERFLOW to avoid unsafe transformations
etc...

Roger
--


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