Re: [PATCH v2] libstdc++: Add lvalue overload for generator::yield_value

ad > taking lvalue element_of view, as per LWG 3899. > * testsuite/24_iterators/range_generators/lwg3899.cc: New test. > --- > > Added a testcase (thanks to Arsen). > > Tested x86_64-linux. > LGTM also, assuming the test still passes :-) Thank you again! -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] d, v2: give dependency files better filenames

Jakub Jelinek writes: > On Sun, Jan 12, 2025 at 04:16:58PM +0100, Arsen Arsenović wrote: >> Regstrapped on x86_64-pc-linux-gnu. I've also checked the generated >> dependency files are correct by hand and "instrumented" the build to >> fail if two depende

[PATCH] gcc/d: give dependency files better filenames

Regstrapped on x86_64-pc-linux-gnu. I've also checked the generated dependency files are correct by hand and "instrumented" the build to fail if two dependency files are the same, by doing the following: DPOSTCOMPILE = ! test -f $(DEPFILE).Po && mv ... ... and confirmed no further conflicts of

Ping: [PATCH] jit: Install jit headers in $(libsubincludedir) [PR 101491]

$(DESTDIR)$(includedir)/libgccjit.h > + $(DESTDIR)$(libsubincludedir)/libgccjit.h > $(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \ > - $(DESTDIR)$(includedir)/libgccjit++.h > + $(DESTDIR)$(libsubincludedir)/libgccjit++.h > > ifneq (,$(findstring mingw,$(target))) > jit.install-common: installdirs jit.install-headers -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH 2/2] libstdc++: add missing return in generator assignment operator [PR118196]

libstdc++-v3/ChangeLog: PR libstdc++/118196 * include/std/generator (generator::operator=(generator)): Add missing 'return *this;'. * testsuite/24_iterators/range_generators/move-assign-missing-return.C: New test. --- libstdc++-v3/include/std/generator

[PATCH 1/2] libstdc++: don't implicit-construct _Yielded_decvref [PR118022]

Evening! This patchset includes fixes for two bugs in libstdc++s implementation of std::generator, namely PR118196 and PR118022. There's little to note about these fixes. Tested on x86_64-pc-linux-gnu via 'make -j17 check' with 'set v3_std_list { 98 11 14 17 20 23 26 }' in the libstdc++ build di

Re: [PATCH] libstdc++: Add lvalue overload for generator::yield_value

doesn't count invocations of allocate(), rather only sizes, so I'd need to write a new allocator). In the text above, -I . adds a with your patch applied into the include path. In the future, the extra allocation of the general range might be removed, but it's probably OK to rely on it for the test for now. Thanks for the patch. Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] install.texi --enable-languages: add rust to the list of languages

expose it to all the users. As at now the > rust FE is still in early development and it's not useful for compiling > any real rust programs. That might've been why it was omitted in the first place - CCing in gcc-rust@ to see if anyone knows (in either case, it'd be

Re: [PATCH v2] libstdc++: Remove constraints on std::generator::promise_type::operator new

Jonathan Wakely writes: > Here's a v2 patch that adds the static assert messages and now also > tests allocation for member coroutines (with implicit and explicit > object parameters). > > [2. text/plain; patch.txt]... This revision looks good. Thanks! :-) Have a l

Re: [PATCH] libstdc++: Remove constraints on std::generator::promise_type::operator new

ct. Yes, I think 'coroutine argument' is OK - this function is only called for allocating the coroutine state when a coroutine is starting, so it can't be anything else (well, unless the user does the call manually for some reason..). -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] libstdc++: Remove constraints on std::generator::promise_type::operator new

new >> +// should not be constrained >> + >> +#include >> +#include >> + >> +std::pmr::generator >> +bar(std::allocator_arg_t, std::pmr::memory_resource& mr) // { dg-error >> "here" } >> +{ >> + co_yield 3; >> +}

Re: [PATCH] libstdc++: Remove constraints on std::generator::promise_type::operator new

s() == 0); > + > + for (auto _ : gen(std::allocator_arg , &mr)) > +VERIFY(mr.number_of_active_allocations() == 1); > + > + for (auto _ : gen("const This& argument", std::allocator_arg , &mr)) > +VERIFY(mr.number_of_active_allocations() == 1);

