C++: Coroutine lambdas and the incomplete closure type

[Arsen Arsenović via Gcc]

Hi!

Currently, I'm looking at PR115731.  To summarize the issue, it is
possible for the user to, through coroutines, observe the closure type
of a lambda before it is completed.  This closure type, in GCC, is
started before and finished after parsing the lambda body, meaning that
it is incomplete during the parsing (and finishing) the lambda
operator().  As a result, when we attempt to resolve the promise type of
the coroutine, we can get an incomplete type error (as in the testcase
in the PR).

I was originally intending to defer expansion of CO_*_EXPRs up until
finishing the lambda operator(), by finishing the struct after pruning
captures and then expanding CO_*_EXPRs with a tree-walk, but this fails
because finishing the struct involves popping its binding level, but the
level stack contains the outermost binding level for the function at
that point.

I'm not sure if I can do that expansion later (defer it until after
finish_function (lambda_fn) or finish_struct (lambda_closure)) either
(in order to go back and recreate the CO_*_EXPRs in the lambda body, and
to "re-finish" the function, so that the coroutine transform gets
applied).

Is there a potential solution I am missing?  Can one of the proposals
above be implemented somehow?  What'd be the best thing to do?

TIA, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: v2.1 Draft for a lengthof paper

[Alejandro Colomar via Gcc]

[CC: s/gcc-patches@/gcc@/]

Hi Jens,

On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote:
> > However, strlen(3) came first, and we must respect it.
> 
> Sure,  string length, a dynamic feature, and array length are two features.

(Except that I've seen --and also written myself-- also string lengths
 that are constant expressions).

#define STRLEN(s)  (NITEMS(s) - 1)

But that's unimportant.  I'm more worried about:

ssize_t
strtcpy(char *restrict dst, const char *restrict src, size_t ndst)
{
booltrunc;
size_t  dlen, slen;

if (ndst == 0)
return -1;

slen = strnlen(src, ndst);
trunc = (slen == ndst);
dlen = slen - trunc;

stpcpy(mempcpy(dst, src, dlen), "");

if (trunc)
return -1;

return slen;
}

There should be a distinction between array length and string length.
If we call them both len, the names will be ambiguous.

> But we also have VLA and not VNEA in the standard, So we should respect this 
> ;-)

Okay.  (Although, when in doubt, I would favour strlen(3) because it's
older, and more stable.)  :-)

> > Since you haven't proposed eliminating "number of elements" from the
> > standard, and it would still be used alongside length, I think
> > elementsof() would be consistent with your view (consistent with "number
> > of elements").
> 
> didn't we ? Then this is actually a good idea to do so, thanks for the idea !

Number of elements also makes it consistent with the language used for
referring to the pointer to one after the last element of an array.
I think length and number of elements can coexist.  Even you had to use
it in your paper:

... We propose to consequently talk about

-  size when talking about size of a type or object in numbers of bytes
-  length when talking about the number of elements in an array.

I would say it's fine to use length if there's no ambiguity, but
number of elements in contexts where it could be ambiguous with strings.
That's already an improvement over the status quo (which is always
ambiguous, since an array always has both a length and a size).

Would you mind at least keeping "number of elements" for now, replacing
uses of size, and reconsidering the idea of removing "number of
elements" separately and only after that?  That would allow separate
discussion.  I'm in favour of the first but not the second.

> "elements of" is a stretch, linguistically, because you don't mean  the
> elements themselves, you are referring to their number. "elementsof" for
> me would refer to a list of these elements.

We could call it nelementsof(), or neltsof().  neltsof() is shorter,
so I like it better.  (alignof() is already a contraction of
alignmentof(), for prior art in contracting names in operators.)

> > Alternatively, you could use a new term, for example extent, for
> > referring to the number of elements of an array.  That would be more
> > respectful to strlen(3), keeping a strong distinction between string
> > length and array **.
> 
> Only that this separation doesn't exist, even now, as said, it is called
> "variable length array"

I guess VLA is already a common enough term that I guess it's blessed.
How do you feel about using it when it's unambiguous, but using number
of elements when it could be ambiguous?

But so is the expression "one past the last element of an array".  Both
notations should be able to coexist.

It's not like the problem with size, which is never unambiguous.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: stack arenas using alloca

[Michael Clark via Gcc]

Hi Folks,

*sending again with Thunderbird because Apple Mail munged the message*.

I wanted to share a seed of an idea I have been ruminating on for a 
while, and that is being able to return alloca memory from a function.


I think it’s trivially possible by hacking the epilogue to unlink the 
frame  pointer but not pop the stack. Stack traces should work fine and 
it just looks like the parent function called an alloca which covers the 
fixed child frame and the alloca that it returned.


