c enable-checking failure

Jason Merrill jason@cygnus.com
Sat Jul 11 18:29:00 GMT 1998


>>>>> Jason Merrill <jason@cygnus.com> writes:

>>>>> Jim Wilson <wilson@cygnus.com> writes:
>>> The exact situation was a NOP to the same integer type, so one
>>> might wonder if fold isn't supposed to take care of that.
>> Good question.  Or maybe it's stripped out during tree->rtl conversion.

>> The NOP_EXPRs are deliberately added so that we can tell the difference
>> between a constant, and an expression that was reduced to a constant.
>> This is needed to correctly handle C null pointer constants, which must
>> be an integral constant expression.  Ideally, there should be a NOP_EXPR
>> at the end if and only if the original expression was not an integral
>> constant expression.  It is possible though that we are adding the
>> NOP_EXPRs when they aren't strictly necessary.

> We are.  The code hits

>           if (integer_zerop (arg1))
>             return non_lvalue (convert (type, arg0));

> and non_lvalue adds the NOP regardless of whether arg0 is constant or not.
> That seems wrong.

I don't have the C standard handy, but the C++ standard says

  -1- A null pointer constant is an integral constant expression (expr.const)
  rvalue of integer type that evaluates to zero.

and then

  An integral constant-expression can involve only literals (lex.literal),
  enumerators, const variables or static data members of integral or
  enumeration types initialized with constant expressions (dcl.init),
  non-type template parameters of integral or enumeration types, and sizeof
  expressions. Floating literals (lex.fcon) can appear only if they are
  cast to integral or enumeration types. Only type conversions to integral
  or enumeration types can be used. In particular, except in sizeof
  expressions, functions, class objects, pointers, or references shall not
  be used, and assignment, increment, decrement, function-call, or comma
  operators shall not be used.

Looking back into the mists of time, I see

Tue Jan 19 09:22:06 1993  Richard Stallman  (rms@mole.gnu.ai.mit.edu)

        * fold-const.c (non_lvalue): Result must not be null ptr constant.
        (omit_one_operand): Use non_lvalue.
        (fold, case COMPOUND_EXPR): Use non_lvalue if value is 0.
        * c-typeck.c (build_compound_expr): Use non_lvalue if value is 0.

so the change was intended to prevent comma expressions from being null
pointer constants, which is correct.  However, as you say, this is not
appropriate for all uses of non_lvalue.  Has this been broken since 1993?

Jason



More information about the Gcc-patches mailing list