Re: [PATCH 2/2] c++/coroutines: handle (new-)extended alignment [PR104177]

Jason Merrill writes: > On 9/18/24 4:36 PM, Arsen Arsenović wrote: >> This patch implements support for frames and promises with new-extended >> alignment. >> There are two kinds of alignment to worry about here: >> - Promise alignment, which causes "in

Stage 1 patch ping (D, C++, libstdc++, toplevel, driver)

ch Thanks in advance! Have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] doc/cpp: Document __has_include_next

Joseph Myers writes: > On Fri, 18 Oct 2024, Arsen Arsenović wrote: > >> -The @code{__has_include} operator by itself, without any @var{operand} or >> -parentheses, acts as a predefined macro so that support for it can be tested >> -in portable code. Thus, the recommende

Ping^2: [PATCH] doc/cpp: Document __has_include_next

Gentle ping on this patch again. TIA, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] doc/cpp: Document __has_include_next

Hi! Arsen Arsenović writes: > OK for trunk? Seems to build and render fine with makeinfo --info and > --html. Typesetting it, I see overfull and underfull hboxes, but I > suspect these were here for a while.. Gentle ping on this patch. TIA, have a lovely day. -- Arsen

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

reRevsFile > .git-blame-ignore-revs' unfortunately though. This can be done in gcc-git-customization.sh. > I believe we should do this regardless of which direction we go in wrt tab. I agree, it should eliminate the blame concern with untabifying, I think. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

Jakub Jelinek writes: > On Fri, Oct 25, 2024 at 01:25:25PM +0200, Arsen Arsenović wrote: >> Maybe we should go the other way around? Compressing eight spaces into >> a tab leads to strange artifacts in diffs (where lines appear >> misindented because some were aligned by ta

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

Jonathan Wakely writes: > On Fri, 25 Oct 2024 at 12:54, Jakub Jelinek wrote: >> >> On Fri, Oct 25, 2024 at 01:25:25PM +0200, Arsen Arsenović wrote: >> > Maybe we should go the other way around? Compressing eight spaces into >> > a tab leads to strange artif

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

take up less disk space; I do not think this is a real issue nowadays WDYT? Am I missing something? TIA, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH] doc/cpp: Document __has_include_next

OK for trunk? Seems to build and render fine with makeinfo --info and --html. Typesetting it, I see overfull and underfull hboxes, but I suspect these were here for a while.. -- >8 -- While hacking on an unrelated change, I noticed that __has_include_next hasn't been documented at

Re: [PATCH] Add 'cobol' to Makefile.def

lib-check-target=check-target-libphobos; }; > languages = { language=jit; gcc-check-target=check-jit; }; > languages = { language=rust; gcc-check-target=check-rust; }; > +languages = { language=cobol;gcc-check-target=check-cobol; > + lib-check-target=check-target-libgcobol; }; > > // Toplevel bootstrap > bootstrap_stage = { id=1 ; }; -- Arsen Arsenović signature.asc Description: PGP signature

C++ ping: [PATCH 0/2] Support for coroutine frames with new-extended alignment

Arsen Arsenović writes: > This patch series implements support for coroutines whose frames require > alignment. > > The standard currently does not specify much about this case AFAICT, so > we can do this for now (until P2014 progresses). > > The new dump was useful for

Ping: [PATCH] d,ada/spec: only sub nostd{inc,lib} rather than nostd{inc,lib}*

Ping on this patch. TIA, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] libstdc++: Enable _GLIBCXX_ASSERTIONS by default for -O0 [PR112808]

generate. >> * include/bits/c++config [!__OPTIMIZE__] (_GLIBCXX_ASSERTIONS): >> Define for unoptimized builds. > > LGTM. At -O0 the additional overhead of the assertions would be > relatively small compared to the overhead of -O0 itself. On that note, maybe we could add a __OPTIMIZE_DEBUG__ or similar so that we can do a similar thing for -Og (which some use for their development cycle). -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH] c++/coro: ignore cleanup_point_exprs while expanding awaits [PR116793]

Tested on x86_64-pc-linux-gnu. OK for trunk? TIA -- >8 -- If we reach a CLEANUP_POINT_EXPR while trying to walk statements, we actually care about the statement or statement list contained within it. Indeed, such a construction started happening with r15-3513-g964577c31df206, aft

Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]

