Am 15.10.2023 um 19:35 schrieb Richard Damon:
> On 10/15/23 3:16 AM, Bonita Montero wrote:
>> Am 15.10.2023 um 09:12 schrieb Bonita Montero:
>>> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>>>
>>>> The compiler can't ignore the calling convention since the definition
>>>> of the variable and the assignment might be spareate. I just printed
>>>> both pointer's addresses and I get different addresses. So there are
>>>> only two options left: either there are separate instantiations for
>>>> each calling convention or there's additional thunk code for each
>>>> calling convention that doesn't mach the standard calling convention.
>>>
>>> This are both instantiations copied from the disassembly in the
>>> debugger:
>>>
>>> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>> 005F10D6 56                   push        esi
>>> 005F10D7 8B 30                mov         esi,dword ptr [eax]
>>> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
>>> 005F10DF 8D 42 01             lea         eax,[edx+1]
>>> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
>>> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
>>> 005F10EB 5E                   pop         esi
>>> 005F10EC C3                   ret
>>>
>>> 005F10A0 55                   push        ebp
>>> 005F10A1 8B EC                mov         ebp,esp
>>> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
>>> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
>>> 005F10B1 8D 42 01             lea         eax,[edx+1]
>>> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
>>> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
>>> 005F10BD 03 C2                add         eax,edx
>>> 005F10BF 5D                   pop         ebp
>>> 005F10C0 C2 04 00             ret         4
>>
>> The symbols for both functions are ...
>>
>> * `main'::`2'::<lambda_1>::<lambda_invoker_fastcall>
>> * `main'::`2'::<lambda_1>::<lambda_invoker_stdcall>
>>
>
> So, two wrappers for the same function. ...

If there were wrappers there would be a CALL XXX.

Am 15.10.2023 um 19:35 schrieb Richard Damon:
> On 10/15/23 3:12 AM, Bonita Montero wrote:
>> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>>
>>> The compiler can't ignore the calling convention since the definition
>>> of the variable and the assignment might be spareate. I just printed
>>> both pointer's addresses and I get different addresses. So there are
>>> only two options left: either there are separate instantiations for
>>> each calling convention or there's additional thunk code for each
>>> calling convention that doesn't mach the standard calling convention.
>>
>> This are both instantiations copied from the disassembly in the
>> debugger:
>>
>> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>> 005F10D6 56                   push        esi
>> 005F10D7 8B 30                mov         esi,dword ptr [eax]
>> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
>> 005F10DF 8D 42 01             lea         eax,[edx+1]
>> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
>> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
>> 005F10EB 5E                   pop         esi
>> 005F10EC C3                   ret
>>
>> 005F10A0 55                   push        ebp
>> 005F10A1 8B EC                mov         ebp,esp
>> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
>> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
>> 005F10B1 8D 42 01             lea         eax,[edx+1]
>> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
>> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
>> 005F10BD 03 C2                add         eax,edx
>> 005F10BF 5D                   pop         ebp
>> 005F10C0 C2 04 00             ret         4
>>
>>
>
> Which is also consistant with a single definition that was inline
> expanded at the two assignment sites

You can see from the RET (xxx) that these are separate functions.
And the functions couldn't be inlined because I hide them behind
volatile function ponters.

> Thus it isn't that you got "two different lambda" with different calling
> convention refencing the same variable, but you have ONE lambda, ...

Seems you're not able to read assembly.

Am 16.10.2023 um 04:23 schrieb Richard Damon:
> On 10/15/23 12:15 PM, Bonita Montero wrote:
>> Am 15.10.2023 um 16:36 schrieb Scott Lurndal:
>>
>>> So, you cannot point to any words in the standard.  Noted.
>>
>> If you don't like platform-specific objections don't read them.
>>
>>
> If making platform-specific question, mention the platform, or better,
> post it in the platform specific group.

As I said you're a nerd.

