Re: [PATCH v4] c++: DR2237, cdtor and template-id tweaks [PR107126]

On 2/9/24 18:46, Marek Polacek wrote: On Fri, Feb 09, 2024 at 10:20:04AM -0500, Jason Merrill wrote: On 2/8/24 16:26, Marek Polacek wrote: This patch does *not* fix where the C++20 diagnostic is missing altogether. What would it take to

[PATCH v4] c++: DR2237, cdtor and template-id tweaks [PR107126]

On Fri, Feb 09, 2024 at 10:20:04AM -0500, Jason Merrill wrote: > On 2/8/24 16:26, Marek Polacek wrote: > > This patch does *not* fix > > > > where the C++20 diagnostic is missing altogether. > > What would it take to fix that as well? It's

Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

> On 9 Feb 2024, at 10:56, Iain Sandoe wrote: >> On 8 Feb 2024, at 21:44, Jason Merrill wrote: >> >> On 2/8/24 12:55, Paolo Bonzini wrote: >>> On 2/8/24 18:16, Jason Merrill wrote: >> > > Hmm. In stage 1, when we build with the system gcc, I'd think we want > the

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

On Fri, 2 Feb 2024, Florian Weimer wrote: > +Certain warnings are now errors That's quite a nice description, thank you, Florian! > +The initial ISO C standard and its 1999 revision removed support for May I suggest to wrap paragraphs in ...? Not strictly necessary any more, now that we

Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib

On Fri, 9 Feb 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk? > > I'll try to reduce and add testcases overnight for these separate bugs > before pushing. > > -- >8 -- > > Building modular fmtlib triggered two small modules bugs in

Re: [PATCH] c++: avoid name lookup during mangling

On Fri, 9 Feb 2024, Jason Merrill wrote: > On 2/9/24 11:55, Patrick Palka wrote: > > On Fri, 9 Feb 2024, Jason Merrill wrote: > > > > > On 2/9/24 10:51, Patrick Palka wrote: > > > > It turns out that with modules we can call mangle_decl recursively, > > > > which is a problem because the global

[PATCH 2/2] c++/modules: ICE with modular fmtlib

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I'll try to reduce and add testcases overnight for these separate bugs before pushing. -- >8 -- Building modular fmtlib triggered two small modules bugs in C++23 and C++26 mode respectively (due to libstdc++ header

[PATCH 1/2] c++/modules: reduce lazy loading recursion

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk -- >8 -- It turns out that with modules we can call mangle_decl recursively, which is a problem because the global mangling state isn't recursion aware. The recursion happens from write_closure_type_name, which calls

Re: [PATCH] call maybe_return_this in build_clone

On 2024-02-09 19:57, Jason Merrill wrote: On 2/7/24 11:24, Torbjorn SVENSSON wrote: Hi, Is it okay to backport 0d24289d129639efdc79338a64188d6d404375e8 to releases/gcc-13? OK. Pushed as 583bd84075d23cde5fd489ab726093060870d773.

Re: [RFC] GCC Security policy

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: > > I think disallowing running as root would be a big problem in practice - > > the typical problem case is when people build software as non-root and run > > "make install" as root, and for some reason "make install" wants to > > (re)build or

Re: [PATCH] call maybe_return_this in build_clone

On 2/7/24 11:24, Torbjorn SVENSSON wrote: Hi, Is it okay to backport 0d24289d129639efdc79338a64188d6d404375e8 to releases/gcc-13? OK. Without this backport, I see these failures on arm-none-eabi: FAIL: g++.dg/warn/Wuse-after-free3.C  -std=gnu++14 (test for excess errors) FAIL:

Re: [PATCH] c++: fix ICE with __type_pack_element [PR113834]

On 2/9/24 13:32, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- Here we crash on this invalid code because we seem to infinitely recurse and end up with __type_pack_element with index that doesn't tree_fits_shwi_p which then crashes on

Re: [PATCH v3] c++: make build_throw SFINAE-friendly [PR98388]

On 2/9/24 13:31, Marek Polacek wrote: On Fri, Feb 09, 2024 at 10:07:33AM -0500, Jason Merrill wrote: On 2/8/24 17:20, Marek Polacek wrote: On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote: On 2/8/24 11:51, Marek Polacek wrote: On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick

[PATCH] c++: fix ICE with __type_pack_element [PR113834]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash on this invalid code because we seem to infinitely recurse and end up with __type_pack_element with index that doesn't tree_fits_shwi_p which then crashes on tree_to_shwi. Thanks to Jakub for suggesting a nicer