ould a flag which has a variable part in the name (like ffree-line-length-...) get matched? i.e. what would we need to emit for it to be linked correctly? This impacts what the right solution is. TIA, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] doc: Remove @code wrapping of fortran option names [PR116801]

ength-@var{n} >>> >>> Shouldn't all the @var{...} parts be dropped as well, throughout? >> >> We have it all over the other manuals: > > But it causes them to not show up in the urls files. That seems like a defect of the regen script rather than of the manuals. They're there for a reason (signifying that something is not a fixed string). -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH v2 1/2] c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]

Arsen Arsenović writes: > Okay, these patch should work correctly in all cases, at least all I > could think of. The first patch is unchanged, the second one is simpler > than it was before, I think. Ah, and of course: tested on x86_64-pc-linux-gnu, OK for trunk? -- Arsen

[PATCH v2 1/2] c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]

Okay, these patch should work correctly in all cases, at least all I could think of. The first patch is unchanged, the second one is simpler than it was before, I think. -- >8 -- If such a diagnostic is necessary, it has already been emitted, otherwise, it is not correct and emitti

[PATCH v2 2/2] c++: simplify handling implicit INDIRECT_REF and co_await in convert_to_void

convert_to_void has, so far, when converting a co_await expression to void altered the await_resume expression of a co_await so that it is also converted to void. This meant that the type of the await_resume expression, which is also supposed to be the type of the whole co_await expression, was no

Ping^3: [PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

Arsen Arsenović writes: > Gentle ping again. Full patch: > https://inbox.sourceware.org/gcc-patches/86y14ptvdi@aarsen.me/ And again. To clarify, the above is a v2 of sorts (it has the comment fixed, I just didn't update the subject). TIA, have a lovely day. -- Arse

[PATCH 2/2] c++/coroutines: handle (new-)extended alignment [PR104177]

This patch implements support for frames and promises with new-extended alignment. There are two kinds of alignment to worry about here: - Promise alignment, which causes "internal" padding inside the frame struct. The reason this is a problem is because the (yet to be formalized, but agreed

[PATCH 0/2] Support for coroutine frames with new-extended alignment

patchset also depends on Iains ramp rework patch, so will be pushed after. Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a most lovely evening. Arsen Arsenović (2): c++: Implement a coroutine language debug dump c++/coroutines: handle (new-)extended alignment [PR104177] gcc/c-family/c

[PATCH 1/2] c++: Implement a coroutine language debug dump

This provides to people working on coroutines, as well as writing tests for coroutines, a way to have insight into the results and inputs of the coroutine transformation passes, which is quite essential to understanding what happens in the coroutine transformation. Currently, the information dumpe

Re: [PATCH] ltmain.sh: Fix typos

there, I think. -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH] libstdc++: Enable most of for freestanding

if // C++20 > @@ -3358,7 +3372,7 @@ namespace __detail > _GLIBCXX_END_NAMESPACE_VERSION > } // namespace std > > -#if __cplusplus >= 202002L > +#if __cplusplus >= 202002L && _GLIBCXX_HOSTED > # include > #endif > > diff --git a/libstdc++-v3/testsuite/

Ping: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

ne (and hence not being too >> informative) - but I haven't debugged that (as I assumed the diagnostic >> code is DTRT now). > > It seems weird to lose the "...to here" marking on the return. Any thoughts, > David? Gentle ping on this patch/question. TIA, have a lovely night. -- Arsen Arsenović signature.asc Description: PGP signature

Re: Is it possible to get an old posed Patch from gcc-patches archive??

get the message ID from a meta tag header, it is in an In-Reply-To in the HTML file, and then give it to public-inbox) Hope that helps, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

