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: C constant expressions proposals


On Sat, 14 Aug 2004, Gabriel Dos Reis wrote:

> | object rather than as being constants, and in C const does not affect 
> | linkage) to the valid parts of constant expressions.  This question isn't 
> 
> I was not suggesting that you make "const" change linkage.  

And I was just reiterating a difference between C and C++ here (as I 
suppose not all readers are familiar with even the documented differences 
in interpretation of shared syntax), as part of the argument that C and 
C++ treat const differently, hence we should wait for WG14 before 
including C++-like semantics as an extension to C.

> | You should also exclude volatile const variables.
> 
> If the model is based on existing semantics in C++, there is no
> exclusion of const volatile.  I think Mark Mitchell recently applied a
> patch to the C++ front-end to that effect.

Isn't that C++ DR 76, incorporated in C++03?  Although the change only 
seems to be to [dcl.type.cv] without anything corresponding in 
[expr.const].

>   (1) declare that the call is never a constant expressions (even
>       though internally it might be); or
>   (2) or declare that it is always a constant expressions - this means
>       we have a list all transformation we do at optimization level N
>       and decide to apply them for the appropriate categories of
>       functions and arguments.
> 
> If the purpose of your model is to remove random variations, I think
> it makes sense to adopt either (1) or (2).

It does.  But the argument

> | standard is of course silent on __builtin_ function calls, there's no 
> | great value in arbitrarily annoying users by restricting them.
> 
> Agreed.  And I think we should make this guarantee irrespective of the
> optimization level.

is one for (2) which involves making these functions much more precisely 
defined than hitherto.  Such documentation is of course a good idea, but 
it is possible to refine things incrementally after implementation in this 
area, i.e. move to specifying the rules for more built-in functions.

> The reason I mentioned the "constant-valued function" proposal is
> precisely that it gives a general rule of what users may expect or
> consider a constant expression.  It needs not  a long list of special
> functions we would have to update as we go.

It depends on the body of the function.  We don't have bodies for these 
built-in functions, but many of them would be much more complicated than 
just returning a single constant expression, although they could be 
treated "as if" they return such a constant expression - bearing in mind 
that some functions are only folded for certain arguments.

> | when (and we fold some only for particular arguments).  When folding 
> | arithmetic constant expressions, FENV_ACCESS complicates matters as well 
> | (i.e. except in static initializers we can't fold, but VLA constraints 
> | expect us to, and there was a view in the UK C Panel that the problem 
> | there might be that the expression was still considered constant in the 
> | presence of FENV_ACCESS rather than in the VLA constraints).  As the 
> 
> If FENV_ACCESS is OFF, the compile-time evaluation is permitted.
> Otherwise, the evaluation is "as-if" done at run time.  Precisely how
> was the other view derived?

The expressions are (it seems to be intended) constant expressions by 
virtue of their operands, and are evaluated as if during execution; F.7.4 
is explicit on that.  But the constraints in 6.7.5.2#1 expect it to be 
determinable at translation time whether the constant expression dimension 
is greater than zero.

I had a draft DR proposing changing "constant expression" to "integer 
constant expression" in 6.7.5.2#1 which would match the rule for 
determining whether an array is a VLA.  About 1 hour 45 minutes of the 2 
hour panel meeting was spent discussing whether to support the creation of 
some new WG14 work items (despite the principle that work item creation is 
a purely formal vote to which you shouldn't object if other countries are 
willing to do the work), leaving 15 minutes to discuss the proposed DR.  
The objections were of the forms:

* We don't want to change some cases (int x[(int)-1.0]; etc.) from 
constraint violations to undefined, so instead should change the standard 
to make the problematic expressions (only) clearly not constant 
expressions in such cases with FENV_ACCESS on.

* The magic wording in resolution of DR#261 that was written on the 
blackboard at the Oxford WG14 meeting would resolve this question - or in 
any case, that wording was needed to address the issue, and no-one could 
remember it.

* Given the arguments about the above, it was clear the issue was more 
complicated than the one-word proposed resolution made out, and Francis as 
the UK representative to WG14 meetings wasn't going to be able to 
understand the issues sufficiently well in the time left in the panel 
meeting to put the case to WG14 at their next meeting.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


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