skip_evaluation

skip_evaluation

[Ian Lance Taylor]

I have a question for C++ language lawyers.  The common part of the
C/C++ frontends has a global variable named skip_evaluation.  Both
frontends set this variable while parsing an expression inside sizeof
and friends.  This has the effect of disabling various warnings which
are irrelevant for code which is not going to be executed.  The C
frontend also sets skip_evaluation for constructs like (0 ? x : y) when
parsing the portion of the expression which will never be executed.  The
C++ frontend does not do this.

My question is whether it would be OK for the C++ frontend to also set
skip_evaluation for (0 ? x : y) or whether I should introduce a
different variable.


In asking this, I'm particularly puzzled by code like this in
build_base_path in cp/class.c:

  /* Don't bother with the calculations inside sizeof; they'll ICE if the
     source type is incomplete and the pointer value doesn't matter.  */
  if (skip_evaluation)
    {
      expr = build_nop (build_pointer_type (target_type), expr);
      if (!want_pointer)
	expr = build_indirect_ref (EXPR_LOCATION (expr), expr, NULL);
      return expr;
    }

Presumably the early return is OK within a sizeof expression; it is OK
within an expression like (0 ? x : y)?


I want to handle this one way or another in the C++ frontend in order to
handle expressions like this in the generated file insn-modes.c:

#define MODE_MASK(m)                          \
  ((m) >= HOST_BITS_PER_WIDE_INT)             \
   ? ~(unsigned HOST_WIDE_INT) 0              \
   : ((unsigned HOST_WIDE_INT) 1 << (m)) - 1

When m >= HOST_BITS_PER_WIDE_INT is true, this generates a warning "left
shift count >= width of type".  In C this warning is disabled by
skip_evaluation.  I would like to implement the same feature in C++.

Ian

Re: skip_evaluation

[Paolo Bonzini]

> In asking this, I'm particularly puzzled by code like this in
> build_base_path in cp/class.c:
> 
>   /* Don't bother with the calculations inside sizeof; they'll ICE if the
>      source type is incomplete and the pointer value doesn't matter.  */
>   if (skip_evaluation)
>     {
>       expr = build_nop (build_pointer_type (target_type), expr);
>       if (!want_pointer)
> 	expr = build_indirect_ref (EXPR_LOCATION (expr), expr, NULL);
>       return expr;
>     }
> 
> Presumably the early return is OK within a sizeof expression; it is OK
> within an expression like (0 ? x : y)?

 From reading the code, I'd say yes.  The bug that Jason fixed is 
related to stuff that cannot appear within a constant expression except 
within sizeof -- for example

    struct B {};
    struct D : public B {
        static const int i = sizeof((B*)(D*)0);
    };

    struct Z {};
    struct A : Z {};
    Z* implicitToZ (Z*);
    struct B : A {
        static const int i = sizeof(implicitToZ((B*)0));
    };

    struct B {};
    struct D;
    D* p;
    struct D: public B {
        static const int i = sizeof ((B*)p);
    };

(see PR27177).  All of these would still be forbidden within (0?x:y).

Paolo

Re: skip_evaluation

[Ian Lance Taylor]

Paolo Bonzini <paolo.bonzini@gmail.com> writes:

>> Presumably the early return is OK within a sizeof expression; it is OK
>> within an expression like (0 ? x : y)?
>
> From reading the code, I'd say yes.  The bug that Jason fixed is
> related to stuff that cannot appear within a constant expression
> except within sizeof -- for example
>
>    struct B {};
>    struct D : public B {
>        static const int i = sizeof((B*)(D*)0);
>    };
>
>    struct Z {};
>    struct A : Z {};
>    Z* implicitToZ (Z*);
>    struct B : A {
>        static const int i = sizeof(implicitToZ((B*)0));
>    };
>
>    struct B {};
>    struct D;
>    D* p;
>    struct D: public B {
>        static const int i = sizeof ((B*)p);
>    };
>
> (see PR27177).  All of these would still be forbidden within (0?x:y).

OK, but should they perhaps give an error which would perhaps not be
given if skip_evaluation is true?

Ian

Re: skip_evaluation

[Paolo Bonzini]

>>    struct B {};
>>    struct D : public B {
>>        static const int i = sizeof((B*)(D*)0);
>>    };
>>
>>    struct Z {};
>>    struct A : Z {};
>>    Z* implicitToZ (Z*);
>>    struct B : A {
>>        static const int i = sizeof(implicitToZ((B*)0));
>>    };
>>
>>    struct B {};
>>    struct D;
>>    D* p;
>>    struct D: public B {
>>        static const int i = sizeof ((B*)p);
>>    };
>>
>> (see PR27177).  All of these would still be forbidden within (0?x:y).
> 
> OK, but should they perhaps give an error which would perhaps not be
> given if skip_evaluation is true?

build_cp_class does not give errors after it tests skip_evaluation.  The 
constant-expression errors are given in the parsers.

Paolo

Re: skip_evaluation

[Gabriel Dos Reis]

On Wed, Jun 10, 2009 at 10:51 AM, Paolo Bonzini<paolo.bonzini@gmail.com> wrote:
>
>>>   struct B {};
>>>   struct D : public B {
>>>       static const int i = sizeof((B*)(D*)0);
>>>   };
>>>
>>>   struct Z {};
>>>   struct A : Z {};
>>>   Z* implicitToZ (Z*);
>>>   struct B : A {
>>>       static const int i = sizeof(implicitToZ((B*)0));
>>>   };
>>>
>>>   struct B {};
>>>   struct D;
>>>   D* p;
>>>   struct D: public B {
>>>       static const int i = sizeof ((B*)p);
>>>   };
>>>
>>> (see PR27177).  All of these would still be forbidden within (0?x:y).
>>
>> OK, but should they perhaps give an error which would perhaps not be
>> given if skip_evaluation is true?
>
> build_cp_class does not give errors after it tests skip_evaluation.  The
> constant-expression errors are given in the parsers.

which arguably is not  a good  place to issue such errors.  Support
for constexpr implies that we refrain from issuing such semantics
error from the parser.  However, constexpr patches will come somewhere in
July, so Ian probably does not want to wait for that now.

-- Gaby