Ping^2: [PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

Evening, Arsen Arsenović writes: > [[PGP Signed Part:Good signature from 52C294301EA2C493 Arsen Arsenović > (trust ultimate) created at 2024-08-28T23:00:44+0200 > using EDDSA]] > Hi, > > Arsen Arsenović writes: > >>> The && should not be left of t

[pushed] c++: add a testcase for [PR 108620]

Pushed as obvious. -- >8 -- Fixed by r15-2540-g32e678b2ed7521. Add a testcase, as the original ones do not cover this particular failure mode. gcc/testsuite/ChangeLog: PR c++/108620 * g++.dg/coroutines/pr108620.C: New test. --- gcc/testsuite/g++.dg/coroutines/pr1

[PATCH] coros: mark .CO_YIELD as LEAF [PR106973]

Tested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- We rely on .CO_YIELD calls being followed by an assignment (optionally) and then a switch/if in the same basic block. This implies that a .CO_YIELD can never end a block. However, since a call to .CO_YIELD is still a call, if

[PATCH] d, ada/spec: only sub nostd{inc, lib} rather than nostd{inc, lib}*

Tested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- This prevents the gcc driver erroneously accepting -nostdlib++ when it should not when Ada was enabled. Also, similarly, -nostdinc* (where * is nonempty) is unhandled by either the Ada or D compiler, so the spec should not subs

Re: [PATCH 3/3] c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]

Jason Merrill writes: > On 8/28/24 3:59 PM, Arsen Arsenović wrote: >> Hm, maybe-unused-1.C should be moved into the previous patch. Could do >> before pushing. > > Let's combine these three into a single patch, they're all small and closely > related. Sure,

Re: [PATCH 1/3] c++: stop altering co_awaits converted to void

Jason Merrill writes: > On 8/28/24 3:59 PM, Arsen Arsenović wrote: >> This patch fixes a gcc-15 regression (PR116502) and an inelegance in my >> earlier patch related to converting CO_AWAIT_EXPRs to void. >> This wasn't noticed anywhere AFAICT, but it was a bit unf

Ping: [PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

Hi, Arsen Arsenović writes: >> The && should not be left of the =; if the initializer needs to span multiple >> lines, it's usually best to wrap it in (). > > Okay - done. [...] >>> + foo::operator delete (new (123, true) foo, 123, true); >>&g

[PATCH 3/3] c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]

Hm, maybe-unused-1.C should be moved into the previous patch. Could do before pushing. -- >8 -- If such a diagnostic is necessary, it has already been emitted, otherwise, it is not correct and emitting it here is inactionable by the user, and bogus. PR c++/116502 gcc/cp/C

[PATCH 2/3] c++: handle CO_AWAIT_EXPRs wrapped in INDIRECT_REF

Currently, GCC misses a diagnostic when discarding a CO_AWAIT_EXPR resulting in a reference type, because such an expression is wrapped in an INDIRECT_REF in finish_co_await_expr. Similar handling is necessary for CALL_EXPRs, so extend it to also handle CO_AWAIT_EXPR. gcc/cp/ChangeLog: *

[PATCH 1/3] c++: stop altering co_awaits converted to void

This patch fixes a gcc-15 regression (PR116502) and an inelegance in my earlier patch related to converting CO_AWAIT_EXPRs to void. This wasn't noticed anywhere AFAICT, but it was a bit unfortunate. The other two patches fix an actual regression as well as provide handling for converting INDIRECT

[PATCH] c++: don't remove labels during coro-early-expand-ifns [PR105104]

Regtested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- In some scenarios, it is possible for the CFG cleanup to cause one of the labels mentioned in CO_YIELD, which coro-early-expand-ifns intends to remove, to become part of some statement. As a result, when that label is remove

Re: [PATCH] c++/coroutines: fix actor cases not being added to the current switch [PR109867]

Jason Merrill writes: > On 8/1/24 12:48 PM, Arsen Arsenović wrote: >> Tested on x86_64-pc-linux-gnu, no regression. >> OK for trunk? >> TIA, have a lovely day. >> -- >8 -- >> Previously, we were building and inserting case_labels manually, w

Re: [PATCH] c++/coros: do not assume coros don't nest [PR113457]

Hi, Arsen Arsenović writes: > gcc/testsuite/ChangeLog: > > * g++.dg/coroutines/pr113457-1.C: New test. > * g++.dg/coroutines/pr113457.C: New test. Just noticed that pr113457.C actually has excess errors. Unsure how I didn't notice on initial testing (the r

Re: [PATCH] c++/coros: do not assume coros don't nest [PR113457]

g_assert if you prefer. No strong feelings in this instance. Thanks. -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH] c++/coros: do not assume coros don't nest [PR113457]

