https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Henderson from comment #7)
> (In reply to Richard Biener from comment #5)
> > int bad1(void) { return __builtin_constant_p(global++); }
> ...
> > Joseph, Richard, do you have anything to add or remember discussions about
> > this semantic detail of __builtin_constant_p?
>
> Since it has been 25 years, I don't recall any specific discussions.
>
> The intended use-case at the time was more like
>
> #define macro(x) \
> (__builtin_constant_p(x) \
> ? inline_expression(x) \
> : out_of_line_function(x))
>
> So I would have expected side effects to have been ignored for
> the builtin and expanded via one of the two arms.
Thanks. So yes,
macro(x++);
incrementing x twice would have been odd - but that's the usual bug
in this kind of macro definition. Fixing it by throwing away
side-effects (and always going the out_of_line_function (x) path!)
for the __builtin_constant_p argument is an odd choice.
As said, I wondered if that was deliberate or simply an omission of
return omit_one_operand (integer_type_node, integer_zero_node, arg);
...
The execute.exp testcase suggests the intention but the testcases
verification is somewhat incomplete (it lacks verifying the side-effects
are gone).