> Platform specific code, when not restricted to the platform, is often
> undefined in the more general world.

On 10/16/2023 10:47 PM, Bonita Montero wrote:
> Am 15.10.2023 um 19:15 schrieb Richard Damon:
>
>> What make you say that?
>
> I know nerds.
>
> Rest unread.
>

You are a special person, Bonita! :^)

On 10/14/2023 1:51 AM, Paavo Helde wrote:
> 14.10.2023 05:36 Kaz Kylheku kirjutas:
>>
>> The thread-specific keys values of a thread should persist until it
>> has terminated, and then be cleaned up at some later time by
>> *another* thread. Kind of like a garbage collection pass.
>
> So, a destructor of an object which has specifically declared to live in
> a single thread only, will be called in some other thread?
>
> Sure, seems very intuitive, what might go wrong!

Ditto.

On 2023-10-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/14/2023 1:51 AM, Paavo Helde wrote:
>> 14.10.2023 05:36 Kaz Kylheku kirjutas:
>>>
>>> The thread-specific keys values of a thread should persist until it
>>> has terminated, and then be cleaned up at some later time by
>>> *another* thread. Kind of like a garbage collection pass.
>>
>> So, a destructor of an object which has specifically declared to live in
>> a single thread only, will be called in some other thread?
>>
>> Sure, seems very intuitive, what might go wrong!
>
> Ditto.

Objects don't literally live in threads. Objects live in an address
space.

This is exactly like finalization of unreachable objects in managed
environments. If a thread holds some objects which are only accessible
to it, when that thraed terminates, they become garbage. They
necessarily get reclaimed by a different thread, and that one will
run their finalization hooks, if any.

If an object is used by only one thread during its lifetime, that means
that it doesn't require locking. However, the thread which reclaims the
object does not run at the same time as the thread which died, so there
is no race between the two. That aspect of it is fine.

The destructor cannot make the assumption that it is executed by that
same thread. E.g. if the object contained a stashed copy of the thread
ID of the original thread, the destructor would be wrong to assume that
the the thread which is executing it corresponds to that ID.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/17/23 1:48 AM, Bonita Montero wrote:
> Am 15.10.2023 um 19:35 schrieb Richard Damon:
>> On 10/15/23 3:16 AM, Bonita Montero wrote:
>>> Am 15.10.2023 um 09:12 schrieb Bonita Montero:
>>>> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>>>>
>>>>> The compiler can't ignore the calling convention since the definition
>>>>> of the variable and the assignment might be spareate. I just printed
>>>>> both pointer's addresses and I get different addresses. So there are
>>>>> only two options left: either there are separate instantiations for
>>>>> each calling convention or there's additional thunk code for each
>>>>> calling convention that doesn't mach the standard calling convention.
>>>>
>>>> This are both instantiations copied from the disassembly in the
>>>> debugger:
>>>>
>>>> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>>> 005F10D6 56                   push        esi
>>>> 005F10D7 8B 30                mov         esi,dword ptr [eax]
>>>> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
>>>> 005F10DF 8D 42 01             lea         eax,[edx+1]
>>>> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
>>>> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
>>>> 005F10EB 5E                   pop         esi
>>>> 005F10EC C3                   ret
>>>>
>>>> 005F10A0 55                   push        ebp
>>>> 005F10A1 8B EC                mov         ebp,esp
>>>> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>>> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
>>>> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
>>>> 005F10B1 8D 42 01             lea         eax,[edx+1]
>>>> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
>>>> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
>>>> 005F10BD 03 C2                add         eax,edx
>>>> 005F10BF 5D                   pop         ebp
>>>> 005F10C0 C2 04 00             ret         4
>>>
>>> The symbols for both functions are ...
>>>
>>> * `main'::`2'::<lambda_1>::<lambda_invoker_fastcall>
>>> * `main'::`2'::<lambda_1>::<lambda_invoker_stdcall>
>>>
>>
>> So, two wrappers for the same function. ...
>
> If there were wrappers there would be a CALL XXX.
>
>

