Re: [PATCH v2] c++: constexpr error with fn redecl in local scope [PR111132]

On 4/4/24 19:15, Marek Polacek wrote: On Thu, Apr 04, 2024 at 05:28:22PM -0400, Jason Merrill wrote: On 4/4/24 14:43, Marek Polacek wrote: On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: On 4/2/24 13:52, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

Re: [PATCH] go: Add go.install-dvi rule in go/Make-lang.in

On Thu, Apr 4, 2024 at 9:27 AM Christophe Lyon wrote: > > go has a go.dvi build rule, but lacks the go.install-dvi one. > > 2024-04-04 Christophe Lyon > > gcc/go/ > * Make-lang.in (go.install-dvi): New rule. This is OK. Thanks. Ian

[COMMITTED] testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement

The xpassing change in generated code was as follows, at r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert to verify that this suspect was the cause). That was so much of an improvement that I had to share it! Worth the testsuite churn anyway. :) Segher, if you end up reverting

[COMMITTED] testsuite/gcc.dg/debug/btf/btf-datasec-1.c: Handle leading-underscore

Committed as obvious. -- >8 -- I noticed my autotester for cris-elf flagging this as a regression. * gcc.dg/debug/btf/btf-datasec-1.c: Adjust pattern for targets with symbols having a leading underscore. --- gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 2 +- 1 file changed,

Re: [PATCH v3] tree-profile: Disable indirect call profiling for IFUNC resolvers