Tested against folly and cppcoro, currently regstrapping on x86_64-pc-linux-gnu. coroutine.exp and coro-torture.exp passed. OK for trunk? (after regstrap) -- >8 -- In the testcase presented in the PR, during template expansion, an tsubst of an operand causes a lambda coroutine to

Re: [PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

Jason Merrill writes: > On 8/2/24 4:36 PM, Arsen Arsenović wrote: >> I'm not 100% clear on what the semantics of the matching here are meant >> to be - AFAICT, an operator new/delete pair matches (after falling >> through the other cases) if all their components (besi

Re: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

Jason Merrill writes: > On 8/21/24 1:52 PM, Arsen Arsenović wrote: >> For clarity, here's the entire split-up patch I intend to push, if it >> looks OK. Tested on x86_64-pc-linux-gnu. >> I've renamed the field we've discussed and also a few parameters that

[PATCH v3 2/2] c++: improve diagnostic of 'return's in coroutines

We now point out why a function is a coroutine, and where (the first return) is in the function. gcc/cp/ChangeLog: * coroutines.cc (struct coroutine_info): Rename first_coro_keyword -> first_coro_expr. The former name is no longer accurate. (coro_promise_type_foun

[PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

For clarity, here's the entire split-up patch I intend to push, if it looks OK. Tested on x86_64-pc-linux-gnu. I've renamed the field we've discussed and also a few parameters that refer to 'kw' to be less specific. The code is functionally identical. OK for trunk? TIA, have a lovely day.

Ping^2: C++/ME patch ping

Hi, Pinging these patches again: - https://inbox.sourceware.org/20240807131613.526335-1-ar...@aarsen.me/ - https://inbox.sourceware.org/20240802211503.3992610-2-ar...@aarsen.me/ Thanks in advance, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH] gnat: fix lto-type-mismatch between C_Version_String and gnat_version_string [PR115917]

Reg-tested on x86_64-pc-linux-gnu with all languages and yes,rtl,extra checking. OK for trunk? TIA, have a lovely day. -- >8 -- gcc/ada/ChangeLog: PR ada/115917 * gnatvsn.ads: Add note about the duplication of this value in verrsion.c. * version.c

C++/ME patch ping

g the wrong people, unsure who's best to ping here) -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH v2] c++: improve diagnostic of 'return's in coroutines

Jason Merrill writes: > On 8/8/24 4:29 PM, Arsen Arsenović wrote: >> Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again, >> but I think they're bogus (I'll re-test on physical hardware before >> pushing if needed). >> I'm somewhat cu

[PATCH v2] c++: improve diagnostic of 'return's in coroutines

Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again, but I think they're bogus (I'll re-test on physical hardware before pushing if needed). I'm somewhat curious of we should do a similar change WRT RETURN_EXPRs in the C FE (currently, the C FE uses the operand location for its

Re: [PATCH] c++: improve diagnostic of 'return's in coroutines

Jason Merrill writes: > On 8/7/24 7:31 PM, Arsen Arsenović wrote: >> Enlargening the function-specific data block is not great. > > Indeed, I think it would be better to search DECL_SAVED_TREE for a RETURN_STMT > once we've decided to give an error. The tr

[PATCH] c++: improve diagnostic of 'return's in coroutines

Enlargening the function-specific data block is not great. I've considered changing the location of RETURN_STMT expressions to cover everything from the return expression to input_location after parsing the returned expr. The result of that is: test.cc:38:3: error: a ‘return’ statement is not al

[PATCH] coroutines: diagnose usage of alloca in coroutines

Tested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- We do not support it currently, and the resulting memory can only be used inside a single resumption, so best not confuse the user with it. PR c++/115858 - Incompatibility of coroutines and alloca() gcc/ChangeLog: PR

[PATCH] warn-access: ignore template parameters when matching operator new/delete [PR109224]

I'm not 100% clear on what the semantics of the matching here are meant to be - AFAICT, an operator new/delete pair matches (after falling through the other cases) if all their components (besides the actual operator name, of course) match, and the pair of actual operator names matches if one is a

[PATCH v2] c++/coroutines: check for members we use in handle_types [PR105475]

Jason Merrill writes: > I don't think these names need to mention "baselink", but I'm not strongly > against it. It doesn't fit with the rest of the codebase either, so I'll rename them. > A few other tweaks below: > >> @@ -90,6 +90,7 @@ struct GTY((for_user)) coroutine_info >> tree self_h_

Re: [PATCH] c++/coroutines: fix actor cases not being added to the current switch [PR109867]

Jason Merrill writes: > On 8/1/24 12:48 PM, Arsen Arsenović wrote: >> Tested on x86_64-pc-linux-gnu, no regression. >> OK for trunk? >> TIA, have a lovely day. >> -- >8 -- >> Previously, we were building and inserting case_labels manually, w

[PATCH] c++/coroutines: fix actor cases not being added to the current switch [PR109867]

Tested on x86_64-pc-linux-gnu, no regression. OK for trunk? TIA, have a lovely day. -- >8 -- Previously, we were building and inserting case_labels manually, which lead to them not being added into the currently running switch via c_add_case_label. This lead to false diagnostics

[PATCH] c++/coroutines: check for members we use in handle_types [PR105475]

Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a lovely day. -- >8 -- Currently, it is possible to ICE GCC by giving it sufficiently broken code, where sufficiently broken means a std::coroutine_handle missing a default on the promise_type template argument, and missing me

[PATCH v2] c++/coroutines: only defer expanding co_{await,return,yield} if dependent [PR112341]

Okay, I've reworked it, and it built and passed coroutine tests. Regstrapping overnight. Is the following OK with you? -- >8 -- By doing so, we can get diagnostics in template decls when we know we can. For instance, in the following: awaitable g(); template task f() {

Re: [PATCH] c++/coroutines: only defer expanding co_{await,return,yield} if dependent [PR112341]

Jason Merrill writes: > On 7/31/24 6:54 AM, Arsen Arsenović wrote: >> Tested on x86_64-pc-linux-gnu. OK for trunk? >> TIA, have a lovely day. >> -- >8 -- >> By doing so, we can get diagnostics in template decls when we know we >>

[PATCH] dir-locals: apply our C settings in C++ also

We haven't been applying our settings to our C++. This patch fixes that. Sadly, it seems that the only documented way to apply settings to multiple modes is to repeat them. I thought that we can provide a list of modes to apply, but that seems to not be the case (even thought it happened to work

[PATCH] c++/coroutines: only defer expanding co_{await, return, yield} if dependent [PR112341]

Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a lovely day. -- >8 -- By doing so, we can get diagnostics in template decls when we know we can. For instance, in the following: awaitable g(); template task f() { co_await g(); co_yield 1; co_return "fo

Re: [PATCH] c++: make BUILTIN_SOURCE_LOCATION follow DECL_RAMP_FN

Jason Merrill writes: > I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to specifically (it > doesn't match CP_BUILT_IN_SOURCE_LOCATION, for instance); let's just refer to > source_location. ACK - will reword. > On 7/29/24 8:20 AM, Arsen Arsenović wrote:

Re: [PATCH 1/2] c++: fix ICE on FUNCTION_DECLs inside coroutines [PR115906]

Jason Merrill writes: > On 7/29/24 8:18 AM, Arsen Arsenović wrote: >> When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it >> fails to account for the fact that FUNCTION_DECLs might be present, and >> later passes it to DECL_HAS_VALUE_EXPR_P. This

[PATCH] c++: make BUILTIN_SOURCE_LOCATION follow DECL_RAMP_FN

This fixes the value of current_function in compiler generated coroutine code. PR c++/110855 - std::source_location doesn't work with C++20 coroutine gcc/cp/ChangeLog: PR c++/110855 * cp-gimplify.cc (fold_builtin_source_location): Use the name of the DECL_RAMP_FN of the c

[PATCH 2/2] c++: diagnose usage of co_await and co_yield in default args [PR115906]

This is a partial fix for PR115906. Per [expr.await] 2s3, "An await-expression shall not appear in a default argument ([dcl.fct.default])". This patch introduces the diagnostic in that case, and in the case of a co_yield (as co_yield is defined in terms of co_await, so prerequisites of co_await h

[PATCH 1/2] c++: fix ICE on FUNCTION_DECLs inside coroutines [PR115906]

When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it fails to account for the fact that FUNCTION_DECLs might be present, and later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check failure in DECL_HAS_VALUE_EXPR_P: tree check: expected var_decl or parm_decl or resu

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

EXPR. When we discard a CO_AWAIT_EXPR, we can also just discard +the await_resume() call conveniently embedded within it. This results +in a [[nodiscard]] diagnostic that the PR noted was missing. gcc/cp/ChangeLog: Thanks again, have a lovely evening. -- Arsen Ar

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

Hi Jason, Thanks for the review. Jason Merrill writes: > On 7/23/24 7:41 PM, Arsen Arsenović wrote: >> co_await expressions are nearly calls to Awaitable::await_resume, and, >> as such, should inherit its nodiscard. A discarded co_await expression >> should, hence,

[PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

co_await expressions are nearly calls to Awaitable::await_resume, and, as such, should inherit its nodiscard. A discarded co_await expression should, hence, act as if its call to await_resume was discarded. CO_AWAIT_EXPR trees do conveniently contain the expression for calling await_resume in the

[PATCH 1/2] cp/coroutines: do not rewrite parameters in unevaluated contexts

It is possible to use parameters of a parent function of a lambda in unevaluated contexts without capturing them. By not capturing them, we work around the usual mechanism we use to prevent rewriting captured parameters. Prevent this by simply skipping rewrites in unevaluated contexts. Those won

[pushed] cp/coroutines: add a test for PR c++/103953

This PR seems to have been fixed by a fix for a seemingly unrelated PR. Lets add a regression test to make sure it stays fixed. PR c++/103953 - Leak of coroutine return object PR c++/103953 gcc/testsuite/ChangeLog: * g++.dg/coroutines/torture/pr103953.C: New test. Reviewed-by:

Ping^3: [PATCH 0/3] Recover in-tree libiconv build support

Arsen Arsenović writes: > Another gentle ping on this patch series. Could it be merged into > trunk? And another! Sorry about them being sparse - I was quite busy in the meanwhile. -- Arsen Arsenović signature.asc Description: PGP signature

Ping^2: [PATCH 0/3] Recover in-tree libiconv build support

Hi! Another gentle ping on this patch series. Could it be merged into trunk? TIA, have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature

Ping: [PATCH 0/3] Recover in-tree libiconv build support

Hi! Given that trunk is now GCC 15, it might be good to land this patch early. I will re-test it just in case after a rebase but, otherwise, OK for trunk? TIA, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

[PATCH 2/3] gitignore: ignore /libiconv*

ChangeLog: * .gitignore: Ignore /libiconv* as with other possibly-in-tree libs. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 93a16b0b950c..3528d9a115ee 100644 --- a/.gitignore +++ b/.gitignore @@ -70,3 +70,4 @@ stamp-* /gmp* /i

[PATCH 3/3] *: support in-tree libiconv again

ChangeLog: * Makefile.def: Inform gettext of our freshly-built libiconv. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac (LIBICONV_SIBLING): If an in-tree host libiconv is being built, set this variable to the path to libiconv.a (L

[PATCH 1/3] toplevel: don't override gettext-runtime/configure-discovered build args

ChangeLog: PR bootstrap/112534 * Makefile.def (host-gettext): Set all_args_override="". * Makefile.in: Regenerate. * Makefile.tpl (all--args): Define as a helper macro for computing extra arguments to make. (all): Use all--args over args. --- Makefil

[PATCH 0/3] Recover in-tree libiconv build support

with delivering these, I have, unfortunately, been busied by various external factors. Hopefully, it is not too late yet. Thanks in advance, have a lovely night! Arsen Arsenović (3): toplevel: don't override gettext-runtime/configure-discovered build args gitignore: ignore /lib

[pushed] libstdc++-v3: drop GCC Runtime Library Exception from gen tests

It was mistakenly added to these files. libstdc++-v3/ChangeLog: * testsuite/24_iterators/range_generators/01.cc: Drop GCC Runtime Library Exception. * testsuite/24_iterators/range_generators/02.cc: Drop GCC Runtime Library Exception. * testsuite/24_iterator

[PATCH 0/2] A few minor fixes in

From: Arsen Arsenović Afternoon! These couple of patches fix two minor issues in the generator implementation that were informally reported a while ago. Tested on x86_64-pc-linux-gnu. OK for trunk? TIA, have a lovely day! Arsen Arsenović (2): libstdc++: fix _V badname in libstdc++: fix

[PATCH 1/2] libstdc++: fix _V badname in

libstdc++-v3/ChangeLog: * include/std/generator: Fix _V badname. --- libstdc++-v3/include/std/generator | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/libstdc++-v3/include/std/generator b/libstdc++-v3/include/std/generator index 87983ee5e7c6..2d1d

[PATCH 2/2] libstdc++: fix generator iterator operator* return type

Per the standard, the return type of a generators ranges iterator op* should be the reference type rather than the yielded type. The yielded type was used here by mistake. libstdc++-v3/ChangeLog: * include/std/generator (generator::_Iterator::operator*): Fix return type.

Re: [PATCH 2/2] libstdc++: Handle encodings in localized chrono formatting [PR109162]

/io.cc > b/libstdc++-v3/testsuite/std/time/weekday_last/io.cc > index 6f76922195d..d069d857ff0 100644 > --- a/libstdc++-v3/testsuite/std/time/weekday_last/io.cc > +++ b/libstdc++-v3/testsuite/std/time/weekday_last/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year/io.cc > b/libstdc++-v3/testsuite/std/time/year/io.cc > index bcaa57faeb7..1bdc95ddbd1 100644 > --- a/libstdc++-v3/testsuite/std/time/year/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year_month/io.cc > b/libstdc++-v3/testsuite/std/time/year_month/io.cc > index 7bb3442e299..e7963d31ae6 100644 > --- a/libstdc++-v3/testsuite/std/time/year_month/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year_month/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year_month_day/io.cc > b/libstdc++-v3/testsuite/std/time/year_month_day/io.cc > index cb82ef3b612..e7dc60b9dea 100644 > --- a/libstdc++-v3/testsuite/std/time/year_month_day/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year_month_day/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year_month_day_last/io.cc > b/libstdc++-v3/testsuite/std/time/year_month_day_last/io.cc > index 3241536a2e6..a57e56a1805 100644 > --- a/libstdc++-v3/testsuite/std/time/year_month_day_last/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year_month_day_last/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year_month_weekday/io.cc > b/libstdc++-v3/testsuite/std/time/year_month_weekday/io.cc > index 65baf1d37ae..e9a5bee7666 100644 > --- a/libstdc++-v3/testsuite/std/time/year_month_weekday/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year_month_weekday/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/year_month_weekday_last/io.cc > b/libstdc++-v3/testsuite/std/time/year_month_weekday_last/io.cc > index 17f2244420d..fc2328ac001 100644 > --- a/libstdc++-v3/testsuite/std/time/year_month_weekday_last/io.cc > +++ b/libstdc++-v3/testsuite/std/time/year_month_weekday_last/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-namedlocale "fr_FR.ISO8859-15" } > // { dg-timeout-factor 2 } > diff --git a/libstdc++-v3/testsuite/std/time/zoned_time/1.cc > b/libstdc++-v3/testsuite/std/time/zoned_time/1.cc > index 1623aca1c7a..e773f50ae73 100644 > --- a/libstdc++-v3/testsuite/std/time/zoned_time/1.cc > +++ b/libstdc++-v3/testsuite/std/time/zoned_time/1.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-effective-target tzdb } > // { dg-require-effective-target cxx11_abi } > diff --git a/libstdc++-v3/testsuite/std/time/zoned_time/io.cc > b/libstdc++-v3/testsuite/std/time/zoned_time/io.cc > index 376b2734f19..c19e2a3c882 100644 > --- a/libstdc++-v3/testsuite/std/time/zoned_time/io.cc > +++ b/libstdc++-v3/testsuite/std/time/zoned_time/io.cc > @@ -1,3 +1,4 @@ > +// { dg-options "-lstdc++exp" { target c++23 } } > // { dg-do run { target c++20 } } > // { dg-require-effective-target cxx11_abi } > // { dg-timeout-factor 2 } -- Arsen Arsenović

Ping^2: [PATCH] toplevel: don't override gettext-runtime/configure-discovered build args

Evening folks, Hope you had wonderful holidays. Gentle ping on this patch. Have a lovely night! -- Arsen Arsenović signature.asc Description: PGP signature

Re: [PATCH wwwdocs 1/1] gcc-14: document P1689R5 scanning output support

;ve added it to my subject, hopefully that works. Have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature

  1   2   3   4   >