Nope, because they are wrapping an inline function, which is expanded in
place the two times.

Note the name of the symbols, they are "invokers"

On 10/17/23 1:50 AM, Bonita Montero wrote:
> Am 15.10.2023 um 19:35 schrieb Richard Damon:
>> On 10/15/23 3:12 AM, Bonita Montero wrote:
>>> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>>>
>>>> The compiler can't ignore the calling convention since the definition
>>>> of the variable and the assignment might be spareate. I just printed
>>>> both pointer's addresses and I get different addresses. So there are
>>>> only two options left: either there are separate instantiations for
>>>> each calling convention or there's additional thunk code for each
>>>> calling convention that doesn't mach the standard calling convention.
>>>
>>> This are both instantiations copied from the disassembly in the
>>> debugger:
>>>
>>> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>> 005F10D6 56                   push        esi
>>> 005F10D7 8B 30                mov         esi,dword ptr [eax]
>>> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
>>> 005F10DF 8D 42 01             lea         eax,[edx+1]
>>> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
>>> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
>>> 005F10EB 5E                   pop         esi
>>> 005F10EC C3                   ret
>>>
>>> 005F10A0 55                   push        ebp
>>> 005F10A1 8B EC                mov         ebp,esp
>>> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>>> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
>>> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
>>> 005F10B1 8D 42 01             lea         eax,[edx+1]
>>> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
>>> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
>>> 005F10BD 03 C2                add         eax,edx
>>> 005F10BF 5D                   pop         ebp
>>> 005F10C0 C2 04 00             ret         4
>>>
>>>
>>
>> Which is also consistant with a single definition that was inline
>> expanded at the two assignment sites
>
> You can see from the RET (xxx) that these are separate functions.
> And the functions couldn't be inlined because I hide them behind
> volatile function ponters.

Nope at the final CALL site, it needs to call through the pointer, but
the pointer needs to create the functions, which are wrappers around a
single function, which happens to be inlined for the two instances.

>
>> Thus it isn't that you got "two different lambda" with different
>> calling convention refencing the same variable, but you have ONE
>> lambda, ...
>
> Seems you're not able to read assembly.
>

No, I read it perfectly fine.

Do you not understand how inlining works?
Or how the compiler needs to generate the out of line copy of in line
functions?

The fact that they share a local scope 'static' variable says they must
be copies of the same inline function.

On 10/17/23 1:51 AM, Bonita Montero wrote:
> Am 16.10.2023 um 04:23 schrieb Richard Damon:
>> On 10/15/23 12:15 PM, Bonita Montero wrote:
>>> Am 15.10.2023 um 16:36 schrieb Scott Lurndal:
>>>
>>>> So, you cannot point to any words in the standard.  Noted.
>>>
>>> If you don't like platform-specific objections don't read them.
>>>
>>>
>> If making platform-specific question, mention the platform, or better,
>> post it in the platform specific group.
>
> As I said you're a nerd.
>

And your an idiot troll.

>> Platform specific code, when not restricted to the platform, is often
>> undefined in the more general world.
>

17.10.2023 23:06 Kaz Kylheku kirjutas:
> On 2023-10-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/14/2023 1:51 AM, Paavo Helde wrote:
>>> 14.10.2023 05:36 Kaz Kylheku kirjutas:
>>>>
>>>> The thread-specific keys values of a thread should persist until it
>>>> has terminated, and then be cleaned up at some later time by
>>>> *another* thread. Kind of like a garbage collection pass.
>>>
>>> So, a destructor of an object which has specifically declared to live in
>>> a single thread only, will be called in some other thread?
>>>
>>> Sure, seems very intuitive, what might go wrong!
>>
>> Ditto.
>
> Objects don't literally live in threads. Objects live in an address
> space.
>
> This is exactly like finalization of unreachable objects in managed
> environments.

