[PATCH] s390: testsuite: Fix loop-interchange-16.c

Revert parameter max-completely-peel-times to 16, otherwise, the innermost loop is removed and we are left with no loop interchange which this test is all about. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/loop-interchange-16.c: Revert parameter max-completely-peel-times for s390.

Re: [PATCH] s390: testsuite: Fix loop-interchange-16.c

On Thu, Apr 11, 2024 at 9:02 AM Stefan Schulze Frielinghaus wrote: > > Revert parameter max-completely-peel-times to 16, otherwise, the > innermost loop is removed and we are left with no loop interchange which > this test is all about. > > gcc/testsuite/ChangeLog: > > * gcc.dg/tree-ssa/lo

Re: [PATCH] wwwdocs: gcc-14: Add RISC-V changes

Committed with fixes, thanks :) On Thu, Apr 11, 2024 at 12:18 AM Palmer Dabbelt wrote: > On Wed, 10 Apr 2024 00:58:00 PDT (-0700), kito.ch...@sifive.com wrote: > > --- > > htdocs/gcc-14/changes.html | 155 - > > 1 file changed, 154 insertions(+), 1 deletion(-

[PATCH] testsuite: Fix loop-interchange-16.c

Yes, that works, too. Will commit. Thanks, Stefan -- Prevent loop unrolling of the innermost loop because otherwise we are left with no loop interchange for targets like s390 which have a more aggressive loop unrolling strategy. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/loop-intercha

[PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027]

On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > So, try to add some other variable with larger size and smaller alignment > > > to the frame (and make sure it isn't optimized away). > > > > > > alignb above is the alignment of the first partition's var, if > > > align_frame_offset r

[PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

The issue here is that the `a?~t:t` pattern assumed (maybe correctly) that a here was always going to be a unsigned boolean type. This fixes the problem in both patterns to cast the operand to boolean type first. I should note that VRP seems to be keep on wanting to produce `a == 0?1:-2` from `((i

Re: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027]

On Thu, 11 Apr 2024, Jakub Jelinek wrote: > On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > > So, try to add some other variable with larger size and smaller > > > > alignment > > > > to the frame (and make sure it isn't optimized away). > > > > > > > > alignb above is the alignme

[PATCH] middle-end/114681 - condition coverage and inlining

When inlining a gcond it can map to multiple stmts, esp. with non-call EH. The following makes sure to pick up the remapped condition when dealing with condition coverage. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR middle-end/114681 * tree-inline.cc (copy_bb)

[PATCH] invoke.texi: Clarify -march=lujiazui

Hi! Yesterday I was searching which exact CPUs are affected by the PR114576 wrong-code issue and went from the PTA_* bitmasks in GCC, so arrived at the goldmont, goldmont-plus, tremont and lujiazui CPUs (as -march= cases which do enable -maes and don't enable -mavx). But when double-checking that

[PATCH] tree-optimization/109596 - wrong debug stmt move by copyheader

The following fixes an omission in r14-162-gcda246f8b421ba causing wrong-debug and a bunch of guality regressions. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/109596 * tree-ssa-loop-ch.cc (ch_base::copy_headers): Propagate debug stmts

Re: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

On Thu, Apr 11, 2024 at 10:43 AM Andrew Pinski wrote: > > The issue here is that the `a?~t:t` pattern assumed (maybe correctly) that a > here was always going to be a unsigned boolean type. This fixes the problem > in both patterns to cast the operand to boolean type first. > > I should note that

Re: [PATCH] openmp: Add support for the 'indirect' clause in C/C++

Hi! I've filed "OpenMP 'indirect' clause: dynamic image loading/unloading" for the following issue: On 2023-11-13T12:47:04+0100, Tobias Burnus wrote: > On 13.11.23 11:59, Thomas Schwinge wrote: Also, for my understanding: why is 'build_indirect_map' done at ke

Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output

On Thu, 25 Jan 2024 at 15:54, Christophe Lyon wrote: > > On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote: > > > > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote: > > > > > > GDB emits end of lines as \r\n, we currently match the reverse \n\r, > > > > We currently match [\n\r]+ which shou

[PATCH 2/3] bpf: remove huge memory waste with string allocation.

Code was allocating way too much space for the string. gcc/ChangeLog: * config/bpf/core-builtins.cc (process_enum_value): Corrected string allocation. --- gcc/config/bpf/core-builtins.cc | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/config/bpf/core

[PATCH 1/3] bpf: support more instructions to match CO-RE relocations

BPF supports multiple instructions to be CO-RE relocatable regardless of the position of the immediate field in the encoding. In particular, not only the MOV instruction allows a CO-RE relocation of its immediate operand, but the LD and ST instructions can have a CO-RE relocation happening to their

[PATCH 3/3] bpf: add line_info support to BTF.ext section.

This patch adds line_info debug information support to .BTF.ext sections. Line info information is used by the BPF verifier to improve error reporting and give more precise source core referenced errors. gcc/Changelog: * config/bpf/bpf-protos.h (bpf_output_call): Change prototype.

RE: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027]

> -Original Message- > From: Jakub Jelinek > Sent: Thursday, April 11, 2024 4:39 PM > To: Richard Biener ; Jeff Law ; > Liu, Hongtao > Cc: gcc-patches@gcc.gnu.org > Subject: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables > with - > fsanitize=address -fstack-protector

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

On 4/11/24 05:03, Li, Pan2 wrote: > Committed, thanks Juzhe and Kito. > > Pan Hi Pan, this commit caused a regression: FAIL: gcc.c-torture/compile/930623-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/930623-1.c -O1 (internal compiler error: in emit_vec_extract, at config/

RE: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

Thanks for reporting this. Just take a look from my test log that 930623-1.c is all pass. Thus I bet this difference comes from the build option --with-arch=rv32imac but my test script take rv64gcv. > I've built the git revision f3fdcf4a37a with > ../gcc-trunk/configure --target=riscv-unknown-

[PATCH][wwwdocs] modula2 update for changes.html, index.html, readings.html and frontends.html

Hello, Here are a proposed set of patches to highlight the changes in the modula-2 frontend for GCC 14.1. The patches also contain updates for: * readings.html: Add Modula-2 language standards. * index.html: Modula-2 listed in the languages supported by GCC. * frontends.html: Update now

[PATCH] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

Hi, The ldp/stp fusion pass can change the base of an access so that the two accesses end up using a common base register. So far we have been using adjust_address_nv to do this, but this means that we don't preserve other properties of the mem we're replacing. It seems better to use replace_equ

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

> On Apr 11, 2024, at 02:02, Martin Uecker wrote: > > Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao: >> >>> On Apr 10, 2024, at 15:05, Martin Uecker wrote: >>> >>> Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker: Am Mittwoch, dem 10.04.2024 um 17:35 +

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

> On Apr 10, 2024, at 17:56, Joseph Myers wrote: > > On Wed, 10 Apr 2024, Qing Zhao wrote: > >> Okay, the above is very clear, thanks a lot for the explanation. >> So, basically, for “counted-by” attribute: >> **The following is good: >> struct f { >> int b; >> int c; >> int a[] __attribu

Re: [PATCH v8 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.

Sid, Thanks a lot for your review! > On Apr 10, 2024, at 17:45, Siddhesh Poyarekar wrote: > > On 2024-03-29 12:07, Qing Zhao wrote: >> gcc/ChangeLog: >> * tree-object-size.cc (access_with_size_object_size): New function. >> (call_object_size): Call the new function. >> gcc/testsuite/

Re: [PATCH v8 4/5] Use the .ACCESS_WITH_SIZE in bound sanitizer.

Sid, Thanks a lot for the review. > On Apr 10, 2024, at 17:46, Siddhesh Poyarekar wrote: > > On 2024-03-29 12:07, Qing Zhao wrote: >> gcc/c-family/ChangeLog: >> * c-ubsan.cc (get_bound_from_access_with_size): New function. >> (ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZ

Re: [PATCH v8 5/5] Add the 6th argument to .ACCESS_WITH_SIZE

Sid, Thanks a lot for your review. Richard, Could you please comment on this patch? Is the middle-end part Okay for stage 1? Thanks. Qing On Apr 10, 2024, at 17:48, Siddhesh Poyarekar wrote: On 2024-03-29 12:07, Qing Zhao wrote: to carry the TYPE of the flexible array. Such information is n

Re: [PATCH v8 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

Sid and Richard, The C FE changes in this patch has been approved by Joseph. Could you please review the Middle-end change? thanks. Qing > On Apr 10, 2024, at 14:36, Joseph Myers wrote: > > On Fri, 29 Mar 2024, Qing Zhao wrote: > >> +/* For a SUBDATUM field of a structure or union DATUM, ge

[PATCH] libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33 [PR114692]

I plan to push this shortly, to fix the P1 ABI regression that Jakub reported earlier today. This will trigger 'make check-abi' failures for CI testers, because the baseline_sybols.txt wasn't regenerated for gcc 13.2.0 and so there are two symbols present in GLIBCXX_3.4.32 which are not in the bas

[PATCH v3 00/12] Add aarch64-w64-mingw32 target

Hello, Thank you for reviewing v2! v3 addresses all comments on v2. v3 Changes: - Exclude the aarch64_calling_abi declaration from the patch series. - Refactor x18 adjustment for MS ABI. - Remove unnecessary headers. - Add an extra comment to explain empty definitions. - Use gcc_unreachable for d

Re: [PATCH] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

Alex Coplan writes: > Hi, > > The ldp/stp fusion pass can change the base of an access so that the two > accesses end up using a common base register. So far we have been using > adjust_address_nv to do this, but this means that we don't preserve > other properties of the mem we're replacing. It

[PATCH v3 01/12] Introduce aarch64-w64-mingw32 target

From: Zac Walker Date: Fri, 1 Mar 2024 01:40:53 +0100 Subject: [PATCH v3 01/12] Introduce aarch64-w64-mingw32 target Add the initial aarch64-w64-mingw32 target for gcc. This is the first commit in a sequence of patch series to add new aarch64-w64-mingw32 target. Coauthors: Zac Walker , Mark Har

[PATCH v3 02/12] aarch64: Mark x18 register as a fixed register for MS ABI

From: Zac Walker Date: Thu, 11 Apr 2024 13:30:27 +0200 Subject: [PATCH v3 02/12] aarch64: Mark x18 register as a fixed register for MS ABI Define the MS ABI for aarch64-w64-mingw32. Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and STATIC_CHAIN_REGNUM for AArch64 MS ABI. The X18 register is

[PATCH v3 03/12] aarch64: Add aarch64-w64-mingw32 COFF

From: Zac Walker Date: Thu, 11 Apr 2024 14:46:07 +0200 Subject: [PATCH v3 03/12] aarch64: Add aarch64-w64-mingw32 COFF Define ASM specific for COFF format on AArch64. gcc/ChangeLog: * config.gcc: Add COFF format support definitions. * config/aarch64/aarch64-coff.h: New file. ---

[PATCH v3 04/12] Reuse MinGW from i386 for AArch64

From: Zac Walker Date: Fri, 1 Mar 2024 02:41:50 +0100 Subject: [PATCH v3 04/12] Reuse MinGW from i386 for AArch64 This patch creates a new config/mingw directory to share MinGW related definitions, and moves there the corresponding existing files from config/i386. gcc/ChangeLog: * confi

[PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

Hi! The following patch regenerates the ABI files for 13 branch (I've only changed the Linux files which were updated in r13-7289, all but m68k, riscv64 and powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited). We've added one symbol very early in the 13.2 cycle, but then added 2

[PATCH v3 05/12] Rename section and encoding functions from i386 which will be used in aarch64

From: Zac Walker Date: Tue, 20 Feb 2024 17:22:31 +0100 Subject: [PATCH v3 05/12] Rename section and encoding functions from i386 which will be used in aarch64 gcc/ChangeLog: * config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO): Rename functions in mingw folder which will be r

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 14:52, Jakub Jelinek wrote: > > Hi! > > The following patch regenerates the ABI files for 13 branch (I've only changed > the Linux files which were updated in r13-7289, all but m68k, riscv64 and > powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited). > We've

[PATCH v3 06/12] Exclude i386 functionality from aarch64 build

From: Zac Walker Date: Thu, 11 Apr 2024 13:38:59 +0200 Subject: [PATCH v3 06/12] Exclude i386 functionality from aarch64 build This patch defines TARGET_AARCH64_MS_ABI in config.gcc and uses it to exclude i386 functionality from aarch64 build and adjust MinGW headers for AArch64 MS ABI. gcc/Chan

[PATCH v3 07/12] aarch64: Add Cygwin and MinGW environments for AArch64

From: Zac Walker Date: Thu, 11 Apr 2024 13:41:51 +0200 Subject: [PATCH v3 07/12] aarch64: Add Cygwin and MinGW environments for AArch64 Define Cygwin and MinGW environment such as types, SEH definitions, shared libraries, etc. gcc/ChangeLog: * config.gcc: Add Cygwin and MinGW difinitio

[PATCH v3 08/12] aarch64: Add SEH to machine_function

From: Zac Walker Date: Tue, 20 Feb 2024 18:10:08 +0100 Subject: [PATCH v3 08/12] aarch64: Add SEH to machine_function SEH is not enabled in aarch64-w64-mingw32 target yet. However, it is needed to be declared in machine_function for reusing winnt.cc. gcc/ChangeLog: * config/aarch64/aarc

[PATCH v3 09/12] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

From: Zac Walker Date: Thu, 11 Apr 2024 13:43:23 +0200 Subject: [PATCH v3 09/12] Rename "x86 Windows Options" to "Cygwin and MinGW Options" Rename "x86 Windows Options" to "Cygwin and MinGW Options". It will be used also for AArch64. gcc/ChangeLog: * config/i386/mingw-w64.opt.urls: Ren

[PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

I think we also want the same change for i386. -- >8 -- libstdc++-v3/ChangeLog: * config/abi/post/i386-linux-gnu/baseline_symbols.txt: Regenerate. --- .../config/abi/post/i386-linux-gnu/baseline_symbols.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libstdc++-

[PATCH v3 10/12] aarch64: Build and add objects for Cygwin and MinGW for AArch64

From: Zac Walker Date: Tue, 20 Feb 2024 13:55:51 +0100 Subject: [PATCH v3 10/12] aarch64: Build and add objects for Cygwin and MinGW for AArch64 gcc/ChangeLog: * config.gcc: Build and add objects for Cygwin and MinGW. Add Cygwin and MinGW options to the target. --- gcc/config.g

Re: Combine patch ping

On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote: > On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool > wrote: > > This is never okay. You cannot commit a patch without approval, *ever*. This is the biggest issue, to start with. It is fundamental. > > That patch is also obvious --

[PATCH v3 11/12] aarch64: Add aarch64-w64-mingw32 target to libatomic

From: Zac Walker Date: Fri, 1 Mar 2024 02:23:45 +0100 Subject: [PATCH v3 11/12] aarch64: Add aarch64-w64-mingw32 target to libatomic libatomic/ChangeLog: * configure.tgt: Add aarch64-w64-mingw32 target. --- libatomic/configure.tgt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d

[PATCH v3 12/12] Add aarch64-w64-mingw32 target to libgcc

From: Zac Walker Date: Mon, 12 Feb 2024 15:22:47 +0100 Subject: [PATCH v3 12/12] Add aarch64-w64-mingw32 target to libgcc Reuse MinGW definitions from i386 for libgcc. Move reused files to libgcc/config/mingw folder. libgcc/ChangeLog: * config.host: Add aarch64-w64-mingw32 target. Adjus

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote: > I think we also want the same change for i386. > > -- >8 -- > > libstdc++-v3/ChangeLog: > > * config/abi/post/i386-linux-gnu/baseline_symbols.txt: > Regenerate. Not sure about that, the file is missing all the 3.4.30

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

On Thu, 11 Apr 2024 at 15:07, Jakub Jelinek wrote: > > On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote: > > I think we also want the same change for i386. > > > > -- >8 -- > > > > libstdc++-v3/ChangeLog: > > > > * config/abi/post/i386-linux-gnu/baseline_symbols.txt: > >

[PATCH, OpenACC 2.7, v3] Adjust acc_map_data/acc_unmap_data interaction with reference counters

Hi Thomas, On 2024/3/15 7:24 PM, Thomas Schwinge wrote: > Hi Chung-Lin! > > I realized: please add "PR libgomp/92840" to the Git commit log, as your > changes are directly a continuation of my earlier changes. Okay, I'll remember to do that. ... > - if (n->refcount != REFCOUNT_INFINITY

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Apr 11 2024, Jakub Jelinek wrote: > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj > 2023-05-04 09:42:43.277271065 +0200 > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt > 2024-04-11 15:44:07.113985138 +0200 > @@ -3214,6 +3214,7 @@ FUNC:_Z

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote: > > On Apr 11 2024, Jakub Jelinek wrote: > > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj > > 2023-05-04 09:42:43.277271065 +0200 > > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt > > 2

[PATCH v2 00/13] Add aarch64-w64-mingw32 target

Wednesday, April 10, 2024 8:40 PM Richard Sandiford wrote: > Thanks for the updates and sorry again for the slow review. > I've replied to some of the patches in the series but otherwise it looks good > to > me. > > If you agree with the suggested changes then the series is OK for stage 1, >

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 15:13, Jonathan Wakely wrote: > > On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote: > > > > On Apr 11 2024, Jakub Jelinek wrote: > > > > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj > > > 2023-05-04 09:42:43.277271065 +0200 > > > +++ li

[pushed] modula2: add modula-2 language section to languages supported by GCC

Pushed to trunk as r14-9915-g0dc39dee836761f1bc993d760f4ed5f3d127897a This patch introduces a small modula-2 language section to the Language Standards Supported by GCC node. gcc/ChangeLog: * doc/standards.texi (Language Standards Supported by GCC): Add Modula-2 language sectio

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Thu, Apr 11, 2024 at 03:16:02PM +0100, Jonathan Wakely wrote: > > That symbol should not be in this symver, see > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and > > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html > > Jakub's patch is just adding the symbols from gcc-

[PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

Hi! While the previous patch was regeneration from 13.2 release (with hand edits for arches I don't have libraries for but which are still well maintained), thius one is regeneration from the trunk (this time for hand edits everywhere for the PR114692 https://gcc.gnu.org/pipermail/libstdc++/2024-A

[pushed] modula2: add modula-2 language section to languages supported by GCC

Pushed to trunk as r14-9915-g0dc39dee836761f1bc993d760f4ed5f3d127897a This patch introduces a small modula-2 language section to the Language Standards Supported by GCC node. gcc/ChangeLog: * doc/standards.texi (Language Standards Supported by GCC): Add Modula-2 language sectio

[committed 0/5 v2] aarch64: FMV feature list fixes

This includes the following changes from v1: 1/5: Add missing testcase update. (I misread my test diffs, but Linaro precommit picked this up as well.) 2/5: Address review comments and add a testcase. 5/5: Remove "memtag", "ssbs" and "ls64" instead of renaming them. Bootstrapped and regression tes

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 10/04/2024 23:48, Ajit Agarwal wrote: > Hello Alex: > > On 10/04/24 7:52 pm, Alex Coplan wrote: > > Hi Ajit, > > > > On 10/04/2024 15:31, Ajit Agarwal wrote: > >> Hello Alex: > >> > >> On 10/04/24 1:42 pm, Alex Coplan wrote: > >>> Hi Ajit, > >>> > >>> On 09/04/2024 20:59, Ajit Agarwal wrote: >

[committed 1/5 v2] aarch64: Reorder FMV feature priorities

Some higher priority FMV features were dependent subsets of lower priority features. Fix this, using the new priorities specified in https://github.com/ARM-software/acle/pull/279. gcc/ChangeLog: * config/aarch64/aarch64-option-extensions.def: Reorder FMV entries. gcc/testsuite/ChangeLog

[committed 2/5 v2] aarch64: Fix FMV array iteration bounds

There was an assumption in some places that the aarch64_fmv_feature_data array contained FEAT_MAX elements. While this assumption held up till now, it is safer and more flexible to use the array size directly. Also fix the lower bound in compare_feature_masks to use ">=0" instead of ">0", and add

[committed 4/5] aarch64: Remove unsupported FMV features

It currently isn't possible to support function multiversioning features properly in GCC without also enabling the extension in the command line options (with the exception of features such as "rpres" that do not require assembler support). We therefore remove unsupported features from GCC's list

[committed 3/5] aarch64: Fix typo and make rdma/rdm alias for FMV

gcc/ChangeLog: * config/aarch64/aarch64-option-extensions.def: Fix "rmd"->"rdm", and add FMV to "rdma". * config/aarch64/aarch64.cc (FEAT_RDMA): Define as FEAT_RDM. diff --git a/gcc/config/aarch64/aarch64-option-extensions.def b/gcc/config/aarch64/aarch64-option-extensio

Re: [PATCH, OpenACC 2.7] Connect readonly modifier to points-to analysis

Hi Chung-Lin, Richard! >From me just a few mechanical pieces, see below. Richard, are you able to again comment on Chung-Lin's general strategy, as I'm not at all familiar with those parts of the code? On 2024-04-03T19:50:55+0800, Chung-Lin Tang wrote: > On 2023/10/30 8:46 PM, Richard Biener wr

[committed 5/5 v2] aarch64: Remove FMV features whose names may change

Some architecture features have been combined under a single command line flag, but have been assigned multiple FMV feature names with the command line flag name enabling only a subset of these features in the FMV specification. I've proposed reallocating names in the FMV specification to match th

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 15:18, Jakub Jelinek wrote: > > Hi! > > While the previous patch was regeneration from 13.2 release (with hand > edits for arches I don't have libraries for but which are still well > maintained), thius one is regeneration from the trunk (this time for > hand edits everywhere

Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target

Evgeny Karpov writes: > Wednesday, April 10, 2024 8:40 PM > Richard Sandiford wrote: > >> Thanks for the updates and sorry again for the slow review. >> I've replied to some of the patches in the series but otherwise it looks >> good to >> me. >> >> If you agree with the suggested changes then

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Apr 11 2024, Jakub Jelinek wrote: > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj > 2024-04-11 15:55:49.982325397 +0200 > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt > 2024-04-11 16:10:05.206559463 +0200 > @@ -497,6 +497,7 @@ F

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote: > +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31 > +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 15:36, Andreas Schwab wrote: > > On Apr 11 2024, Jakub Jelinek wrote: > > > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj > > 2024-04-11 15:55:49.982325397 +0200 > > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Apr 11 2024, Jakub Jelinek wrote: > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote: >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31 >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9_

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

On Thu, 11 Apr 2024 at 15:46, Andreas Schwab wrote: > > On Apr 11 2024, Jakub Jelinek wrote: > > > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote: > >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3

[PATCH] Update GCC 14.1 library versions in docs

Hi! When we are already touching this topic, here is a patch like r13-5126 which documents the upcoming release symbol versions in the documentation. Ok for trunk? 2024-04-11 Jakub Jelinek * doc/xml/manual/abi.xml: Add latest library versions. * doc/html/manual/abi.html: Rege

Re: [PATCH] Update GCC 14.1 library versions in docs

On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote: > > Hi! > > When we are already touching this topic, here is a patch like r13-5126 > which documents the upcoming release symbol versions in the documentation. > > Ok for trunk? OK, thanks. > > 2024-04-11 Jakub Jelinek > > * doc/xml/ma

Re: Combine patch ping

> Am 11.04.2024 um 16:03 schrieb Segher Boessenkool > : > > On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote: >>> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool >>> wrote: >>> This is never okay. You cannot commit a patch without approval, *ever*. > > This is the biggest iss

[PING] Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity.

PING: I remind you that the patch for the computation of complexity for unsupported addressing modes ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 ) has been sent: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html

[PATCH] aarch64: Fix _BitInt testcases

This patch fixes some testisms introduced by: commit 5aa3fec38cc6f52285168b161bab1a869d864b44 Author: Andre Vieira Date: Wed Apr 10 16:29:46 2024 +0100 aarch64: Add support for _BitInt The testcases were relying on an unnecessary sign-extend that is no longer generated. The tested versi

Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.

Hi Cupertino, On 4/11/24 04:11, Cupertino Miranda wrote: > Code was allocating way too much space for the string. A little bit more description would not hurt. Perhaps you could say something like: "The BPF backend was allocating an unnecessarily large string when constructing CO-RE relocations

Re: [PATCH] aarch64: Fix _BitInt testcases

"Andre Vieira (lists)" writes: > This patch fixes some testisms introduced by: > > commit 5aa3fec38cc6f52285168b161bab1a869d864b44 > Author: Andre Vieira > Date: Wed Apr 10 16:29:46 2024 +0100 > > aarch64: Add support for _BitInt > > The testcases were relying on an unnecessary sign-extend

[PATCH] libstdc++: Compile std::allocator instantiations as C++20

I'm considering this late patch for gcc-14 to workaround an issue discovered by a recent Clang change. I'm not yet sure if Clang is right to require these symbols. It's not really clear, because always_inline isn't part of the standard so it's not clear how it should interact with explicit instant

Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.

Hi David, Thanks for the review. Will apply the changes. Nice catch and optimization with the vlen size. Cupertino David Faust writes: > Hi Cupertino, > > On 4/11/24 04:11, Cupertino Miranda wrote: >> Code was allocating way too much space for the string. > > A little bit more description wou

Re: [PATCH] libstdc++: Compile std::allocator instantiations as C++20

On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely wrote: > > I'm considering this late patch for gcc-14 to workaround an issue > discovered by a recent Clang change. > > I'm not yet sure if Clang is right to require these symbols. It's not > really clear, because always_inline isn't part of the standa

[PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

Hi, contrib/check-params-in-docs.py is a script that checks that all options reported with ./gcc/xgcc -Bgcc --help=param are in gcc/doc/invoke.texi and vice versa. gcn-preferred-vectorization-factor is in the manual but normally not reported by --help, probably because I do not have gcn offload co

Re: [PATCH] libstdc++: Compile std::allocator instantiations as C++20

> On 11 Apr 2024, at 18:33, Ville Voutilainen > wrote: > > On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely wrote: >> >> I'm considering this late patch for gcc-14 to workaround an issue >> discovered by a recent Clang change. >> >> I'm not yet sure if Clang is right to require these symbols.

Re: [PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

Hi! On 2024-04-11T19:52:51+0200, Martin Jambor wrote: > contrib/check-params-in-docs.py is a script that checks that all > options reported with ./gcc/xgcc -Bgcc --help=param are in > gcc/doc/invoke.texi and vice versa. Eh, first time I'm hearing about this one! (a) Shouldn't this be running as

[PATCH] btf: emit non-representable bitfield as void

This patch fixes an issue with mangled BTF that could occur when a struct type contains a bitfield member which cannot be represented in BTF. It is undefined what should happen in such cases, but we can at least do something reasonable. Commit 936dd627cd9 "btf: do not skip members of data type

New Swedish PO file for 'gcc' (version 14.1-b20240218)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-14.1-b20240218.sv.po'

Re: Combine patch ping

On Thu, Apr 11, 2024 at 4:02 PM Segher Boessenkool wrote: > > On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote: > > On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool > > wrote: > > > This is never okay. You cannot commit a patch without approval, *ever*. > > This is the biggest issue

Re: [PATCH] btf: emit non-representable bitfield as void

On 4/11/24 11:53, David Faust wrote: This patch fixes an issue with mangled BTF that could occur when a struct type contains a bitfield member which cannot be represented in BTF. It is undefined what should happen in such cases, but we can at least do something reasonable. Commit 936dd627cd

[r14-9912 Regression] FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i on Linux/x86_64

On Linux/x86_64, c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit commit c7e8a8d814229fd6fc4c16c2452f15dddc613479 Author: Richard Biener Date: Thu Apr 11 11:08:07 2024 +0200 tree-optimization/109596 - wrong debug stmt move by copyheader caused FAIL: gcc.dg/guality/pr43051

Re: [PATCH] btf: emit non-representable bitfield as void

On 4/11/24 13:40, Indu Bhagat wrote: > On 4/11/24 11:53, David Faust wrote: >> This patch fixes an issue with mangled BTF that could occur when >> a struct type contains a bitfield member which cannot be represented >> in BTF. It is undefined what should happen in such cases, but we can >> at l

[PATCH v2] btf: emit non-representable bitfield as void

[Changes from v1: use btf_dmd_representable_bitfield_p in btf_asm_sou_member, instead of a slightly incorrect equivalent check.] This patch fixes an issue with mangled BTF that could occur when a struct type contains a bitfield member which cannot be represented in BTF. It is undefined what shou

[PATCH] btf: fix a possibly misleading asm debug comment

This patch fixes a small error that could occur in the debug comment when emitting a type reference with btf_asm_type_ref. While working on a previous patch, I noticed the following in the asm output for the test btf-bitfields-4.c: ... .long 0x39# MEMBER 'c' idx=3 .l

Re: [PATCH v2] btf: emit non-representable bitfield as void

On 4/11/24 14:01, David Faust wrote: [Changes from v1: use btf_dmd_representable_bitfield_p in btf_asm_sou_member, instead of a slightly incorrect equivalent check.] This patch fixes an issue with mangled BTF that could occur when a struct type contains a bitfield member which cannot be repres

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

On 4/11/2024 5:45 AM, Li, Pan2 wrote: Thanks for reporting this. Just take a look from my test log that 930623-1.c is all pass. Thus I bet this difference comes from the build option --with-arch=rv32imac but my test script take rv64gcv. I've built the git revision f3fdcf4a37a with ../gcc-tru

[PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

FYI: This patch is an update to Will Schmidt's patches to fix PR101865: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601825.html https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601823.html ...taking into consideration patch reviews received than. I also found a few more

Re: [PATCH] btf: fix a possibly misleading asm debug comment

On 4/11/24 14:02, David Faust wrote: This patch fixes a small error that could occur in the debug comment when emitting a type reference with btf_asm_type_ref. While working on a previous patch, I noticed the following in the asm output for the test btf-bitfields-4.c: ... .long

RE: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

> -Original Message- > From: Richard Biener > Sent: Thursday, April 11, 2024 2:31 AM > To: Andrew Pinski (QUIC) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 > bit > types [PR114666] > > On Thu, Apr 11, 2024 at 10:43 AM Andre

[PATCH 0/3] c++/modules: Fix some small issues with exported using-decls

This patch series fixes a few issues with exported using-declarations that have come up recently. I was hoping to fix PR114683 and PR114685 as well, but the issues there look to be much more involved and I'm not yet sure how to handle them. They're ultimately caused by using-declarations just ins

[PATCH 1/3] c++/modules: Only emit exported GMF usings [PR114600]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- A typo in r14-6978 made us emit too many things. This ensures that we don't emit using-declarations from the GMF that we don't need to. PR c++/114600 gcc/cp/ChangeLog: * module.cc (depset::hash::add_bindi

  1   2   >