[PATCH v3] c++: make build_throw SFINAE-friendly [PR98388]

On Fri, Feb 09, 2024 at 10:07:33AM -0500, Jason Merrill wrote: > On 2/8/24 17:20, Marek Polacek wrote: > > On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote: > > > On 2/8/24 11:51, Marek Polacek wrote: > > > > On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote: > > > > > On

Re: [PATCH v4]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

On 2/9/24 11:02, Hans-Peter Nilsson wrote: Oops, I managed to send a version that only added a comment, but still had a dg-do run. Anyway, here's v4: actually change the "dg-do run", not just adding a comment. Sending as a self-contained fresh patch for the benefit of aforementioned CI. See

Re: [PATCH] c++: avoid name lookup during mangling

On 2/9/24 11:55, Patrick Palka wrote: On Fri, 9 Feb 2024, Jason Merrill wrote: On 2/9/24 10:51, Patrick Palka wrote: It turns out that with modules we can call mangle_decl recursively, which is a problem because the global mangling state isn't recursion aware. The recursion happens from

Re: [PATCH] libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same

On Fri, 9 Feb 2024 at 16:02, Patrick Palka wrote: > On Thu, 8 Feb 2024, Ken Matsui wrote: > > > Since is_same has a fallback native implementation, and > > _GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which > > implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME > >

Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

On 2/2/24 10:45, Alex Coplan wrote: On 02/02/2024 09:34, Marek Polacek wrote: On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote: Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk? Thanks, Alex -- >8 -- When __has_feature was introduced for GCC 14, I included the feature

Re: [RFC] GCC Security policy

On 2024-02-09 12:14, Joseph Myers wrote: On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: For privilege management we could add a --allow-root driver flag that allows gcc to run as root. Without the flag one could either outright refuse to run or drop privileges and run. Dropping privileges

Re: [RFC] GCC Security policy

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: > For privilege management we could add a --allow-root driver flag that allows > gcc to run as root. Without the flag one could either outright refuse to run > or drop privileges and run. Dropping privileges will be a bit tricky to > implement

Re: [PATCH] c++: avoid name lookup during mangling

On Fri, 9 Feb 2024, Jason Merrill wrote: > On 2/9/24 10:51, Patrick Palka wrote: > > It turns out that with modules we can call mangle_decl recursively, > > which is a problem because the global mangling state isn't recursion > > aware. The recursion happens from write_closure_type_name, which

[PATCH] RISC-V: Point our Python scripts at python3

This builds for me, and I frequently have python-is-python3 type packages installed so I think I've been implicitly testing it for a while. Looks like Kito's tested similar configurations, and the bugzilla indicates we should be moving over. gcc/ChangeLog: PR 109668 *

Re: [pushed] diagnostics, analyzer: add optional per-diagnostic property bags to SARIF