That's something we want to avoid, not to replicate.

> If a thread holds some objects which are only accessible
> to it, when that thraed terminates, they become garbage. They
> necessarily get reclaimed by a different thread, and that one will
> run their finalization hooks, if any.

We have been through that, here, long time ago, with a lot of pain and
suffering. The consensus reached was that if/when supporting something
like garbage collection in C++, only the occupied memory should be
released by GC. The destructors of objects should not be run, because
that would happen in a non-predictable thread at non-predictable time,
making the program non-deterministic.

To be honest, your idea to run the destructors during the thread join
makes it a bit more deterministic, so it is somewhat better.

On 2023-10-18, Paavo Helde <eesnimi@osa.pri.ee> wrote:
> We have been through that, here, long time ago, with a lot of pain and
> suffering. The consensus reached was that if/when supporting something
> like garbage collection in C++, only the occupied memory should be
> released by GC.

Well, this isn't that discussion; it's about a clean up of
thread-specfic keys when a thread dies.

No GC-like reachability analysis is required; the thread explicitly
terminated and so we know the key bindings are garbage, requiring
destruction. That is handed to us.

There are advantages to not doing that cleanup in the context of the
thread which died.

> The destructors of objects should not be run, because
> that would happen in a non-predictable thread at non-predictable time,
> making the program non-deterministic.

If you what deterministic, don't use these things called threads?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/18/2023 10:29 AM, Kaz Kylheku wrote:
> On 2023-10-18, Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> We have been through that, here, long time ago, with a lot of pain and
>> suffering. The consensus reached was that if/when supporting something
>> like garbage collection in C++, only the occupied memory should be
>> released by GC.
>
> Well, this isn't that discussion; it's about a clean up of
> thread-specfic keys when a thread dies.

I must be misunderstanding you here. However, we do not need to create a
thread-specific key on a per thread basis. One key per process works fine.

On 10/15/2023 7:19 PM, Richard Damon wrote:
> On 10/15/23 3:08 AM, Bonita Montero wrote:
>> Am 14.10.2023 um 17:26 schrieb Richard Damon:
>>
>>> Who said I didn't understand it.
>>
>> You're a nerd and I know nerds.
>
> So, you are wrong, but can't admit it.

Basically, wrt Bonita:
_________
Cruel puppets are one of the most insidious creatures in fantasy worlds.
They use their shapeshifting abilities and sharp tongues to inflict
emotional pain on their victims, often targeting their deepest
insecurities and vulnerabilities.

The cruel puppet's attacks are particularly effective because they are
often unexpected and difficult to defend against. Victims may be tempted
to engage the puppet in a battle of insults, but this is a losing
proposition. The puppet thrives on conflict and will only become more
emboldened by the victim's reactions.

Instead, the best defense against a cruel puppet is to ignore it. This
can be difficult, especially when the puppet is taunting the victim with
personal insults and accusations. However, it is important to remember
that the puppet's words are designed to hurt and should not be taken
seriously.

If the victim can remain calm and collected, the puppet will eventually
lose interest and move on. However, if the victim reacts emotionally,
the puppet will only continue to attack.

In the fantasy world of Gurth, cruel puppets are known to inhabit the
Forest of Youth. During the Great Monster Uprising of the Second Age of
Magic, cruel puppets were also reported in many other regions of the
world, including the abandoned Casino of Port Foozle, the Southern
Wastes, the Coast Road near Borphee, Pheebor, the Forest of Youth, Gurth
Woodland Trail, the Lost Castle of Y'Syska, Crab Island, Egreth Castle,
The Glass Maze, Bozbarland, Largoneth Castle, and the G.U.E. Tech
Training Grounds in the Ethereal Plane of Atrii.

