On 4/27/25 01:39, Jason McKesson via Std-Discussion wrote:
> On Sat, Apr 26, 2025 at 4:06 PM Tiago Freire via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>>
>> I personally see no reason why "no such guarantees" shouldn't be part of the standard.
>> I see no reason as to why comparing function addresses should yield predictable results, and saving spaces seems to me like an overwhelming compelling case as why 2 functions could have the exact same address.
>
> Because different things should be different. If `foo` and `bar` do
> not name the same entity, then they are not the same. If pointers to
> functions point to a specific function entity, then pointers to those
> two different entities should have different addresses because they
> refer to two different entities.
>
> We actually have an explicit rule for objects: [intro.object]/10.
> Outside of nesting, zero-sized subobjects, or string/array literals,
> addresses for different objects must be *different*.
>
> To be fair, within that rule is the exception for string/array
> literals. And maybe functions could be treated like literals, as
> "non-unique". But it seems to me that it's reasonable to expect
> compilers to not make different things behave differently. If you
> never get the address of both `foo` and `bar`, then the compiler ought
> to be able to play whatever games it wants. But if you explicitly get
> the address of both, then the compiler needs to manifest them with
> different addresses.
>
> Granted, that might be a linker nightmare since in one TU you might
> get the address of `foo`, and in another TU, you get the address of
> `bar`, so you don't know that they need to have different addresses
> until the linker happens.

Could the scope of [[no_unique_address]] be broadened to allow these
optimizations? Looks like GCC does merge global const objects with this
attribute, but not functions: https://godbolt.org/z/YvY8M3hKT