Re: [PATCH] always turn return into __builtin_unreachable for noreturn fuctions [PR119599]

On Thu, Apr 3, 2025 at 11:56 PM Andrew Pinski wrote: > > r8-3988-g356fcc67fba52b added code to turn return statements into > __builtin_unreachable > calls inside noreturn functions but only while optimizing. Since > -funreachable-traps > was added (r13-1204-gd68d3664253696), it is a good idea to

Re: [PATCH] libgcobol: Check if the target needs libm.

On Thu, Apr 3, 2025 at 9:19 PM Iain Sandoe wrote: > > We should not assume that the target needs (or even has) libm. > > Tested on the usual suspects (x86_64, aarch64 linux, x86_64 darwin). > OK for trunk? OK. > thanks > Iain. > > --- 8< --- > > Use the libtool config check and $(LIBM). > > libg

Re: [PATCH] combine: Allow 2->2 combos but limit insn searches [PR116398]

On Thu, 3 Apr 2025, Richard Sandiford wrote: > Richard Biener writes: > > On Wed, 2 Apr 2025, Richard Sandiford wrote: > > > >> Richard Biener writes: > >> > On Tue, 1 Apr 2025, Richard Sandiford wrote: > >> > > >> >> The problem in PR101523 was that, after each successful 2->2 > >> >> combinati

[PATCH] cse: Fix up delete_trivially_dead_insns [PR119594]

Hi! The following testcase is miscompiled by delete_trivially_dead_insns, latently since r0-6313, actually since r15-1575. The problem is in that r0-6313 change, which made count_reg_usage not count uses of the pseudo which the containing SET sets. That is needed so we can delete those instructi

[PATCH] tailc: Use the IPA-VRP tail call hack even for pointers [PR119614]

Hi! As the first two testcases show, even with pointers IPA-VRP can optimize return values from functions if they have singleton ranges into just the exact value, so we need to virtually undo that for tail calls similarly to integers and floats. The third test just adds check that it works even w

[PATCH] c++/modules: Fix divergence in streaming/non-streaming tree walks [PR119608]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Modules streaming walks decls multiple times, first as a non-streaming walk to find dependencies, and then later to actually emit the decls. The first walk needs to be done to note locations that will be emitted. In the PR

[PATCH] c++: Fix GC with TU_LOCAL_ENTITY [PR119564]

