On Fri, 3 Nov 2023, Joseph Myers wrote:
> On Fri, 3 Nov 2023, Richard Biener wrote:
>
> > The following tries to clarify the __builtin_constant_p documentation,
> > stating that the argument expression is not evaluated and side-effects
> > are discarded. I'm struggling to find the correct terms matching
> > what the C language standard would call things so I'd appreciate
> > some help here.
> >
> > OK for trunk?
>
> OK.
Pushed.
> > Shall we diagnose arguments with side-effects? It seems to me
> > such use is usually unintended? I think rather than dropping
>
> The traditional use is definitely in macros to choose between code for
> constant arguments (evaluating them more than once) and maybe-out-of-line
> code for non-constant arguments (evaluating them exactly once), in which
> case having a side effect is definitely OK.
I was wondering about literally writing
if (__builtin_constant_p (++x))
{
...
}
else
{
...
}
which would have the surprising effects that a) it always evaluates
to false, b) the side-effect to 'x' is discarded.
> > side-effects as a side-effect of folding the frontend should
> > discard them at parsing time instead, no?
>
> I suppose the original expression needs to remain around in some form
> until the latest point at which optimizers might decide to evaluate
> __builtin_constant_p to true. Although cases with possible side effects
> might well be optimized to false earlier; the interesting cases for
> deciding later are e.g. __builtin_constant_p called on an argument to an
> inline function (no side effects for __builtin_constant_p to discard,
> whether or not there are side effects in the caller from evaluating the
> expression passed to the function).
Yes, maybe we can improve here but as of now arguments with
side-effects will always result in a 'false' assessment as to
__builtin_constant_p, so the behavior is hardly useful apart from
having "correct" behavior for the traditional macro case.
Richard.
