[cfe-dev] Incongruency in __builtin_constant_p with pointer argument

[Abramo Bagnara]

Il 28/04/2011 00:06, Joerg Sonnenberger ha scritto:
> On Wed, Apr 27, 2011 at 11:30:50PM +0200, Abramo Bagnara wrote:
>> I'm perfectly fine with the fact that clang treats const typed variable
>> as evaluatable constant (although gcc don't), but this should be the
>> same for both cases.
> 
> But a pointer to a global variable is not known at compile-time.
> At such the behavior is completely correct and valid.

>From http://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Other-Builtins.html:

> You can use the built-in function __builtin_constant_p to determine
> if a value is known to be constant at compile-time and hence that GCC
> can perform constant-folding on expressions involving that value. The
> argument of the function is the value to test. The function returns
> the integer 1 if the argument is known to be a compile-time constant
> and 0 if it is not known to be a compile-time constant. A return of 0
> does not indicate that the value is not a constant, but merely that
> GCC cannot prove it is a constant with the specified value of the -O
> option.

I think that clang is right to consider pointer to static memory region
to be constant at compile-time and hence candidate to constant-folding.
(note that the documentation does not say "constant with a known value
at compile-time", but "value known to be constant at compile time").

The following snippet shows another example of what clang does:

$ cat t.c
int i;

int a[__builtin_constant_p(&i) ? 1 : -1];
$ clang -S t.c
$

The point is only if this constant folding should be reported by
__builtin_constant_p or if the intention is that clang implementation
should mimic gcc behaviour.