Re: int a = a

On 20/03/2025 11:20, Keith Thompson wrote:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

>
The "could have been declared with the register storage class"
seems quite odd.  And in fact it is quite odd.

>
I don't have the same reaction.  The point of this phrase is that
undefined behavior occurs only for variables that don't have
their address taken.  The phrase used describes that nicely.
Any questions related to "registerness" can be ignored, because
'register' in C really has nothing to do with hardware registers,
despite the name.

 DR 338 is explicitly motivated by an IA-64 feature that applies only to
CPU registers.  An object whose address is taken can't be stored (only)
in a register, so it can't have a NaT representation.
 The phrase used is "could have been declared with register storage class
(never had its address taken)".  Surely "never had its address taken"
would have been clear enough if CPU registers weren't a big part of the
motivation.
 

I too think the phrasing is a bit odd.
Just because a variable's address is taken, does not mean it cannot be put in a cpu register by the compiler.  If the variable is not accessed in a way that actually requires putting it in memory, then the compiler can put it in a cpu register (or otherwise optimise it).  So simply taking the address of a variable on IA-64 does not mean it cannot be in a register, and thus does not necessarily mean it cannot be NaT.  Taking the address of a variable means the variable cannot be declared "register", but it does not mean it cannot be /in/ a register.
It seems very strange to me that this is UB:
int foo1(void) {
int x;
return x;
}
while this is not :
int foo2(void) {
int x;
int * p = &x;
return x;
}
(Unfortunately, godbolt.org doesn't seem to have a gcc IA-64 compiler in its list.)
It strikes me that it would have been far simpler for the standard simply to say that using the value of an uninitialised and unassigned variable is undefined behaviour.