Tested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full bootstrap+regtest succeeds? -- >8 -- When adding TU_LOCAL_ENTITY in r15-6379 I neglected to add it to cp_tree_node_structure, so garbage collection was crashing on it. gcc/cp/ChangeLog: * decl.cc (cp_tree_node

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

On Wed, Apr 02, 2025 at 09:16:47PM +, Qing Zhao wrote: > Hi, Bill, > > Thanks for the summary. > > I think that this is good. > > Two more questions: > > 1. Shall we keep the same name of the attribute counted_by for the 2nd new > syntax? > Or use a new name, such as, “counted_by_exp

Re: [PATCH] c++: P2280R4 and speculative constexpr folding [PR119387]

On 4/2/25 3:07 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux, does this look OK for trunk/14? OK. -- >8 -- The testcase in this PR uses 2.5x more memory and 6x more compile time ever since r14-5979 which implements P2280R4. This is because our speculative constexpr

[pushed] c++/modules: inline loaded at eof

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- std/format/string.cc and a few other libstdc++ tests were failing with module std with undefined references to __failed_to_parse_format_spec. This turned out to be because since r15-8012 we don't end up calling note_vague_linkage_fn for fun

[PATCH] always turn return into __builtin_unreachable for noreturn fuctions [PR119599]

r8-3988-g356fcc67fba52b added code to turn return statements into __builtin_unreachable calls inside noreturn functions but only while optimizing. Since -funreachable-traps was added (r13-1204-gd68d3664253696), it is a good idea to move over to using __builtin_unreachable (and the trap version wi

Re: [PATCH] c++: constraint variable used in evaluated context [PR117849]

On 4/2/25 2:28 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? OK for 14. For 15, what happens if we remove that error entirely? Do we still give other errors in that case? That seems to be the expectation of https://eel.is/c++dra

libstdc++, nvptx: Remove machinery to inject per-file flags (was: GCN, nvptx: Allow for "hosted" libstdc++ build)

Hi! On 2025-03-14T11:39:20+0100, I wrote: > Subject: [PATCH] GCN, nvptx: Allow for "hosted" libstdc++ build > > We need [...], and > for nvptx twiddle some more knobs. > --- /dev/null > +++ b/libstdc++-v3/config/cpu/nvptx/t-nvptx > @@ -0,0 +1,7 @@ > +# Per-file flags, see '../../../configure.host

nvptx: Don't use PTX '.const', constant state space [PR119573] (was: 'TREE_READONLY' for 'const' array in C vs. C++)

Hi! I have, by the way, filed "nvptx: PTX '.const', constant state space" for this topic. On 2025-04-01T09:32:46+0200, Jakub Jelinek wrote: > On Tue, Apr 01, 2025 at 09:19:08AM +0200, Richard Biener via Gcc wrote: >> On Tue, Apr 1, 2025 at 12:04 AM Thomas Schwinge

Re: [PATCH 2/2] c++: maybe_dependent_member_ref and typenames [PR118626]

On 3/31/25 7:51 PM, Patrick Palka wrote: Here during maybe_dependent_member_ref for accepted_type<_Up>, we correctly don't strip the typedef because it's a complex one (its defaulted template parameter isn't used in its definition) and so we recurse to consider its corresponding TYPE_DECL. We th

Re: [PATCH 1/2] c++: maybe_dependent_member_ref and stripped alias [PR118626]

On 3/31/25 7:51 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This isn't a regression and potentially impacts C++17 code, but it also makes alias CTAD unusable for our std::variant currently. OK. -- >8 -- Here during maybe_dependent

Re: [PATCH] c++: Fix typo in RAW_DATA_CST build_list_conv subsubconv hanling [PR119563]

On 4/1/25 10:31 AM, Jakub Jelinek wrote: Hi! The following testcase ICEs (the embed one actually doesn't but dereferences random uninitialized pointer far after allocated memory) because of a typo. In the RAW_DATA_CST handling of list conversion where there are conversions to something other th

[PATCH] libgcobol: Check if the target needs libm.

We should not assume that the target needs (or even has) libm. Tested on the usual suspects (x86_64, aarch64 linux, x86_64 darwin). OK for trunk? thanks Iain. --- 8< --- Use the libtool config check and $(LIBM). libgcobol/ChangeLog: * Makefile.am: Use $(LIBM) to add the math lib when

[PATCH v1 1/2] c: Add target_version attribute support.

This commit introduces support for the target_version attribute in the c frontend, following the behavior defined in the Arm C Language Extension. Key changes include: - During pushdecl, the compiler now checks whether the current symbol is part of a multiversioned set. - New versions are ad

[COMMITTED 31/35] gccrs: FIX ICE when working with HIR::BareFunctionType

From: Philip Herron Fixes Rust-GCC#3615 gcc/rust/ChangeLog: * hir/rust-hir-dump.cc (Dump::visit): check has type * hir/tree/rust-hir-type.cc (BareFunctionType::BareFunctionType): likewise gcc/testsuite/ChangeLog: * rust/compile/issue-3615.rs: New test. Signed-off-by:

Re: [PATCH, OBVIOUS] rs6000: Add Cobol support to traceback table [PR119308]

On 4/2/25 2:57 PM, Peter Bergner wrote: > The AIX traceback table documentation states the tbtab "lang" field for > Cobol should be set to 7. > > Tested on powerpc64le-linux. There are "new" FAILs with the patch (see below) > on the Cobol test cases, but that is a good thing, because without the

[PATCH] libstdc++: Provide formatter for vector::reference [PR109162]

This patch implement formatter for vector::reference which is part of P2286R8. To indicate partial support we define __glibcxx_format_ranges macro value 1, without defining __cpp_lib_format_ranges. To avoid including the whole content of the header, we introduce new bits/formatfwd.h forward decl

[PATCH] libstdc++: Fix handling of field width for wide strings and characters [PR119593]

This patch corrects handling of UTF-32LE and UTF32-BE in __unicode::__literal_encoding_is_unicode<_CharT>, so they are recognized as unicode and functions produces correct result for wchar_t. Use `__unicode::__field_width` to compute the estimated witdh of the charcter for unicode wide encoding.

Re: Forward declaration

CC’ing gcc alias as well. Hi, Yeoul, I think the key for when to use the forward declaration syntax is: When there is only one single identifier as the argument of counted_by attribute, There will be no possibility of scope conflict between different identifiers inside the counted_by attrib

Re: [PATCH] combine: Allow 2->2 combos but limit insn searches [PR116398]

Richard Sandiford writes: > Richard Biener writes: >> On Wed, 2 Apr 2025, Richard Sandiford wrote: >> >>> Richard Biener writes: >>> > On Tue, 1 Apr 2025, Richard Sandiford wrote: >>> > >>> >> The problem in PR101523 was that, after each successful 2->2 >>> >> combination attempt, distribute_lin

[PING^2] [PATCH v2] rs6000: Adding missed ISA 3.0 atomic memory operation instructions.

Ping! please review. Thanks & Regards Jeevitha On 20/02/25 7:41 pm, jeevitha wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > Changes to amo.h include the addition of the following load atomic operations: > Compare and Swap Not Equal, Fet

Re: [PATCH] vect: Relax scan-tree-dump strict pattern matching [PR118597]

On 4/3/25 8:40 AM, Victor Do Nascimento wrote: Cheers, And given how the test also started failing for GCC14, are we also okay to go ahead with backporting the patch? Of course. Thanks, jeff

Re: [PATCH] vect: Relax scan-tree-dump strict pattern matching [PR118597]

Cheers, And given how the test also started failing for GCC14, are we also okay to go ahead with backporting the patch? Victor On 4/2/25 17:39, Jeff Law wrote: On 4/2/25 8:53 AM, Victor Do Nascimento wrote: Using specific SSA names in pattern matching in `dg-final' makes tests "unstable", i

[PATCH v1 2/2] c: Improve diagnostics for C FMV declaration conflicts.

Improves diagnostic messages for conflicting function multiversioning (FMV) declarations using target_version and/or target_clones attributes. Conflict errors now include the overlapping version string (if relevant), making it easier to identify and resolve declaration mismatches. gcc/c/ChangeLo

Re: [PATCH] libstdc++: Fix handling of field width for wide strings and characters [PR119593]

On Thu, Apr 3, 2025 at 2:49 PM Jonathan Wakely wrote: > On Thu, 3 Apr 2025 at 10:24, Jonathan Wakely wrote: > > > > On Thu, 3 Apr 2025 at 09:55, Tomasz Kamiński > wrote: > > > > > > This patch corrects handling of UTF-32LE and UTF32-BE in > > > __unicode::__literal_encoding_is_unicode<_CharT>,

Ping^2: [PATCH v4] get source line for diagnostic from preprocessed file [PR preprocessor/79106]

Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676875.html

Re: [PATCH] combine: Allow 2->2 combos but limit insn searches [PR116398]

On Thu, Apr 03, 2025 at 07:50:13AM -0600, Jeff Law wrote: > On 4/3/25 7:40 AM, Richard Sandiford wrote: > > > > > > But log-links on i2 are for uses in i2 for defs before i2, given > > > i0/i1/i2 changed/have gone away we adjust those to eventually end > > > up on insns between i2 and i3 (or indee

Re: [PATCH] combine: Allow 2->2 combos but limit insn searches [PR116398]

Richard Biener writes: > On Wed, 2 Apr 2025, Richard Sandiford wrote: > >> Richard Biener writes: >> > On Tue, 1 Apr 2025, Richard Sandiford wrote: >> > >> >> The problem in PR101523 was that, after each successful 2->2 >> >> combination attempt, distribute_links would search further and >> >> fu

Re: [PATCH] libstdc++: Fix handling of field width for wide strings and characters [PR119593]

On Thu, 3 Apr 2025 at 10:24, Jonathan Wakely wrote: > > On Thu, 3 Apr 2025 at 09:55, Tomasz Kamiński wrote: > > > > This patch corrects handling of UTF-32LE and UTF32-BE in > > __unicode::__literal_encoding_is_unicode<_CharT>, so they are > > recognized as unicode and functions produces correct r

RE: [PATCH] rtlanal, i386: Adjust pattern_cost and x86 constant cost [PR115910]

I agree returning to the GCC 14 behaviour is the best approach given the current stage. > -Original Message- > From: Jakub Jelinek > Sent: 03 April 2025 09:16 > To: Roger Sayle > Cc: 'Richard Biener' ; 'Jan Hubicka' ; 'Uros > Bizjak' ; 'Richard Sandiford' ; > gcc-patches@gcc.gnu.org > Su

[committed] cobol: Additional cobol.dg/group2 testcases

cobol: New testcases for INSPECT statement. gcc/testsuite * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_LEADING.cob: New testcase. * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_TRAILING.cob: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_CONVERTING.c

Re: [PATCH] rtlanal, i386: Adjust pattern_cost and x86 constant cost [PR115910]

On Thu, Apr 03, 2025 at 08:42:01AM -0400, Roger Sayle wrote: > I've been bootstrapping and regression testing a variant of Jakub's > previously proposed change: > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc > index f38e3db41fa..123948a2dea 100644 > --- a/gcc/config/i386/i386.c

Re: Pushed r15-9167: [PATCH] LoongArch: Make gen-evolution.awk compatible with FreeBSD awk

On 2025-04-03 11:37, Lulu Cheng wrote: 在 2025/4/3 上午11:12, Xi Ruoyao 写道: On Thu, 2025-04-03 at 10:13 +0800, Lulu Cheng wrote: 在 2025/4/2 上午11:19, Xi Ruoyao 写道: Avoid using gensub that FreeBSD awk lacks, use gsub and split those each of gawk, mawk, and FreeBSD awk provides. Reported-by: mp..

Make ipa-cp propagate over non-hot calls

Hi, Currently enabling profile feedback regresses x264 and exchange. In both cases the root of the issue is that ipa-cp cost model thinks cloning is not relevant when feedback is available while it clones without feedback. Consider: __attribute__ ((used)) int a[1000]; __attribute__ ((noinline)

Re: [PATCH] libstdc++: Fix handling of field width for wide strings and characters [PR119593]

On Thu, 3 Apr 2025 at 13:55, Tomasz Kaminski wrote: > > > > On Thu, Apr 3, 2025 at 2:49 PM Jonathan Wakely wrote: >> >> On Thu, 3 Apr 2025 at 10:24, Jonathan Wakely wrote: >> > >> > On Thu, 3 Apr 2025 at 09:55, Tomasz Kamiński wrote: >> > > >> > > This patch corrects handling of UTF-32LE and UT

Re: [PATCH] sra: Avoid creating TBAA hazards (PR118924)

> On Mon, 31 Mar 2025, Martin Jambor wrote: > > > Hi, > > > > the testcase in PR 118924, when compiled on Aarch64, contains an > > gimple aggregate assignment statement in between different types which > > are types_compatible_p but behave differently for the purposes of > > alias analysis. > >

Re: [PATCH] sra: Avoid creating TBAA hazards (PR118924)

> > > So in WPA we can not assume that TYPE_CANONICAL (A) == TYPE_CANONICAL > > > (B) is forever. We also don't do any gimple transforms here, so this is > > > kind of safe, but ugly. > > > > Hmm. But we do > > > > /* alias_ptr_types_compatible_p relies on fact that during LTO > >

Re: [PATCH] sra: Avoid creating TBAA hazards (PR118924)

> > So in WPA we can not assume that TYPE_CANONICAL (A) == TYPE_CANONICAL > > (B) is forever. We also don't do any gimple transforms here, so this is > > kind of safe, but ugly. > > Hmm. But we do > > /* alias_ptr_types_compatible_p relies on fact that during LTO > types do not g

RE: [PATCH] rtlanal, i386: Adjust pattern_cost and x86 constant cost [PR115910]

Hi Jakub, I've been bootstrapping and regression testing a variant of Jakub's previously proposed change: diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index f38e3db41fa..123948a2dea 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -21883,7 +21883,10 @@ ix86

[RFC PATCH] Implement -fdiag-prefix-map

In many setups, especially when CI and/or some meta-build system like Yocto or buildroot, is involved, gcc ends up being invoked using absolute path names, which are often long and uninteresting. That amounts to a lot of noise both when trying to decipher the warning or error, when the warning tex

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi all, the backport to gcc-14 has been committed as: gcc-14.2.0-996-gf955c5b409a Regards, Andre On Fri, 21 Mar 2025 13:33:37 +0100 Andre Vehreschild wrote: > Hi Paul, > > well, I had those might complicated patches bit my mightily. So let's hope for > the best :-) > > Thanks for the r

Re: [PATCH v2 04/18] Add microMIPS R6 support

HTEC Public Hi, > Umm, this change can't go forward I'm afraid without microMIPSr6 > support landing in binutils first. Otherwise we have no consumer > for compiled code available. We have sent a patch series to binutils: https://sourceware.org/pipermail/binutils/2025-April/140356.html It inclu

[committed] c-family: Regenerate c.opt.urls

Hi! On Sun, Mar 30, 2025 at 02:48:43PM +0200, Martin Uecker wrote: > The warning -Wzero-as-null-pointer-constant is now not only supported > in C++ but also in C. Change the documentation accordingly. This change didn't include make regenerate-opt-urls changes, because moving option documentatio

[COMMITTED] Doc: Clarify use of access attribute [PR101440]

This issue was specifically about a confusing mention of the "second and third arguments to the memcpy function" when only the second one is a pointer affected by the attribute, but reading through the entire discussion I found other things confusing as well; e.g. in some cases it wasn't clear whet

Re: [PATCH] combine: Allow 2->2 combos but limit insn searches [PR116398]

On Wed, 2 Apr 2025, Richard Sandiford wrote: > Richard Biener writes: > > On Tue, 1 Apr 2025, Richard Sandiford wrote: > > > >> The problem in PR101523 was that, after each successful 2->2 > >> combination attempt, distribute_links would search further and > >> further for the next combinable use

Re: [RFC] Doc: Clean up musttail attribute docs some more

On Wed, 2 Apr 2025, Sandra Loosemore wrote: > Looking over the recently-committed change to the musttail attribute > documentation, it appears the comment in the last example was a paste-o, > as it does not agree with either what the similar example in the > -Wmaybe-musttail-local-addr documentati

Re: [PATCH] fold-const, cobol, v2: Add native_encode_wide_int and use it in COBOL FE [PR119242]

On Wed, 2 Apr 2025, Jakub Jelinek wrote: > On Wed, Apr 02, 2025 at 09:22:54PM +0100, Richard Sandiford wrote: > > I'm not sure the _1 template is worth it. wi::to_widest -> > > const wide_int_ref & should be very cheap (it doesn't for example > > construct a widest_int), so I think native_encode_