Adventurers who find themselves in these regions should be wary of cruel
puppets. If they encounter one, it is best to avoid it if possible. If
contact is unavoidable, it is important to remain calm and ignore the
puppet's taunts.
_________

Am 18.10.2023 um 05:04 schrieb Richard Damon:

> Nope, because they are wrapping an inline function, which is expanded in
> place the two times.

The functions aren't inlined because the function pointers are volatile.
And as you see there's a RET for each function, so this isn't inlined
code.

> Note the name of the symbols, they are "invokers"

If they were invokers the actual code would be called with a CALL
instruction. And if you know assembly you can see that each function
exactly does what the C++ code does.

Am 18.10.2023 um 05:04 schrieb Richard Damon:

> Nope, because they are wrapping an inline function, which is expanded in
> place the two times.

The functions aren't inlined because the function pointers are volatile.
And as you see there's a RET for each function, so this isn't inlined
code.

> Note the name of the symbols, they are "invokers"

If they were invokers the actual code would be called with a CALL
instruction. And if you know assembly you can see that each function
exactly does what the C++ code does.

Am 18.10.2023 um 05:08 schrieb Richard Damon:

> On 10/17/23 1:50 AM, Bonita Montero wrote:

>> You can see from the RET (xxx) that these are separate functions.
>> And the functions couldn't be inlined because I hide them behind
>> volatile function ponters.

> Nope at the final CALL site, it needs to call through the pointer, but
> the pointer needs to create the functions, which are wrappers around a
> single function, which happens to be inlined for the two instances.

I've traced through the code and both functions are directly called
from the volatile function pointers and both functions do what the
C++ code shows. If they would be invokers both functions wouldn't
have to deal with thread-local storate through the FS-segment.

> Do you not understand how inlining works?

The functions aren't inlined because the function pointers are volatile.

Am 18.10.2023 um 05:08 schrieb Richard Damon:

> On 10/17/23 1:50 AM, Bonita Montero wrote:

>> You can see from the RET (xxx) that these are separate functions.
>> And the functions couldn't be inlined because I hide them behind
>> volatile function ponters.

> Nope at the final CALL site, it needs to call through the pointer, but
> the pointer needs to create the functions, which are wrappers around a
> single function, which happens to be inlined for the two instances.

I've traced through the code and both functions are directly called
from the volatile function pointers and both functions do what the
C++ code shows. If they would be invokers both functions wouldn't
have to deal with thread-local storate through the FS-segment.

> Do you not understand how inlining works?

The functions aren't inlined because the function pointers are volatile.

On 2023-10-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 18.10.2023 um 05:04 schrieb Richard Damon:
>
>> Nope, because they are wrapping an inline function, which is expanded in
>> place the two times.
>
> The functions aren't inlined because the function pointers are volatile.
> And as you see there's a RET for each function, so this isn't inlined
> code.

Can you point to any documentation (MSDN?) that would give us confidence
that all which happened is a committed, robust feature that will work
across different versions of MSVC, with different code generation
options?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Am 19.10.2023 um 20:06 schrieb Kaz Kylheku:

> Can you point to any documentation (MSDN?) that would give us confidence
> that all which happened is a committed, robust feature that will work
> across different versions of MSVC, with different code generation
> options?

Which option do you think would make MSVC drop the optimization barrier
of volatile function pointers ? The only volatile compiler option is
ISO or MSVC volatile behaviour.

On 10/19/23 1:58 PM, Bonita Montero wrote:
> Am 18.10.2023 um 05:04 schrieb Richard Damon:
>
>> Nope, because they are wrapping an inline function, which is expanded
>> in place the two times.
>
> The functions aren't inlined because the function pointers are volatile.
> And as you see there's a RET for each function, so this isn't inlined
> code.
>
>> Note the name of the symbols, they are "invokers"
>
> If they were invokers the actual code would be called with a CALL
> instruction. And if you know assembly you can see that each function
> exactly does what the C++ code does.

Not if they were invoking an inline function.

