Date: Sat, 26 Apr 2025 20:58:10 -0600
> On Apr 26, 2025, at 12:24, Federico Kircheis via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
> On 26/04/2025 7:34 pm, Andrey Semashev via Std-Discussion wrote:
>> On 26 Apr 2025 20:17, Nate Eldredge via Std-Discussion wrote:
>>>
>>> Somewhat related, clang does a "controversial" optimization where, if a
>>> function would unconditionally cause UB if called, the compiler emits a
>>> label for it but no code, not even a return instruction. As such, the
>>> next function compiled can end up at the same address. See https://
>>> godbolt.org/z/775s6e4vv <http://godbolt.org/z/775s6e4vv> for an example.
>>> This does seem like a clear violation of expr.eq p3, but it's
>>> been unfixed for a long time.
>
> Oh, that's bad since the function with UB is never called...
> Strangely removing volatile helps.
Indeed, given simply `f1 == f2` clang optimizes it into constant false, without actually comparing the addresses. So actually it's even worse, since pointers to the same two functions may sometimes compare equal (when the comparison is optimized out) and sometimes unequal (when the addresses are actually compared at runtime), even within the same run of the program.
>
> On 26/04/2025 7:34 pm, Andrey Semashev via Std-Discussion wrote:
>> On 26 Apr 2025 20:17, Nate Eldredge via Std-Discussion wrote:
>>>
>>> Somewhat related, clang does a "controversial" optimization where, if a
>>> function would unconditionally cause UB if called, the compiler emits a
>>> label for it but no code, not even a return instruction. As such, the
>>> next function compiled can end up at the same address. See https://
>>> godbolt.org/z/775s6e4vv <http://godbolt.org/z/775s6e4vv> for an example.
>>> This does seem like a clear violation of expr.eq p3, but it's
>>> been unfixed for a long time.
>
> Oh, that's bad since the function with UB is never called...
> Strangely removing volatile helps.
Indeed, given simply `f1 == f2` clang optimizes it into constant false, without actually comparing the addresses. So actually it's even worse, since pointers to the same two functions may sometimes compare equal (when the comparison is optimized out) and sometimes unequal (when the addresses are actually compared at runtime), even within the same run of the program.
Received on 2025-04-27 02:58:24