I tend to use alloca quite a lot in my programming style because I like 
to avoid the heap. I have a style where I run a loop with a size pass, 
then call alloca, then run the loop again without suppressing writes. I 
would like to be able to return, initially, one alloca to a parent 
function, but more than one should also be possible.


I haven't thought a lot about the mechanics of how one might signal to 
the compiler to suppress popping the stack, but I imagined one could 
return a pointer or structure with _Stack qualifiers to signal that 
stack memory from the child frame is being returned.


This is just a quick note as there is a deeper conversation about 
compacting stack arenas that would be possible if one had a runtime 
*and* compile time reflection API for frame metadata, where the frame is 
expressed as an anonymous C structure perhaps accessible via a function 
on a reference to a function. If you had frame metadata, you could emit 
one or many memmove calls. trivially one just needs the fixed frame 
length to recover the fixed frame stack memory and with full frame 
reflection, it would be possible to defer to a runtime routine in the 
case two or more stack pointers are returned, assuming the compiler 
tracks sizes of alloca calls. Ideally, the reflection API would also be 
constexpr-able meaning the runtime compaction could be inlined. This 
won't work for types that have pointers unless one has a full 
single-thread compacting GC that uses type metadata, but I tend to use 
indices. But unlike heap compaction, it doesn't have to worry about races.


The beauty of stack arenas, and compacting stack arenas, as a subtype, 
are many. Firstly the memory has no thread aliasing issues unlike heap 
memory, meaning analysis is much simpler and there are no pause issues 
like there are for GC. Secondly, it would be quite a neat way to 
constexpr variable-length arrays or a _List type because, unlike malloc, 
it’s much easier to reason about.


I have a relatively complete C reflection API that could be used as a 
starting point for C reflection. It currently works as an LLVM plugin. I 
am not sure how I would do this in GCC. A Python parser came to mind but 
it would be better if it somehow ran inside the compiler. It would also 
be great to have access to the frame of a function as an anonymous 
structure. It’s only runtime at present and it could benefit from a for 
comprehension because looping on variable length lists is a little 
clumsy. If I could return alloca memory in a structure that would 
largely solve this problem.


- https://github.com/michaeljclark/crefl

Regards,
Michael

v2.2 Draft for an elementsof paper

[Alejandro Colomar via Gcc]

[To: s/gcc-patches/gcc/] 

Hi,

Attached is a new revision of the proposal for WG14 for adding an
elementsof() operator (both the man(7) source, and the generated PDF).

v2.2:

-  Rename lengthof => elementsof.  Aaron found incompatible existing
   functions called lengthof() in the wild.

-  Require parens in ISO C.  Leave sizeof-like syntax as a (recommended)
   QoI detail.  It should give more freedom to implementations to start
   with something simple, if they need it.  [Jens]

-  Document prior art in C and C++.  [Jens, Aaron]

-  Document a rationale for the naming choice.  [Jens, Aaron]

-  Document backwards compatiblity.  [Jens, Aaron]

-  Document why we don't propose an uglified name.  [Jens]

-  Add a few specific questions for WG14.  [Jens]

Have a lovely day!
Alex

-- 



elementsof.man
Description: Unix manual page


elementsof.pdf
Description: Adobe PDF document


signature.asc
Description: PGP signature

Re: gcc-regression script build fail info

[Sam James via Gcc]

"Jiang, Haochen"  writes:

> Ping for this thread.
>
> Any ideas? If no, I will change the generated info with command following
> if we take r15-1643 as example and see if it is clearer:
>
> head -26 makelog.r15-1643.x86_64.native | tail -7 > 1.log;
> grep -E "(error:|Error)" makelog.r15-1643.x86_64.native >> 1.log;
> echo " Detailed Info around error (+- 10 Lines) 
> " >> 1.log;
> grep -C 10 -E "error:" makelog.r15-1643.x86_64.native >> 1.log;
>

This plan sounds good to me, although I was hoping someone might speak
up ;)

I will keep an eye on the failures afterwards and then see if it looks
OK too.

(Sorry if you were waiting on me, I may have misunderstood.)