And yes, that is what happens when you inline a function multiple times.

At the C++ language level, they are all the same function, it just
exists in multiple places in memory.

You seem to go by what you think is happening, not by what is defined to
happen.

On 10/19/23 2:02 PM, Bonita Montero wrote:
> Am 18.10.2023 um 05:08 schrieb Richard Damon:
>
>> On 10/17/23 1:50 AM, Bonita Montero wrote:
>
>>> You can see from the RET (xxx) that these are separate functions.
>>> And the functions couldn't be inlined because I hide them behind
>>> volatile function ponters.
>
>> Nope at the final CALL site, it needs to call through the pointer, but
>> the pointer needs to create the functions, which are wrappers around a
>> single function, which happens to be inlined for the two instances.
>
> I've traced through the code and both functions are directly called
> from the volatile function pointers and both functions do what the
> C++ code shows. If they would be invokers both functions wouldn't
> have to deal with thread-local storate through the FS-segment.

Yes, the call through the pointer isn't inlined, because that would
violate the symantics of the volatile.

The calls inside the invokers IS inlined, because there it know exactly
what function is being called.

So, you are seeing two invoker thunks to the same function, but that
function has been inlined into the two invoker thunks.

>
>> Do you not understand how inlining works?
>
> The functions aren't inlined because the function pointers are volatile.
>

So, you don't understand what happens when you take the address of an
inline function?

On 2023-10-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 19.10.2023 um 20:06 schrieb Kaz Kylheku:
>
>> Can you point to any documentation (MSDN?) that would give us confidence
>> that all which happened is a committed, robust feature that will work
>> across different versions of MSVC, with different code generation
>> options?
>
> Which option do you think would make MSVC drop the optimization barrier
> of volatile function pointers? The only volatile compiler option is
> ISO or MSVC volatile behaviour.

Possibly, options that turn off optimization entirely, so that the barrier is not
considered.

It's the wrong question. What piece of documentation specifies that
there is such an optimization barrier? Not just the optimization
barrier, but an optimization barrier that causes calling convention
attributes from a pointer to regenerate the called function body.

Where did you get this belief?

It is really weird. It similar to a situation like:

struct foo { int x; int y } foo_obj = { 1, 2 };
struct bar { int y; int x };

bar *volatile bar_ptr = (struct bar *) &foo_obj;

printf("%d\n", bar_ptr->x); // unexpectedly prints 1

Wee, the compiler fixed up the ->x reference to the correct offset
through the wrong type.

The code looks flatly wrong in the abstract semantics, because a
function not defined with any calling convention attributes (and thus
"__cdecl") is being called with incompatible calling conventions.

In the abstract semantics without optimization, of course we expect real
function calls to be attempted.

A plausible explanation for the observed behavior is that the
function got inlined first, and then due to the volatile, it was
de-inlined, and this happened in such a way that the calling conventions
from the pointer influenced the code generation.

Where is that aspect of it documented?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/19/23 3:20 PM, Kaz Kylheku wrote:
> On 2023-10-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 19.10.2023 um 20:06 schrieb Kaz Kylheku:
>>
>>> Can you point to any documentation (MSDN?) that would give us confidence
>>> that all which happened is a committed, robust feature that will work
>>> across different versions of MSVC, with different code generation
>>> options?
>>
>> Which option do you think would make MSVC drop the optimization barrier
>> of volatile function pointers? The only volatile compiler option is
>> ISO or MSVC volatile behaviour.
>
> Possibly, options that turn off optimization entirely, so that the barrier is not
> considered.

Turning off optimizations says that definitely the volatile barrier will
be obeyed. The question

>
> It's the wrong question. What piece of documentation specifies that
> there is such an optimization barrier? Not just the optimization
> barrier, but an optimization barrier that causes calling convention
> attributes from a pointer to regenerate the called function body.
>
> Where did you get this belief?