On Fri, 1 Dec 2023, David Malcolm wrote: > * diagnostic-core.h (emit_diagnostic_valist): New overload decl. This has broken regeneration of gcc.pot (overloads can't have the message extracted for translation in different argument positions). emit_diagnostic_valist used incompatibly as

Re: [PATCH] c++/modules: anon union member of as-base class [PR112580]

On 2/1/24 12:18, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Here when streaming in the fields of the as-base version of _Formatting_scanner we end up clobbering ANON_AGGR_TYPE_FIELD of the anonymous union type, since it turns out this type

Re: [PATCH] c++: avoid name lookup during mangling

On 2/9/24 10:51, Patrick Palka wrote: It turns out that with modules we can call mangle_decl recursively, which is a problem because the global mangling state isn't recursion aware. The recursion happens from write_closure_type_name, which calls lambda function, which performs name lookup,

Re: [PATCH v4]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

Oops, I managed to send a version that only added a comment, but still had a dg-do run. Anyway, here's v4: actually change the "dg-do run", not just adding a comment. Sending as a self-contained fresh patch for the benefit of aforementioned CI. See v2 and v3 for more. Sorry! Ok to commit? --

Re: [PATCH] libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same

On Thu, 8 Feb 2024, Ken Matsui wrote: > Since is_same has a fallback native implementation, and > _GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which > implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME > definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead. > >

Re: [RFC] GCC Security policy

On 2024-02-09 10:38, Martin Jambor wrote: If anyone is interested in scoping this and then mentoring this as a Google Summer of Code project this year then now is the right time to speak up! I can help with mentoring and reviews, although I'll need someone to assist with actual approvals.

[PATCH v5 4/4] Use the .ACCESS_WITH_SIZE in bound sanitizer.

gcc/c-family/ChangeLog: * c-ubsan.cc (get_bound_from_access_with_size): New function. (ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE. gcc/testsuite/ChangeLog: * gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test. *

[PATCH v5 2/4] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

Including the following changes: * The definition of the new internal function .ACCESS_WITH_SIZE in internal-fn.def. * C FE converts every reference to a FAM with a "counted_by" attribute to a call to the internal function .ACCESS_WITH_SIZE. (build_component_ref in c_typeck.cc) This

[PATCH v5 3/4] Use the .ACCESS_WITH_SIZE in builtin object size.

gcc/ChangeLog: * tree-object-size.cc (access_with_size_object_size): New function. (call_object_size): Call the new function. gcc/testsuite/ChangeLog: * gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT. * gcc.dg/flex-array-counted-by-3.c: New test.

[PATCH v5 0/4] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, This is the 5th version of the patch. compare with the 4th version, the major difference are: 1. Change the return type of the routine .ACCESS_WITH_SIZE FROM: Pointer to the type of the element of the flexible array; TO: Pointer to the type of the flexible array; And

[PATCH v5 1/4] Provide counted_by attribute to flexible array member field (PR108896)

'counted_by (COUNT)' The 'counted_by' attribute may be attached to the C99 flexible array member of a structure. It indicates that the number of the elements of the array is given by the field named "COUNT" in the same structure as the flexible array member. GCC uses this

[PATCH] c++: avoid name lookup during mangling

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look reasonable? -- >8 -- It turns out that with modules we can call mangle_decl recursively, which is a problem because the global mangling state isn't recursion aware. The recursion happens from write_closure_type_name, which calls

Re: [RFC] GCC Security policy

Hi, On Tue, Aug 08 2023, Richard Biener via Gcc-patches wrote: > On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar wrote: >> >> On 2023-08-08 04:16, Richard Biener wrote: >> > On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches >> > wrote: >> >> >> >> FOSS Best Practices recommends

Re: [PATCH][PUSHED] hwasan: support new dg-output format.

Hi, On 04/05/2022 09:59, Martin Liška wrote: > Supports change in libsanitizer where it newly reports: > READ of size 4 at 0xc3d4 tags: 02/01(00) (ptr/mem) in thread T0 > > So the 'tags' contains now 3 entries compared to 2 entries. > > gcc/testsuite/ChangeLog: > > *

[PATCH v3]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

Bah. Linaro's CI didn't like that there were UNRESOLVEDs due to this patch. Running it "as usual" didn't show anything suspicious. Sure, there were "# of unresolved testcases 3" in the summary (see v2), but no error or other special message from dejagnu. Perhaps there could be a way to have

Re: [PATCH v3] c++: DR2237, cdtor and template-id tweaks [PR107126]

On 2/8/24 16:26, Marek Polacek wrote: This patch does *not* fix where the C++20 diagnostic is missing altogether. What would it take to fix that as well? * doc/invoke.texi: Document -Wdeprecated-template-id-cdtor. Was it ever

Re: [PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]

On 2/8/24 17:20, Marek Polacek wrote: On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote: On 2/8/24 11:51, Marek Polacek wrote: On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote: On Wed, 7 Feb 2024, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu,

Re: [PATCH] testsuite, arm: Fix testcase arm/pr112337.c to check for the options first

On 30/01/2024 17:07, Saurabh Jha wrote: > Hey, > > Previously, this test was added to fix this bug: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did not > check the compilation options before using them, leading to errors. > > This patch fixes the test by first checking

[PATCH v2] libstdc++: add ARM SVE support to std::experimental::simd

Hi, Thanks for review @Richard!. I have tried to address most of your comments in this patch. The major updates include optimizing operator[] for masks, find_first_set and find_last_set. My further comments on some of the pointed out issues are a. regarding the coverage of types supported for

[PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]

The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert the timespec used in gthreads to specify the absolute time for end of the condition variables timed wait to a milliseconds value relative to "now" to pass to the Win32 SleepConditionVariableCS function. Unfortunately, the

Re: [PATCH] bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]

On Fri, 9 Feb 2024, Jakub Jelinek wrote: > Hi! > > On the following testcases memcpy lowering folds the calls to > reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t > with OImode or uint512_t with XImode. Further optimization turn > the load from MEM_REF from the large/huge

Re: [PATCH] testsuite, arm: Fix testcase arm/pr112337.c to check for the options first

Ping. I also don't have commit access so can someone please commit on my behalf. From: Saurabh Jha Sent: Tuesday, January 30, 2024 5:07 PM To: Richard Sandiford via Gcc-patches; Richard Sandiford; Kyrylo Tkachov; Richard Earnshaw Subject: [PATCH]

Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

> On 8 Feb 2024, at 21:44, Jason Merrill wrote: > > On 2/8/24 12:55, Paolo Bonzini wrote: >> On 2/8/24 18:16, Jason Merrill wrote: > Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage

Re: [PATCH] [testsuite] tsvc: skip include malloc.h when unavailable

On 2024-02-09 11:34, Richard Biener wrote: On Fri, Feb 9, 2024 at 11:33 AM Torbjorn SVENSSON wrote: Hi, Is it okay to backport 2f20d6296087cae51f55eeecb3efefe786191fd6 to releases/gcc-13? Yes. Pushed as 5b3dcff46780192a2e526bc434d61c8626898050.

Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

On Thu, Feb 1, 2024 at 4:26 PM Jakub Jelinek wrote: > > On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote: > > No, besides the formatting being incorrect both in ChangeLog and in the > > patch, this pessimizes ILP32 hosts unnecessarily. > > So like this instead? OK. Thanks, Richard.

Re: [PATCH] [testsuite] tsvc: skip include malloc.h when unavailable

On Fri, Feb 9, 2024 at 11:33 AM Torbjorn SVENSSON wrote: > > Hi, > > Is it okay to backport 2f20d6296087cae51f55eeecb3efefe786191fd6 to > releases/gcc-13? Yes. > Without this backport, I see about 150 failures on arm-none-eabi, an > example of them is: > > FAIL:

Re: [PATCH] [testsuite] tsvc: skip include malloc.h when unavailable

Hi, Is it okay to backport 2f20d6296087cae51f55eeecb3efefe786191fd6 to releases/gcc-13? Without this backport, I see about 150 failures on arm-none-eabi, an example of them is: FAIL: gcc.dg/vect/tsvc/vect-tsvc-s000.c (test for excess errors) Kind regards, Torbjörn On 2023-05-24 11:02,

[pushed] libgcc, Darwin: Update symbol exports to include bitint and bf.

Tested on i686-darwin8, x86_64-darwin{14,17,19,21,23} pushed to trunk. thanks, Iain --- 8< --- Some exports were missed from the GCC-13 cycle, these are added here along with the bitint-related ones added in GCC-14. libgcc/ChangeLog: * config/i386/libgcc-darwin.ver: Export bf and

[PATCH 3/3][RFC] Initial MEM_BASE population

The following attempts to set a MEM_BASE from set_mem_attributes_minus_bitpos which is often first called on the expanded base of a complicated memory reference. For now simply preserve a SYMBOL_REF (fancy unwrapping to be implemented). The commented code would transfer some points-to info.

[PATCH 2/3] Remove get_reg_base_value

This makes recorded reg base values private to alias.cc, its computation should go away but find_base_term can be used to cross-check that we don't regress when only having MEM_BASE eventually. Selective scheduling wouldn't need to avoid renaming regs with a base value anymore, so this removes

[PATCH 1/3][RFC] Add MEM_BASE

The following adds a 'base' member to the RTL memory attributes, recording the base value as base_alias_check expects and currently find_base_{value,term} compute. It is expected to either contain a SYMBOL_REF or a special ADDRESS, see base_alias_check for reference. With this patch nothing sets

[PATCH] rtl-optimization/113597 - recover base term for argument pointers

The following allows a base term to be derived from an existing MEM_EXPR, notably the points-to set of a MEM_REF base. For the testcase in the PR this helps RTL DSE elide stores to a stack temporary. This covers pointers to NONLOCAL which can be mapped to arg_base_value, helping to disambiguate

Re: [PATCH] middle-end/113576 - zero padding of vector bools when expanding compares

On Fri, Feb 09, 2024 at 10:24:25AM +0100, Richard Biener wrote: > The following zeros paddings of vector bools when expanding compares > and the mode used for the compare is an integer mode. In that case > targets cannot distinguish between a 4 element and 8 element vector > compare (both get to

Re: [COMMITTED 13/25] gccrs: remove old generics hack to reuse generic symbols from previous seg

On Wed, Feb 07, 2024 at 12:43:59PM +0100, arthur.co...@embecosm.com wrote: > From: Philip Herron > > This patch introduces one regression because generics are getting better > understood over time. The code here used to apply generics with the same > symbol from previous segments which was a bit

Patch ping

Hi! I'd like to ping 2 patches: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html PR113617 P1 - Handle private COMDAT function symbol reference in readonly data section More details in the https://gcc.gnu.org/pipermail/gcc-patches/2024-January/thread.html#644121 and

Re: [PATCH] expand: Fix asm goto expansion [PR113415]

On Fri, 9 Feb 2024, Jakub Jelinek wrote: > Hi! > > The asm goto expansion ICEs on the following testcase (which normally > is rejected later), because expand_asm_stmt emits the code to copy > the large var out of the out operand to its memory location into > after_rtl_seq ... after_rtl_end

Re: [PATCH] lower-bitint: Fix up additions of EH edges [PR113818]

On Fri, 9 Feb 2024, Jakub Jelinek wrote: > Hi! > > Due to -fnon-call-exceptions the bitint lowering adds new EH edges > in various places, so that the EH edge points from handling (e.g. load or > store) of each of the limbs. The problem is that the EH edge destination > as shown in the testcase

[PATCH] expand: Fix asm goto expansion [PR113415]

Hi! The asm goto expansion ICEs on the following testcase (which normally is rejected later), because expand_asm_stmt emits the code to copy the large var out of the out operand to its memory location into after_rtl_seq ... after_rtl_end sequence and because it is asm goto, it duplicates the

Re: [PATCH] lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774]

On Fri, 9 Feb 2024, Jakub Jelinek wrote: > Hi! > > The following patch is the optimization part of PR113774, where in > handle_cast we emit some conditionals which are always true and presumably > VRP would figure that out later and clean it up, except that instead > thread1 is invoked and

[PATCH] middle-end/113576 - zero padding of vector bools when expanding compares

The following zeros paddings of vector bools when expanding compares and the mode used for the compare is an integer mode. In that case targets cannot distinguish between a 4 element and 8 element vector compare (both get to the QImode compare optab) so we have to do the job in the middle-end.

[PATCH] lower-bitint: Fix up additions of EH edges [PR113818]

Hi! Due to -fnon-call-exceptions the bitint lowering adds new EH edges in various places, so that the EH edge points from handling (e.g. load or store) of each of the limbs. The problem is that the EH edge destination as shown in the testcase can have some PHIs. If it is just a virtual PHI, no

[PATCH] lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774]

