https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33437
jbeulich at suse dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |NEW
Resolution|INVALID |---
--- Comment #3 from jbeulich at suse dot com ---
(In reply to Andrew Pinski from comment #2)
> This is not a valid C.
As per "All the expressions in an initializer for an object that has static or
thread storage duration shall be constant expressions or string literals."
long l = (long)x;
then either similarly isn't (yet the compiler accepts it), or both are (which
is my reading of the sentence, albeit further restrictions make this invalid).
Plus if it was strictly invalid, then why would a PPC compiler accept it (as
you've said yourself many years ago)?
It was for a reason that I did say "potentially" in the title. Without knowing
what "x" is and what relocation types a target has, the compiler has no
justification to say "initializer element is not computable at load time". It
might use "may", but then it would still be overly limiting. As said in the
original description, "x" may simply stand for a small constant value, which C
does not allow to access any (meaningfully) other way than by expressing
through either an array (as in the example) or by using the address operator in
the initialization.
> That is (int)(long)x where
> sizeof(long)!=sizeof(int)!=sizeof(void*) the linker might not know the value
> at link time and therefor will need a runtime relocation and then it might
> not load at load time as the value would have gotten truncated.
Hence it should be the assembler's job to determine whether a suitable
relocation type is available and the (static and/or dynamic) linker's job to
detect and report truncation / overflow. This is not the least because later
the standard also says "An implementation may accept other forms of constant
expressions."
