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]

Re: c enable-checking failure


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


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