Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #92556 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-10-11 05:30 +0200 |
| Last post | 2023-10-25 23:12 -0700 |
| Articles | 20 on this page of 134 — 12 participants |
Back to article view | Back to comp.lang.c++
What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 05:30 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-11 14:03 +0100
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-11 13:12 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:22 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-11 17:41 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-11 20:24 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:24 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-13 17:53 +0100
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:12 -0400
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-13 17:27 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:52 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:08 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-15 12:55 -0700
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:19 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 20:58 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:21 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:41 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:25 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-12 20:50 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 08:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:53 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:00 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:47 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-13 16:34 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 13:12 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 02:36 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 20:44 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 11:51 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:35 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-17 20:06 +0000
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-18 11:43 +0300
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-18 17:29 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 11:31 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:54 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 18:05 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 14:58 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 08:58 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-14 12:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:07 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:12 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:16 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:48 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:04 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:39 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 18:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:11 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 19:20 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 16:06 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:45 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 23:26 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 09:19 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 05:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 17:59 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 19:16 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 08:38 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 19:40 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 10:54 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 20:34 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 12:45 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 04:18 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 19:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 06:53 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-22 09:59 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-22 07:12 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-23 19:05 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-23 10:40 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 16:03 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 07:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 17:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 18:27 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:05 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:08 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:39 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 20:25 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 19:48 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 10:54 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 17:57 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-24 16:40 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:07 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-24 15:25 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 16:34 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:05 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 14:50 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-20 17:34 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 15:59 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:00 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 16:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:40 +0200
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-20 20:07 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:04 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:43 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-15 14:36 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 18:15 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:23 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:51 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:25 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:33 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 21:54 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:56 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-24 15:53 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 15:07 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 09:21 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:24 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 11:23 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:02 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:13 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:09 -0700
Re: What does this code print ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-25 23:55 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:01 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:15 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:12 -0700
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-19 14:43 -0700 |
| Message-ID | <ugs7tb$j12c$1@dont-email.me> |
| In reply to | #93316 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-14 15:54 +0200 |
| Message-ID | <uge6j1$3spt4$4@dont-email.me> |
| In reply to | #92777 |
Am 13.10.2023 um 18:34 schrieb Kaz Kylheku: > I don't believe it. ... Compile it with Godbolt and you see that the lambda is instantiated twice. > It's possible that inlining will render this consideration > moot, because if the function is inlined, then no actual calls are > happening, and there are no calling conventions. The function is called behind a volatile function pointer, so there's no inlining. Rest of your nonsense unread.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-14 18:05 +0000 |
| Message-ID | <20231014105829.590@kylheku.com> |
| In reply to | #92822 |
On 2023-10-14, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 13.10.2023 um 18:34 schrieb Kaz Kylheku: > >> I don't believe it. ... > > Compile it with Godbolt and you see that the lambda is instantiated > twice. To clarify, what I don't believe is the idea that the behavior you are seeing is documented and reliable. >> It's possible that inlining will render this consideration >> moot, because if the function is inlined, then no actual calls are >> happening, and there are no calling conventions. > > The function is called behind a volatile function pointer, so there's > no inlining. A volatile on a local variable whose address isn't taken, in a function where setjmp isn't being used, means approximately to nothing. The compiler is allowed to deduce that the pointer points to that lambda regardless of the volatile. > Rest of your nonsense unread. "Nonsense" like how different calling conventions are incompatible, making the code utter garbage where those keywords are not ignored. -- 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-14 14:58 -0400 |
| Message-ID | <ugeoc7$1gpne$1@i2pn2.org> |
| In reply to | #92832 |
On 10/14/23 2:05 PM, Kaz Kylheku wrote: > On 2023-10-14, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 13.10.2023 um 18:34 schrieb Kaz Kylheku: >> >>> I don't believe it. ... >> >> Compile it with Godbolt and you see that the lambda is instantiated >> twice. > > To clarify, what I don't believe is the idea that the behavior you are > seeing is documented and reliable. > >>> It's possible that inlining will render this consideration >>> moot, because if the function is inlined, then no actual calls are >>> happening, and there are no calling conventions. >> >> The function is called behind a volatile function pointer, so there's >> no inlining. > > A volatile on a local variable whose address isn't taken, in a function > where setjmp isn't being used, means approximately to nothing. The > compiler is allowed to deduce that the pointer points to that lambda > regardless of the volatile. I don't think that is true, The volatile modifier says that it might be changed/accessed by things beyond the implementations knowledge. The caller might well have passed the address of the future variable to some other actor, perhaps getting an interrupt when the variable was written and then doing something to it. > >> Rest of your nonsense unread. > > "Nonsense" like how different calling conventions are incompatible, > making the code utter garbage where those keywords are not ignored. >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 08:58 +0200 |
| Message-ID | <ugg2j5$cf8s$1@dont-email.me> |
| In reply to | #92832 |
Am 14.10.2023 um 20:05 schrieb Kaz Kylheku: > To clarify, what I don't believe is the idea that the behavior you are > seeing is documented and reliable. If MSVC supports that it won't drop that. clang-cl also supports that for a long time, but implemented that later than MSVC. > A volatile on a local variable whose address isn't taken, in a function > where setjmp isn't being used, means approximately to nothing. What a volatile does is compiler-dependent and both supporting compilers (MSVC, clang-cl) implemented that in a way that what I did works, i.e. the compiler couldn't inline the code.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2023-10-14 12:47 -0400 |
| Message-ID | <ugegmt$3uo8b$1@dont-email.me> |
| In reply to | #92704 |
On 10/13/23 2:50 AM, Bonita Montero wrote:
> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> #include <iostream>
>>>>
>>>> using namespace std;
>>>>
>>>> int main()
>>>> {
>>>> auto lambda = []( int a ) -> int
>>>> {
>>>> thread_local int i = 0;
>>>> return i++ + a;
>>>> };
>>>> int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>> int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>> cout << pFnFastcall( 10 ) << endl;
>>>> cout << pFnStdcall( 9 ) << endl;
>>>> }
>>>>
>>>> Don't compile it yourself,
>>>
>>> An easy injunction to follow since it has syntax errors! Presumably
>>> those undeclared identifiers (or proprietary keywords?) have some
>>> meaning to your compiler.
>>>
>>>> just guess.
>>>
>>
>>
>> What is 10 * 10?
>> It's one hundred percent that the lovely Bonita is a troll.
>
>
> O.k., I'll explain it: the lambda is compiled twice for each cal-
> ling convention but in contrast to a generic lambda the thread
> local variable "i" exists only once for both "instantiations" !
> With a generic lambda there would be an "i" for each instanti-
> ation of the lambda's calling operator. I thought the people
> here should be able to think about that without compiling the
> code.
> And you call that trolling ...
Can you point to any words in the standard that allows the lambda
expression to get "recompiled" for different calling conventions?
Since the lambda has no "auto" parameters, it is NOT a "generic" lambda
that gets recompiled under different usages, so I am not sure what basis
you have to claim the ability to "compile" it generically.
This might just be a common extension.
The fact that others have pointed out that when compiling for current
operating systems, the common compilers that understand those reserved
symbols point out that they are just ignored.
Did you actually look at the generated code to see that it in fact DID
get generated twice? or are you just guessing (perhaps wrongly) as you
seem to do so often.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 09:07 +0200 |
| Message-ID | <ugg33f$cf8s$3@dont-email.me> |
| In reply to | #92831 |
Am 14.10.2023 um 18:47 schrieb Richard Damon: > Can you point to any words in the standard that allows the lambda > expression to get "recompiled" for different calling conventions? MSVC and clang-cl do that. > Since the lambda has no "auto" parameters, it is NOT a "generic" lambda > that gets recompiled under different usages, ... I didn't say that it is generic but there's an opposite analogy to generic lambdas that thread local and shared variables are shared among the different instantiations for different calling conventions. > The fact that others have pointed out that when compiling for current > operating systems, the common compilers that understand those reserved > symbols point out that they are just ignored. 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. > Did you actually look at the generated code to see that it in fact DID > get generated twice? ... Yes, and as I said both pointers have different addresses.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 09:12 +0200 |
| Message-ID | <ugg3c2$ckp0$1@dont-email.me> |
| In reply to | #92841 |
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
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 09:16 +0200 |
| Message-ID | <ugg3l3$cmg4$1@dont-email.me> |
| In reply to | #92843 |
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>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-15 13:35 -0400 |
| Message-ID | <ugh7s8$1k9qh$3@i2pn2.org> |
| In reply to | #92844 |
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. just different instances of the invoking of it, not two different "instances" of the lambda function.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-17 07:48 +0200 |
| Message-ID | <ugl77t$2pe6u$2@dont-email.me> |
| In reply to | #92863 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-17 23:04 -0400 |
| Message-ID | <ugnhvc$1t8hq$1@i2pn2.org> |
| In reply to | #92904 |
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"
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-19 19:58 +0200 |
| Message-ID | <ugrqo2$fsmt$1@dont-email.me> |
| In reply to | #93130 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-19 14:39 -0400 |
| Message-ID | <ugrt5f$238ca$2@i2pn2.org> |
| In reply to | #94112 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-19 19:58 +0200 |
| Message-ID | <ugrqok$fto1$1@dont-email.me> |
| In reply to | #93130 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-19 18:06 +0000 |
| Message-ID | <20231019110532.810@kylheku.com> |
| In reply to | #94113 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-19 20:11 +0200 |
| Message-ID | <ugrrh1$fto1$4@dont-email.me> |
| In reply to | #94116 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-19 19:20 +0000 |
| Message-ID | <20231019120451.638@kylheku.com> |
| In reply to | #94118 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-19 16:06 -0400 |
| Message-ID | <ugs28l$238c9$2@i2pn2.org> |
| In reply to | #94121 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-19 14:45 -0700 |
| Message-ID | <ugs82g$j12c$2@dont-email.me> |
| In reply to | #94121 |
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?
>
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web