On Thu, Apr 4, 2024 at 5:34 PM wrote: > > On 3 April 2024 15:49:13 CEST, "H.J. Lu" wrote: > > > >> OK witht that change. > >> Honza > > > >I am checking in this patch with the updated comments: > > > > /* Disable indirect call profiling for an IFUNC resolver and its > > callees since it

Re: [PATCH v3] tree-profile: Disable indirect call profiling for IFUNC resolvers

On 3 April 2024 15:49:13 CEST, "H.J. Lu" wrote: >> OK witht that change. >> Honza > >I am checking in this patch with the updated comments: > > /* Disable indirect call profiling for an IFUNC resolver and its > callees since it requires TLS which hasn't been set up yet when > the

[PATCH v2] c++: constexpr error with fn redecl in local scope [PR111132]

On Thu, Apr 04, 2024 at 05:28:22PM -0400, Jason Merrill wrote: > On 4/4/24 14:43, Marek Polacek wrote: > > On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: > > > On 4/2/24 13:52, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > > >

[PATCH] libgccjit: Add ability to get the alignment of a type

Hi. This patch adds a new API to produce an rvalue representing the alignment of a type. Thanks for the review.From 12d8e57ca2313002da42672dc86b167baf812ff3 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Thu, 4 Apr 2024 18:57:07 -0400 Subject: [PATCH] libgccjit: Add ability to get the

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about:   ',3' as input for 'comma'   (or '.3' as input for 'point') For 'point' – 0.3 is read and ios = 0 (as expected) But for 'comma': * GCC 12 reads nothing and has ios = 0. * GCC 13/mainline has

Re: [PATCH] c++: constexpr error with fn redecl in local scope [PR111132]

On 4/4/24 14:43, Marek Polacek wrote: On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: On 4/2/24 13:52, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- We evaluate constexpr functions on the original, pre-genericization bodies. That

Re: [PATCH] c++: fix alias CTAD [PR114377]

Applied, thanks! BTW, in future please see https://gcc.gnu.org/contribute.html#legal This patch is small enough to not need to worry about copyright, but for larger patches we would. On 3/27/24 14:36, centurion wrote: PR c++/114377 gcc/cp/ChangeLog: PR c++/114377

[PATCH] ICF: Make ICF and SRA agree on padding

Hi, PR 113359 shows that (at least with -fno-strict-aliasing) ICF can unify two functions which copy an aggregate type of the same size but then SRA, through its total scalarization, can copy the aggregate by pieces, skipping paddding, but the padding was not the same in the two original

[PATCH] ipa: Compare jump functions in ICF (PR 113907)

Hello, In PR 113907 comment #58, Honza found a case where ICF thinks bodies of functions are equivalent but becaise of difference in aliases in a memory access, different aggregate jump functions are associated with supposedly equivalent call statements. This patch adds a way to compare jump

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/4/24 2:31 AM, Tobias Burnus wrote: Hi Jerry, --- snip --- The patch looks mostly like I would expect, except for decimal='point' and a ';' which is *not* preceded by a space. Thanks for working on it. Regarding the 'except' case: --- snip --- i.e. for the following string, I had

[wwwdocs] gcc-14/changes.html: Comment out of empty sections

I find it confusing to see multiple in a row without content. Actually, both have as content, but those are commented out as actual news is missing ... See https://gcc.gnu.org/gcc-14/changes.html and see the last entry at the bottom of the page and "Operating Systems" somewhere in between.

[wwwdocs] gcc-14/changes.html: Mention OpenACC 2.7's 'readonly' modifier

Minor OpenACC 2.7 update to https://gcc.gnu.org/gcc-14/changes.html#openacc The 'readonly' modifier is now in (well, since March), albeit more 2.7 features are in the pipeline... Comments, remarks, suggestions before I commit it? Tobias gcc-14/changes.html: Mention OpenACC 2.7's 'readonly'

[wwwdocs,committed] gcc-14/changes.html: Fix HTML syntax

Found when testing my own change via https://validator.w3.org/nu/#file Committed as obvious. Tobias commit c9e275660a19c804dd8c591c73cb9b169a9d7573 Author: Tobias Burnus Date: Thu Apr 4 22:07:28 2024 +0200 gcc-14/changes.html: Fix HTML syntax W3.org's HTML checker complained

[pushed][PR114415][scheduler]: Fixing wrong code generation

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 The patch was successfully tested and bootstrapped on x86_64, ppc64le, aarch64. commit fe305ca39930afc301cdd1f1143d540d1bfa2a48 Author: Vladimir N. Makarov Date: Thu Apr 4 16:04:04 2024 -0400

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

On 4/4/24 2:31 AM, Tobias Burnus wrote: Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, 4 Apr 2024 at 17:55, Jonathan Wakely wrote: > > On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote: > Ulrich's suggestion is to allow the buggy user code to Just Work (for > all cases except (char)-1 on a platform where char is signed). That is > maybe the least surprising behaviour for

Re: [Patch] nvptx: In mkoffload.cc, call diagnostic_color_init + gcc_init_libintl

Hi Tobias! On 2024-04-03T14:06:45+0200, Tobias Burnus wrote: > Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at' > call, > which stands out more clearly (color, bold) when enabling >diagnostic_color_init > which this patch does. — Additionally, the call

Re: [PATCH] x86: Define __APX_F__ for -mapxf

On Thu, Apr 4, 2024 at 5:08 PM H.J. Lu wrote: > > Define __APX_F__ when APX is enabled. > > gcc/ > > PR target/114587 > * config/i386/i386-c.cc (ix86_target_macros_internal): Define > __APX_F__ when APX is enabled. > > gcc/testsuite/ > > PR target/114587 >

Re: [PATCH] c++: constexpr error with fn redecl in local scope [PR111132]

On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: > On 4/2/24 13:52, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > We evaluate constexpr functions on the original, pre-genericization bodies. > > That means that the

[committed] wwwdocs: gcc-14: Add release notes for C23 features

Add release notes for C23 features added in GCC 14. This doesn't cover any non-C23 new C features; any such features should also have release notes added. diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 934cd1ad..045893cf 100644 --- a/htdocs/gcc-14/changes.html +++

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote: > > On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote: > > > > > > > > > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote: > > > > > > I would appreciate more eyes on this to confirm my conclusions about > > > negative int_type values, and the

[PATCH 8/9] wwwdocs: gcc-14: analyzer improvements

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 162 + 1 file changed, 162 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 8b72bc20..d782c334 100644 --- a/htdocs/gcc-14/changes.html +++

[PATCH 6/9] wwwdocs: gcc-14: improvements to automatic doc URLs for options

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 2dc7e598..0701dc29 100644 --- a/htdocs/gcc-14/changes.html +++

[PATCH 4/9] wwwdocs: gcc-14: c++: note changes to source quoting in template errors

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 7 +++ 1 file changed, 7 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index f9ce4fe5..95ed00c9 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -262,6 +262,13 @@ a

[PATCH 9/9] wwwdocs: gcc-14: add 'Improvements to SARIF support' section

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 22 ++ 1 file changed, 22 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index d782c334..934cd1ad 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@

[PATCH 3/9] wwwdocs: gcc-14: add null_terminated_string_arg attribute

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 7 +++ 1 file changed, 7 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 397458d5..f9ce4fe5 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -191,6 +191,13 @@ a

[PATCH 5/9] wwwdocs: gcc-14: libgccjit changes

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 95ed00c9..2dc7e598 100644 --- a/htdocs/gcc-14/changes.html +++

[PATCH 7/9] wwwdocs: gcc-14: improvements for plugin authors

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 0701dc29..8b72bc20 100644 --- a/htdocs/gcc-14/changes.html +++

[PATCH 2/9] wwwdocs: gcc-14: add URLs to some options

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 5cc729c5..397458d5 100644 --- a/htdocs/gcc-14/changes.html +++

[pushed] wwwdocs: gcc-14: various changes

I've taken the liberty of pushing the following changes to the GCC 14 release notes. Hope they look reasonable. David Malcolm (9): gcc-14: add caveat about not using analyzer on C++ gcc-14: add URLs to some options gcc-14: add null_terminated_string_arg attribute gcc-14: c++: note

[PATCH 1/9] wwwdocs: gcc-14: add caveat about not using analyzer on C++

Signed-off-by: David Malcolm --- htdocs/gcc-14/changes.html | 4 1 file changed, 4 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 9fd224c1..5cc729c5 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -49,6 +49,10 @@ a

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, 4 Apr 2024 at 17:33, Jonathan Wakely wrote: > > On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote: > > > > On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote: > > > I would appreciate more eyes on this to confirm my conclusions about > > > negative int_type values, and the proposed

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote: > > On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote: > > I would appreciate more eyes on this to confirm my conclusions about > > negative int_type values, and the proposed fix, make sense. > > The way something like this is handled in

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote: > > > > > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote: > > > > I would appreciate more eyes on this to confirm my conclusions about > > negative int_type values, and the proposed fix, make sense. > > > > Tested x86_64-linux. > > > > -- >8 -- > >

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote: > I would appreciate more eyes on this to confirm my conclusions about > negative int_type values, and the proposed fix, make sense. The way something like this is handled in glibc's ctype functions is that both branches are considered. For

Re: [gcc-13 backport Committed] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

On 4/4/2024 7:40 AM, Palmer Dabbelt wrote: On Thu, 04 Apr 2024 07:37:56 PDT (-0700), ja...@redhat.com wrote: On Thu, Apr 04, 2024 at 07:28:40AM -0700, Palmer Dabbelt wrote: I'm not sure if we need release maintainer approval, For cherry-picking one's own non-risky bugfixes for regression

[PATCH] rust: Add rust.install-dvi and rust.install-html rules

rust has the (empty) rust.dvi and rust.html rules, but lacks the (empty) rust.install-dvi and rust.install-html ones. 2024-04-04 Christophe Lyon gcc/rust/ * Make-lang.in (rust.install-dvi, rust.install-html): New rules. --- gcc/rust/Make-lang.in | 2 ++ 1 file changed, 2

[PATCH] modula2: Add m2.install-dvi in gcc/m2/Make-lang.in

m2 has a m2.dvi build rule, but lacks the m2.install-dvi one. 2024-04-04 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-dvi): New rule. --- gcc/m2/Make-lang.in | 12 1 file changed, 12 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in

[PATCH] go: Add go.install-dvi rule in go/Make-lang.in

go has a go.dvi build rule, but lacks the go.install-dvi one. 2024-04-04 Christophe Lyon gcc/go/ * Make-lang.in (go.install-dvi): New rule. --- gcc/go/Make-lang.in | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in index

[PATCH]middle-end vect: adjust loop upper bounds when peeling for gaps and early break [PR114403]

Hi All, The report shows that we end up in a situation where the code has been peeled for gaps and we have an early break. The code for peeling for gaps assume that a scalar loop needs to perform at least one iteration. However this doesn't take into account early break where the scalar loop

Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

> On 4 Apr 2024, at 16:29, Jonathan Wakely wrote: > > I would appreciate more eyes on this to confirm my conclusions about > negative int_type values, and the proposed fix, make sense. > > Tested x86_64-linux. > > -- >8 -- > > A negative value for the delim value passed to

[PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

I would appreciate more eyes on this to confirm my conclusions about negative int_type values, and the proposed fix, make sense. Tested x86_64-linux. -- >8 -- A negative value for the delim value passed to std::istream::ignore can never match any character in the stream, because the comparison

Re: [PATCH] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

> > gcc/ChangeLog: > > > > 2024-03-15 Martin Jambor > > > > PR ipa/111571 > > * ipa-param-manipulation.cc > > (ipa_param_body_adjustments::common_initialization): Avoid creating > > duplicate replacement entries. > > > > gcc/testsuite/ChangeLog: > > > > 2024-03-15 Martin Jambor

[PATCH 1/1] libgfortran: Fix compilation of gf_vsnprintf

The fallback function (gf_vsnprintf) to provide a vsnprintf function if the system library doesn't have one would not compile due to the variable name for the string's destination buffer not being updated after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba. This updates the

[PATCH 0/1] libgfortran: Fix compilation of gf_vsnprintf

The fallback function (gf_vsnprintf) to provide a vsnprintf function if the system library doesn't have one would not compile due to the variable name for the string's destination buffer not being updated after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba. This updates the

[PATCH] x86: Define __APX_F__ for -mapxf

Define __APX_F__ when APX is enabled. gcc/ PR target/114587 * config/i386/i386-c.cc (ix86_target_macros_internal): Define __APX_F__ when APX is enabled. gcc/testsuite/ PR target/114587 * gcc.target/i386/apx-2.c: New test. --- gcc/config/i386/i386-c.cc

Re: [gcc-13 backport PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

On Thu, 04 Apr 2024 07:37:56 PDT (-0700), ja...@redhat.com wrote: On Thu, Apr 04, 2024 at 07:28:40AM -0700, Palmer Dabbelt wrote: I'm not sure if we need release maintainer approval, For cherry-picking one's own non-risky bugfixes for regression or documentation bugs from trunk to release

Re: [gcc-13 backport PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

On Thu, Apr 04, 2024 at 07:28:40AM -0700, Palmer Dabbelt wrote: > I'm not sure if we need release maintainer approval, For cherry-picking one's own non-risky bugfixes for regression or documentation bugs from trunk to release branches no special approval is needed, or maintainer of the

Re: [gcc-13 backport PATCH] RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

On Wed, 03 Apr 2024 13:17:36 PDT (-0700), e...@rivosinc.com wrote: We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there is nothing to advance, but that is not the case for (...) functions returning by hidden reference which have one such artificial argument. This

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

> > > diff --git a/gcc/ipa-inline.cc b/gcc/ipa-inline.cc > > > index dc120e6da5a..9502a21c741 100644 > > > --- a/gcc/ipa-inline.cc > > > +++ b/gcc/ipa-inline.cc > > > @@ -682,7 +682,7 @@ can_early_inline_edge_p (struct cgraph_edge *e) > > > } > > > gcc_assert (gimple_in_ssa_p

Re: [PATCH] middle-end/114579 - speed up add_scope_conflicts

Hello, On Thu, 4 Apr 2024, Richard Biener wrote: > I have reworded the comment before the all-to-all conflict recording > since it seemed to be confusing and missing the point - but maybe I > am also missing something here. The point of the comment was to explain how this differs from building

Re: [RFC 0/2] black, isort, and flake8 configuration

> "Tom" == Tom Tromey writes: Tom> This short series adds configuration files for black ("opinionated" Tom> code formatter), isort (import sorter) and flake8 (Python lint) to Tom> libstdc++. Tom> I marked it as RFC since sometimes people don't like black's output. Tom> In gdb we use it --

Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

On 4/4/24 14:22, Jakub Jelinek wrote: > On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote: >> On 4/4/24 13:38, Ilya Leoshkevich wrote: >>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master? >>> >>> >>> libsanitizer/ChangeLog: >>> >>> *

[pushed] aarch64: Recognise svundef idiom [PR114577]

GCC 14 adds the header file arm_neon_sve_bridge.h to help interface SVE and Advanced SIMD code. One of the defined idioms is: svset_neonq (svundef_TYPE (), advsimd_vector) which simply reinterprets advsimd_vector as an SVE vector without regard for what's in the upper bits. GCC was failing

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

On 04/04/2024 14:10, Jan Hubicka wrote: gcc/ChangeLog: * builtins.cc (expand_builtin_fork_or_exec): Check condition_coverage_flag. * collect2.cc (main): Add -fno-condition-coverage to OBSTACK. * common.opt: Add new options -fcondition-coverage and

[PATCH] middle-end/114579 - speed up add_scope_conflicts

The following speeds up stack variable conflict detection by recognizing that the all-to-all conflict recording is only necessary for CFG merges as it's the unioning of the live variable sets that doesn't come with explicit mentions we record conflicts for. If we employ this optimization we have

Re: [PATCH] libatomic: Cleanup macros in atomic_16.S

Wilco Dijkstra writes: > As mentioned in > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648397.html , > do some additional cleanup of the macros and aliases: > > Cleanup the macros to add the libat_ prefixes in atomic_16.S. Emit the > alias to __atomic_ when ifuncs are not enabled in

Re: [PATCH] libatomic: Fix build for --disable-gnu-indirect-function [PR113986]

Wilco Dijkstra writes: > v2: > > Fix libatomic build to support --disable-gnu-indirect-function on AArch64. > Always build atomic_16.S, add aliases to the __atomic_ functions if > !HAVE_IFUNC. > Include auto-config.h in atomic_16.S to avoid having to pass defines via > makefiles. > Fix build

[PATCH v2] c++/modules: Track declarations imported from partitions [PR99377]

On Wed, Apr 03, 2024 at 02:16:25PM -0400, Jason Merrill wrote: > On 3/28/24 08:22, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > The testcase in comment 15 of the linked PR is caused because the > > following assumption in

Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote: > On 4/4/24 13:38, Ilya Leoshkevich wrote: > > Bootstrapped and regtested on s390x-redhat-linux. Ok for master? > > > > > > libsanitizer/ChangeLog: > > > > * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143): > >

Re: [PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

On 4/4/24 13:38, Ilya Leoshkevich wrote: > Bootstrapped and regtested on s390x-redhat-linux. Ok for master? > > > libsanitizer/ChangeLog: > > * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143): > Do not mention MSan and DFSan, which are not supported by GCC. Ok,

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

> gcc/ChangeLog: > > * builtins.cc (expand_builtin_fork_or_exec): Check > condition_coverage_flag. > * collect2.cc (main): Add -fno-condition-coverage to OBSTACK. > * common.opt: Add new options -fcondition-coverage and > -Wcoverage-too-many-conditions. > *

[PATCH] libsanitizer: Do not mention MSan and DFSan in an error message

Bootstrapped and regtested on s390x-redhat-linux. Ok for master? libsanitizer/ChangeLog: * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143): Do not mention MSan and DFSan, which are not supported by GCC. --- libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp

Re: [PATCH] c++: Keep DECL_SAVED_TREE of destructor instantiations in modules [PR104040]

On Wed, Apr 03, 2024 at 11:18:01AM -0400, Jason Merrill wrote: > On 4/2/24 20:57, Nathaniel Shead wrote: > > On Tue, Apr 02, 2024 at 01:18:17PM -0400, Jason Merrill wrote: > > > On 3/28/24 23:21, Nathaniel Shead wrote: > > > > - && !(modules_p () && DECL_DECLARED_INLINE_P (fn))) > > > > +

Re: [committed] amdgcn: Adjust GFX10/GFX11 cache coherency

Hi! To again state this in public: On 2024-03-22T15:54:49+, Andrew Stubbs wrote: > The RDNA devices have different cache architectures to the CDNA devices, and > the differences go deeper than just the assembler mnemonics, so we > probably need to generate different code to maintain

[PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

Hi, This adds a note to the GCC 14 release notes mentioning support for __has_{feature,extension} (PR60512). OK to commit? Thanks, Alex diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 9fd224c1..facead8d 100644 --- a/htdocs/gcc-14/changes.html +++

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the spaces to see if it is a comma or semicolon.

[PATCH] i386: Fix aes/vaes patterns [PR114576]

On Wed, Apr 19, 2023 at 02:40:59AM +, Jiang, Haochen via Gcc-patches wrote: > > > (define_insn "aesenc" > > > - [(set (match_operand:V2DI 0 "register_operand" "=x,x") > > > - (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x") > > > - (match_operand:V2DI

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, It looks good to me. Noting that this is not a regression, OK for mainline on condition that you keep a sharp eye out for any associated problems. Likewise with backporting to 13-branch. Thanks Paul On Thu, 4 Apr 2024 at 02:34, Jerry D wrote: > Hi all, > > The attached log entry

[MAINTAINERS] Update my email address and step down as arm port maintainer

Hi all, I'm stepping down as arm maintainer. Realistically I won't have good access to arm hardware to test patches for the port in the foreseeable future, or at least the more active M-profile parts of it. I'm still happy to keep helping with AArch64 though. I'm also adding myself to the DCO

Re: [PATCH] fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537]

On Thu, 4 Apr 2024, Jakub Jelinek wrote: > Hi! > > The following testcase is incorrectly rejected. The problem is that > for bit-fields native_encode_initializer expects the corresponding > CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case > here, it is wrapped into

Re: [PATCH] bitint: Handle m_bitfld_load cast in outer m_cast_conditional [PR114555]

On Thu, 4 Apr 2024, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase, because we use result of a PHI node > which is only conditional because of a m_cast_conditional on the outermost > loops PHI node argument and so is invalid SSA form. > > The following patch fixes it like

[PATCH] tree-optimization/114485 - neg induction with partial vectors

We can't use vect_update_ivs_after_vectorizer for partial vectors, the following fixes vect_can_peel_nonlinear_iv_p accordingly. Bootstrap and regtest running on x86_64-unknown-linux-gnu. We could handle this case by vectorizing the live lane but that's a different thing and might be tackled

[wwwdocs] projects/gomp/: Update TR12 status - fix misplaced GCC-14; add new items

TR12 update: * I misplaced one implemented in GCC 14 in one of the last commits * Same update as just proposed for libgomp.texi: - Renaming of 'coexecute' to 'workdistribute' (Post TR12 change to avoid confusion with Fortran's co_min, co_broadcast, ... intrinsic procedures for

[Patch] libgomp.texi: Update entries in OpenMP TR12 implementation status

Hi all, this patch updates the OpenMP TR12 status (to-do) items: (a) 'coexecute', added in TR12, was renamed after TR12 to 'workdistribute'. Reason: Feedback that 'co...' reminds of Fortran coarrays and the its intrinsic procedures: co_broadcast, co_max, co_min, co_reduce, co_sum

[PATCH] fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537]

Hi! The following testcase is incorrectly rejected. The problem is that for bit-fields native_encode_initializer expects the corresponding CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case here, it is wrapped into NON_LVALUE_EXPR by maybe_wrap_with_location. We could

[PATCH] bitint: Handle m_bitfld_load cast in outer m_cast_conditional [PR114555]

Hi! We ICE on the following testcase, because we use result of a PHI node which is only conditional because of a m_cast_conditional on the outermost loops PHI node argument and so is invalid SSA form. The following patch fixes it like similar cases elsewhere by adding needed intervening PHI(s).

[PATCH] tree-optimization/114551 - loop splitting and undefined overflow

When loop splitting hoists a guard computation it needs to make sure that can be safely evaluated at this place when it was previously only conditionally evaluated. The following fixes this for the case of undefined overflow. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.