Hi! The following patch is the optimization part of PR113774, where in handle_cast we emit some conditionals which are always true and presumably VRP would figure that out later and clean it up, except that instead thread1 is invoked and threads everything through the conditions, so we end up

Re: [PATCH v2] libstdc++: optimize bit iterators assuming normalization [PR110807]

On 2024-02-07 17:36, Jonathan Wakely wrote: On Wed, 7 Feb 2024 at 16:25, Torbjorn SVENSSON mailto:torbjorn.svens...@foss.st.com>> wrote: Hi, Is it okay to backport e39b3e02c27bd771a07e385f9672ecf1a45ced77 to releases/gcc-13? It would also need 

Re: [PATCH v2] testsuite: Pattern does not match when using --specs=nano.specs

On 2024-02-09 01:07, Mike Stump wrote: On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON wrote: Changes since v1: - Replaced .* with [^\r\n]* to avoid matching newline. Ok for trunk and releases/gcc-13? Ok. Pushed as 1175d1b35ce7bf8ee7c9b37b334370f01eb95335 and

Re: [PATCH] c++: for contracts, cdtors never return this

On 2024-02-07 20:46, Jason Merrill wrote: On 2/7/24 11:22, Torbjorn SVENSSON wrote: Hi, Is it okay to backport 71804526d3a71a8c0f189a89ce3aa615784bfd8b to releases/gcc-13? OK. Pushed as eae51472f68d9f922aa3a1a636f81467bfdae87a.

[PATCH] bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]

Hi! On the following testcases memcpy lowering folds the calls to reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t with OImode or uint512_t with XImode. Further optimization turn the load from MEM_REF from the large/huge _BitInt var into VIEW_CONVERT_EXPR from it to the

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

On Fri, 2024-02-09 at 00:02 +0800, chenglulu wrote: > > 在 2024/2/7 上午12:23, Xi Ruoyao 写道: > > Hi Lulu, > > > > I'm proposing to backport r14-4674 "LoongArch: Delete macro definition > > ASM_OUTPUT_ALIGN_WITH_NOP." to releases/gcc-12 and releases/gcc-13.  The > > reasons: > > > > 1. Strictly