This is the mail archive of the gcc@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: New gcc 4.0.0 warnings seem spurious


Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > > However it is correct to store any integer to an unsigned variable,
| > > even if the original value cannot be represented.
| > 
| > If that operation occurs at runtime it has a well-defined result.
| 
| And gcc 4 doesn't output a diagnostic in this case?

Why shall it?

| 
| > If that operation occurs at compile time, as part of an initializer
| > expression, the overflow must be diagnosed (C99 6.6p4 - constraint
| > violation).
| 
| Before the conversion, the value is representable in the type of
| the expression, and after the conversion (which is well-defined),
| it is still representable in the (new) type of the expression.
| 6.7.8#11 mentions the possible conversion. So, I disagree here.
| 
| > > The fact that they are not considered as constant expressions,
| > > is it due to the fact that the environment is allowed to modify
| > > them?
| > 
| > No (and in fact the environment is not allowed to do that).  It is
| > because the set of things that are allowed in constant expressions are
| > explicitly listed in C99 6.6, and read-only variables aren't one of
| > the things on the list.
| 
| The only two constraints in 6.6 are:

In my version of the C standard, 6.6 contains *at least* these two
constraints
       Semantics

       [#5] An expression that evaluates to a constant is  required
       in  several contexts.  If a floating expression is evaluated
       in the translation environment, the arithmetic precision and
       range  shall  be at least as great as if the expression were
       being evaluated in the execution environment.

       [#6] An integer constant expression96)  shall  have  integer
       type   and   shall  only  have  operands  that  are  integer
       constants,  enumeration  constants,   character   constants,
       sizeof  expressions whose results are integer constants, and
       floating constants that are the immediate operands of casts.
       Cast  operators in an integer constant expression shall only
       convert arithmetic types to integer types, except as part of
       an operand to the sizeof operator.

Clearly, 6.6/6 rules out AAA from being an integer constant.

| 
|        [#3] Constant  expressions  shall  not  contain  assignment,
|        increment,  decrement,  function-call,  or  comma operators,
|        except when they are contained within a  subexpression  that
|        is not evaluated.86)
| 
|        [#4] Each constant expression shall evaluate to  a  constant
|        that is in the range of representable values for its type.
| 
| #3 doesn't include variables. #4 is OK if one considers that the
| value cannot be modified.
| 
| #6 adds other requirements, but this is out of the scope of the
| given diagnostic (which complained about an expression not being a
| constant -- not because it wasn't an integer constant expression).
| Couldn't the expression fall into #10 with some implementations?

Huh?

-- Gaby


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