> Thx,
> Haochen
>
>> -Original Message-
>> From: Jiang, Haochen
>> Sent: Thursday, July 18, 2024 3:57 PM
>> To: 'Sam James' 
>> Cc: 'gcc-regress...@gcc.gnu.org' ; 'gcc-
>> testresu...@gcc.gnu.org' ; 'gcc@gcc.gnu.org'
>> 
>> Subject: RE: gcc-regression script build fail info
>> 
>> 
>> 
>> > -Original Message-
>> > From: Jiang, Haochen
>> > Sent: Thursday, July 18, 2024 3:46 PM
>> > To: 'Sam James' 
>> > Cc: 'gcc-regress...@gcc.gnu.org' ; 'gcc-
>> > testresu...@gcc.gnu.org' ; gcc@gcc.gnu.org
>> > Subject: gcc-regression script build fail info
>> >
>> > > > For future reports, would it be possible to change the grep to
>> > > > something
>> > > > like:
>> > > >
>> > > > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
>> > > >
>> > > > This would allow catching the actual compile error in libbacktrace
>> > > > if it's not going to fit in the last N lines from make.
>> > >
>> > > Hi Sam,
>> > >
>> > > Let me change that in the script and see if it is much clearer.
>> > >
>> > > This bug report definitely seems not clear for me also.
>> >
>> > Hi all,
>> >
>> > Sam just mentioned in another thread that the current log for build fail in
>> gcc-
>> > regression is not clear at all, like the problem in:
>> > https://gcc.gnu.org/pipermail/gcc-regression/2024-July/080272.html
>> > The 100 bottom line didn't give any info for why it runs into a build fail.
>> >
>> > As Sam suggested, we might change the build fail info part which is 
>> > currently
>> > using 'tail -100' to 'grep -E "(error:|Error)"' to get some clear info.
>> >
>> > Does any one still needs the 'tail -100' for some more info? Or if the 
>> > output
>> for
>> > 'grep -E "(error:|Error)" is enough?
>> >
>> > For example, for r15-2116, overall report will be:
>> 
>> Made a typo here, the report is generated from r15-1643.
>> 
>> >
>> > make[2]: Entering directory '/home/haochenj/src/gcc-regression'
>> > rm -rf bld
>> > mkdir -p bld
>> > cd bld; \
>> >  RUNTESTFLAGS="--target_board='unix{-m32,}'" ../src-master/configure \
>> > --with-arch=native --with-cpu=native --enable-clocale=gnu --with-
>> system-
>> > zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --
>> > prefix=/usr/gcc-15.0.0 --with-fpmath=sse checking build system type...
>> > x86_64-pc-linux-gnu
>> > grep "Error " makelog.r15-1643.x86_64.native >> makelog.r15-
>> > 1643.x86_64.native.mail; \
>> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > make[6]: [Makefile:1831: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
>> 1
>> > (ignored)
>> > ../../src-master/gcc/config/i386/i386.cc:107:12: error: 'rtx_def*
>> > legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never 
>> > defined [-
>> > Werror=unused-function]
>> > ../../src-master/gcc/config/i386/i386.cc:108:12: error: 'rtx_def*
>> > legitimize_pe_coff_extern_decl(rtx, bool)' declared 'static' but never 
>> > defined
>> [-
>> > Werror=unused-function]
>> > make[6]: *** [Makefile:2557: i386.o] Error 1
>> > make[5]: *** [Makefile:5108: all-stage2-gcc] Error 2
>> > make[4]: *** [Makefile:30031: stage2-bubble] Error 2
>> > make[3]: *** [Makefile:30275: bootstrap] Error 2
>> > make[2]: *** [Makefile:313: bootstrap] Error 2
>> > make[1]: *** [Makefile:409: one] Error 1
>> > make: *** [Makefile:406: one-master] Error 2
>> >
>> > Thx,
>> > Haochen
>> >
>> > >
>> > > Thx,
>> > > Haochen
>> > >
>> > > >
>> > > > (Not needed here as ILT already fixed the issue on master).
>> > > >
>> > > > thanks,
>> > > > sam


signature.asc
Description: PGP signature

RE: gcc-regression script build fail info

[Jiang, Haochen via Gcc]

> -Original Message-
> From: Sam James 
> Sent: Thursday, August 15, 2024 6:30 AM
> To: Jiang, Haochen 
> Cc: gcc-regress...@gcc.gnu.org; gcc-testresu...@gcc.gnu.org;
> gcc@gcc.gnu.org
> Subject: Re: gcc-regression script build fail info
> 
> "Jiang, Haochen"  writes:
> 
> > Ping for this thread.
> >
> > Any ideas? If no, I will change the generated info with command
> > following if we take r15-1643 as example and see if it is clearer:
> >
> > head -26 makelog.r15-1643.x86_64.native | tail -7 > 1.log; grep -E
> > "(error:|Error)" makelog.r15-1643.x86_64.native >> 1.log; echo
> > " Detailed Info around error (+- 10 Lines)
> > " >> 1.log; grep -C 10 -E "error:"
> > makelog.r15-1643.x86_64.native >> 1.log;
> >
> 
> This plan sounds good to me, although I was hoping someone might speak
> up ;)
> 
> I will keep an eye on the failures afterwards and then see if it looks OK too.
> 
> (Sorry if you were waiting on me, I may have misunderstood.)
> 

I have changed the command to the mentioned one for normal and ia32 build
while keeping the native build as unchanged for comparison and prevent
something went wrong for the change. (I suppose it won't break but in case I did
some typo.)

Thx,
Haochen