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


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?

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

       [#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?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


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