This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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)