Well, since the pointer is volatile, the compiler can not assume it
points to the function that the pointer was set to.

>
> It is really weird. It similar to a situation like:
>
> struct foo { int x; int y } foo_obj = { 1, 2 };
> struct bar { int y; int x };
>
> bar *volatile bar_ptr = (struct bar *) &foo_obj;
>
> printf("%d\n", bar_ptr->x); // unexpectedly prints 1
>
> Wee, the compiler fixed up the ->x reference to the correct offset
> through the wrong type.
>
> The code looks flatly wrong in the abstract semantics, because a
> function not defined with any calling convention attributes (and thus
> "__cdecl") is being called with incompatible calling conventions.
>
> In the abstract semantics without optimization, of course we expect real
> function calls to be attempted.
>
> A plausible explanation for the observed behavior is that the
> function got inlined first, and then due to the volatile, it was
> de-inlined, and this happened in such a way that the calling conventions
> from the pointer influenced the code generation.
>
> Where is that aspect of it documented?
>

WHat I see is that we have, as you say, a pointer to a _cdecl function
being assigned to a different calling convention pointer, so the
compiler builds a thunk or an "invoker" that accepts a call by the
specified convention, and then "calls" the specified function. Since
that function is inlinable, that call just become an inline instance of
the function. At THIS point, we don't have the volatile barrier, so the
inlining is possible.

On 10/18/2023 11:31 AM, Chris M. Thomasson wrote:
> On 10/18/2023 10:29 AM, Kaz Kylheku wrote:
>> On 2023-10-18, Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> We have been through that, here, long time ago, with a lot of pain and
>>> suffering. The consensus reached was that if/when supporting something
>>> like garbage collection in C++, only the occupied memory should be
>>> released by GC.
>>
>> Well, this isn't that discussion; it's about a clean up of
>> thread-specfic keys when a thread dies.
>
> I must be misunderstanding you here. However, we do not need to create a
> thread-specific key on a per thread basis. One key per process works fine.
>

Multiple TLS keys per process usually occurs when we load a third party
library.

On 10/19/2023 12:20 PM, Kaz Kylheku wrote:
> On 2023-10-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 19.10.2023 um 20:06 schrieb Kaz Kylheku:
>>
>>> Can you point to any documentation (MSDN?) that would give us confidence
>>> that all which happened is a committed, robust feature that will work
>>> across different versions of MSVC, with different code generation
>>> options?
>>
>> Which option do you think would make MSVC drop the optimization barrier
>> of volatile function pointers? The only volatile compiler option is
>> ISO or MSVC volatile behaviour.
>
> Possibly, options that turn off optimization entirely, so that the barrier is not
> considered.
>
> It's the wrong question. What piece of documentation specifies that
> there is such an optimization barrier? Not just the optimization
> barrier, but an optimization barrier that causes calling convention
> attributes from a pointer to regenerate the called function body.
>
> Where did you get this belief?
>
> It is really weird. It similar to a situation like:
>
> struct foo { int x; int y } foo_obj = { 1, 2 };
> struct bar { int y; int x };
>
> bar *volatile bar_ptr = (struct bar *) &foo_obj;
^^^^^^^^^^^^^^^^^

Nasal demons regardless of volatile?

>
> printf("%d\n", bar_ptr->x); // unexpectedly prints 1
>
> Wee, the compiler fixed up the ->x reference to the correct offset
> through the wrong type.
>
> The code looks flatly wrong in the abstract semantics, because a
> function not defined with any calling convention attributes (and thus
> "__cdecl") is being called with incompatible calling conventions.
>
> In the abstract semantics without optimization, of course we expect real
> function calls to be attempted.
>
> A plausible explanation for the observed behavior is that the
> function got inlined first, and then due to the volatile, it was
> de-inlined, and this happened in such a way that the calling conventions
> from the pointer influenced the code generation.
>
> Where is that aspect of it documented?
>