[cfe-dev] Incongruency in __builtin_constant_p with pointer argument

[Jens Ayton]

On Apr 28, 2011, at 10:48, Miles Bader wrote:
> 
> 
> Whatever wording is in the documentation, I think people tend to _use_
> __builtin_constant_p as if it means "the value is known to the
> compiler/optimizer, and so most of the calculation can be done at
> compile-time."  A "constant" known only at link-time would break this
> assumption.
> 
> So if consistency is necessary (I dunno), it seems better to follow gcc
> and declare them both non-__builtin_constant_p.

Some user input: when I've used __builtin_constant_p(), the intention has been to predict whether feeding the specified value into some block of code (for instance, a large switch statement) is likely to be optimized to a constant or a subset of the code.

As such, I only want to know whether the value is a constant known to this compiler at this time; whether it's a literal, a constant expression, or another type of const-foldable value, or whether there exist particular operations that will produce constants from it. This is how I've always interpreted the gcc manual. I don't see how I could possibly benefit from it lying to me for "consistency".

As for the "inconsistency" involving strlen(), both gcc and clang seem to give useful results for __builtin_constant_p(strlen(foo)).


-- 
Jens Ayton