Re: [PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

I can't review this stuff. Let kito review this. Thanks. juzhe.zh...@rivai.ai From: pan2.li Date: 2024-03-18 14:05 To: gcc-patches CC: juzhe.zhong; kito.cheng; yanzhang.wang; Pan Li Subject: [PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v")) From: Pan Li This patch would

[PATCH v1] RISC-V: Bugfix ICE for __attribute__((target("arch=+v"))

From: Pan Li This patch would like to fix one ICE for __attribute__((target("arch=+v")) and likewise extension(s). Given we have sample code as below: void __attribute__((target("arch=+v"))) test_2 (int *a, int *b, int *out, unsigned count) { unsigned i; for (i = 0; i < count; i++)

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

On 21/04/22 04:31 -0700, Kaz Kylheku wrote: libcpp/ChangeLog 2022-04-21 Kaz Kylheku This change introduces a pair of related macros __EXP_COUNTER__ and __UEXP_COUNTER__. These macros access integer values which enumerate macro expansions. They can be used for

Re: [PATCH] testsuite: Define _POSIX_C_SOURCE for test

On 2024-03-17 18:48, Mike Stump wrote: On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON wrote: Ok for trunk? Ok. Pushed as basepoints/gcc-14-9513-g58753dba800 to trunk. Kind regards, Torbjörn

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

On 18/03/24 07:30 +, Jonathan Wakely wrote: On 21/04/22 04:31 -0700, Kaz Kylheku wrote: libcpp/ChangeLog 2022-04-21 Kaz Kylheku This change introduces a pair of related macros __EXP_COUNTER__ and __UEXP_COUNTER__. These macros access integer values which

Re: [PATCH] Predefine __STRICT_ALIGN__ if STRICT_ALIGNMENT

On Sun, 17 Mar 2024, YunQiang Su wrote: > Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access, > and RISC-V predefines __riscv_misaligned_avoid, while other ports > that support -mstrict-align/-mno-unaligned-access don't have such > macro, and these backend macros are only avaiable

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

On Sun, 17 Mar 2024 at 18:14, François Dumont wrote: > > I was a little bit too confident below. After review of all _M_singular > usages I found another necessary fix. > > After this one for sure we will be able to define > __cpp_lib_null_iterators even in Debug mode. > > libstdc++: Fix

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

On Sun, 17 Mar 2024 at 16:52, François Dumont wrote: > > > > > > OK for trunk, thanks! > > > > I think this is OK to backport to 13 too. > > > > Maybe after this we can define the __cpp_lib_null_itetators macro for > > debug mode? > > > After this fix of local_iterator I think we can indeed. > >

[patch,avr,applied] Tweak xor insn constraints

xor insn allows some more values without the requirement of a scratch register. This patch adds new constraint alternative for such values. The output function avr_out_bitop already handles these cases, so no change is needed there. Johann -- avr.md - Tweak xor insn constraints. xor insn

Re: [Patch][RFC] GCN: Define ISA archs in gcn-devices.def and use it

On Fri, Mar 15, 2024 at 5:36 PM Andrew Stubbs wrote: > > On 15/03/2024 13:56, Tobias Burnus wrote: > > Hi Andrew, > > > > Andrew Stubbs wrote: > >> This is more-or-less what I was planning to do myself, but as I want > >> to include all the other features that get parametrized in gcn.cc, > >>

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

Here is a patch for the GCC bug 109429.

Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

David: Ping. Le 2024-03-10 à 07 h 05, Iain Buclaw a écrit : Excerpts from David Malcolm's message of März 5, 2024 4:09 pm: On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote: Hi. See answers below. On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote: On Thu, 2023-11-09 at 17:27

Re: [pushed] aarch64: Define out-of-class static constants

Hi Richard, I think this patch is breaking the build of aarch64-none-elf and aarch64-none-linux-gnu targets, when building with GCC 4.8. This is not an issue when building with GCC 7.5. Kind regards, Vasee From: Richard Sandiford Sent: 06 March 2024

Re: [PATCH] i386 [stv]: Handle REG_EH_REGION note [pr111822].

On Mon, Mar 18, 2024 at 11:52 AM liuhongt wrote: > > Commit r14-9459-g618e34d56cc38e only handles > general_scalar_chain::convert_op. The patch also handles > timode_scalar_chain::convert_op to avoid potential similar bug. > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for

Re: RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model

> Hello, > > Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit : > (...) > > gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +- > > looks like the patch pushed to master lost the file rename. > I get a bootstrap failure caused by the missing zn4zn5.md file. > > Can you

[PATCH] LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

We were assuming 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 is causing gcc.dg/c23-stdarg-6.c and gcc.dg/c23-stdarg-8.c to fail.

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

On Thu, 7 Mar 2024 at 21:48, Evgeny Karpov wrote: > > Monday, March 4, 2024 > Evgeny Karpov wrote: > > > > > Changes from v1 to v2: > > Adjust the target name to aarch64-*-mingw* to exclude the big-endian target > > from support. > > Exclude 64-bit ISA. > > Rename enum calling_abi to

Re: [PATCH] i386 [stv]: Handle REG_EH_REGION note [pr111822].

On Mon, Mar 18, 2024 at 6:59 PM Uros Bizjak wrote: > > On Mon, Mar 18, 2024 at 11:52 AM liuhongt wrote: > > > > Commit r14-9459-g618e34d56cc38e only handles > > general_scalar_chain::convert_op. The patch also handles > > timode_scalar_chain::convert_op to avoid potential similar bug. > > > >

[PATCH] i386 [stv]: Handle REG_EH_REGION note [pr111822].

Commit r14-9459-g618e34d56cc38e only handles general_scalar_chain::convert_op. The patch also handles timode_scalar_chain::convert_op to avoid potential similar bug. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk and backport to releases/gcc-13 branch? gcc/ChangeLog:

[PATCH] Document -fexcess-precision=16.

Ok for trunk? gcc/ChangeLog: * doc/invoke.texi: Document -fexcess-precision=16. --- gcc/doc/invoke.texi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 85c938d4a14..673420fdd3e 100644 --- a/gcc/doc/invoke.texi +++

Re: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

Hi! On Mon, 4 Mar 2024 at 18:44, Evgeny Karpov wrote: > > From: Zac Walker > Date: Fri, 1 Mar 2024 10:49:28 +0100 > Subject: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for > AArch64 > > Define Cygwin and MinGW environment such as types, SEH definitions, > shared libraries,

Re: [PATCH] ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

> gcc/ChangeLog: > > 2024-03-06 Martin Jambor > > PR ipa/108802 > PR ipa/114254 > * ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking > at COMPONENT_REFs directly from a PARM_DECL, also recognize loads from > a pointer parameter. >

RISC-V: Use convert instructions instead of calling library functions

As RV has round instructions it is reasonable to use them instead of calling the library functions. With my patch for the following C code: double foo(double a) { return ceil(a); } GCC generates the following ASM code (before it was tail call) foo: fabs.d fa4,fa0 lui

Re: [PATCH, RFC] combine: Don't truncate const operand of AND if it's no benefits

Hi, Gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647533.html Thanks Gui Haochen 在 2024/3/11 13:41, HAO CHEN GUI 写道: > Hi, > This patch tries to fix the problem when a canonical form doesn't benefit > on a specific target. The const operand of AND is and with the

Re: RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model

Hello, Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit : (...) gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +- looks like the patch pushed to master lost the file rename. I get a bootstrap failure caused by the missing zn4zn5.md file. Can you have a look?

Re: [PATCH, OpenACC 2.7] struct/array reductions for Fortran

Hi Chung-Lin! Thanks for your work here, which I'm beginning to look into (prerequisite "[PATCH, OpenACC 2.7] Implement reductions for arrays and structs", first, of course); it'll take me some time. In non-offloading testing, I noticed for x86_64-pc-linux-gnu '-m32': +PASS:

Re: [PATCH] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

On 3/18/24 9:36 AM, Segher Boessenkool wrote: > Hi! > > On Fri, Feb 23, 2024 at 03:04:13PM +0530, jeevitha wrote: >> PTImode attribute assists in generating even/odd register pairs on 128 bits. > > It is a mode, not an attribute. Attributes are on declarations, while > modes are on a much more

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

On 2024-03-18 12:28, Qing Zhao wrote: This should probably bail out if object_size_type & OST_DYNAMIC == 0. Okay. Will add this. When add this into access_with_size_object_size, I found some old bugs in early_object_sizes_execute_one, and fixed them as well. Would you be able to isolate

Re: [PATCH] testsuite: Turn errors back into warnings in arm/acle/cde-mve-error-2.c

On 15/03/2024 15:13, Thiago Jung Bauermann wrote: Hello, "Richard Earnshaw (lists)" writes: On 13/01/2024 20:46, Thiago Jung Bauermann wrote: diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c index

[COMMITTED] testsuite: Fix excess errors for new modules testcases on powerpc [PR114320]

Tested on powerpc64-unknown-linux-gnu, committed as obvious. -- >8 -- On some configurations, PowerPC emits -Wpsabi warnings when using IEEE long doubles on a machine configured with IBM long double by default. This patch suppresses these warnings for this testcase. PR testsuite/114320

Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]

On Thu, Mar 07, 2024 at 11:46:54PM +0100, Uros Bizjak wrote: > > Can't you just describe the dataflow then, without an unspec? An unspec > > by definition does some (unspecified) operation on the data. > > Previously, it was defined as: > > (define_insn "*pushfl2" >[(set (match_operand:W 0

Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]

On Mon, Mar 18, 2024 at 3:46 PM Segher Boessenkool wrote: > > On Thu, Mar 07, 2024 at 11:27:28PM +0100, Uros Bizjak wrote: > > On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote: > > > > > (unspec:DI [ > > > > > (reg:CC 17 flags) > > > > > ] UNSPEC_PUSHFL) > > > > > > > > But that

[PATCH] tree-optimization/114375 - disallow SLP discovery of permuted mask loads

We cannot currently handle permutations of mask loads in code generation or permute optimization. But we simply drop any permutation on the floor, so the following instead rejects the SLP build rather than producing wrong-code. I've also made sure to reject them in vectorizable_load for

Re: [PATCH] Document -fexcess-precision=16.

On Mon, 18 Mar 2024, liuhongt wrote: > +If @option{-fexcess-precision=16} is specified, casts and assignments of > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their > +semantic types if they're supported by the target. Isn't that option about rounding results of all

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

On 2024-03-18 00:30, Jonathan Wakely wrote: >>+@item __EXP_COUNTER__ >>+This macro's name means "(macro) expansion counter". >>+Outside of macro replacement sequences, it expands to the integer >>+token @code{1}. This make it possible to easily test for the presence >>+of this feature using

Re: [PATCH v2] RISC-V: Introduce option -mrvv-max-lmul for RVV autovec

LGTM as well. Regards Robin

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

On Mar 13, 2024, at 15:17, Qing Zhao wrote: On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote: On 2024-02-16 14:47, 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/ChangeLog: *

Re: [PATCH] gcc_update: Add missing generated files

On Fri, 1 Mar 2024, Jonathan Wakely wrote: > I'm seeing errors for --enable-maintainer-mode builds due to incorrectly > regenerating these files. They should be touched by gcc_update so they > aren't regenerated unnecessarily. > > contrib/ChangeLog: > > * gcc_update: Add more generated

Re: [PATCH] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

Hi! On Fri, Feb 23, 2024 at 03:04:13PM +0530, jeevitha wrote: > PTImode attribute assists in generating even/odd register pairs on 128 bits. It is a mode, not an attribute. Attributes are on declarations, while modes are on a much more fundamental level (every value has a mode, in GCC!) > When

Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]

On Mon, Mar 18, 2024 at 3:51 PM Segher Boessenkool wrote: > > On Thu, Mar 07, 2024 at 11:46:54PM +0100, Uros Bizjak wrote: > > > Can't you just describe the dataflow then, without an unspec? An unspec > > > by definition does some (unspecified) operation on the data. > > > > Previously, it was

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

> On Mar 18, 2024, at 12:30, Siddhesh Poyarekar wrote: > > On 2024-03-18 12:28, Qing Zhao wrote: This should probably bail out if object_size_type & OST_DYNAMIC == 0. >>> Okay. Will add this. >> When add this into access_with_size_object_size, I found some old bugs in >>

Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]

On Thu, Mar 07, 2024 at 11:27:28PM +0100, Uros Bizjak wrote: > On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote: > > > > (unspec:DI [ > > > > (reg:CC 17 flags) > > > > ] UNSPEC_PUSHFL) > > > > > > But that is invalid RTL? The only valid use of a CC is written as > > >

[PATCH] rs6000: Fix up setup_incoming_varargs [PR114175]

Hi! The c23-stdarg-8.c test (as well as the new test below added to cover even more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets as well. Like in the r14-9503-g218d174961 change on x86-64 we need to advance next_cum after the hidden return pointer argument even in case

[PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

Monday, March 18, 2024 2:27 PM Christophe Lyon wrote: > > +/* Disable SEH and declare the required SEH-related macros that are > > +still needed for compilation. */ #undef TARGET_SEH #define > > +TARGET_SEH 0 > > + > > +#define SSE_REGNO_P(N) 0 > > +#define GENERAL_REGNO_P(N) 0 > I think you

[pushed] analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902, PR110928, PR111305, PR111441]

Various analyzer ICEs in our bugzilla relate to sloppy use of types within bounds-checking. The bounds-checking code works by comparing symbolic *bit* offsets, and we don't have a good user-facing type that can represent such an offset (ptrdiff_type_node is for *byte* offsets). ana::svalue

[pushed] analyzer: support null operands in remove_ssa_names

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Successful run of analyzer integration tests on x86_64-pc-linux-gnu. Pushed to trunk as r14-9526-g3c2827d75ea8fb. gcc/analyzer/ChangeLog: * access-diagram.cc (remove_ssa_names): Support operands being NULL_TREE, such

Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64

On 3/17/24 17:38, Mike Stump wrote: On Feb 15, 2024, at 6:08 AM, Jonathan Yong wrote: Attached patch OK? Ok. Copy/pasted for review convenience. diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c b/gcc/testsuite/c-c++-common/Wrestrict.c index 4d005a618b3..57a3f67e21e 100644 ---

Re: [gcc-15 1/3] RISC-V: avoid LUI based const materialization ... [part of PR/106265]

On 3/16/24 13:28, Jeff Law wrote: >> Implementation Details (for posterity) >> -- >> - basic idea is to have a splitter selected via a new predicate for >> constant >> being possible sum of two S12 and provide the transform. >> This is however a 2

Re: [PATCH] c++: explicit inst of template method not generated [PR110323]

On 3/15/24 13:48, Marek Polacek wrote: On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote: On 3/8/24 12:02, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Consider constexpr int VAL = 1; struct foo { template

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

On 3/18/24 12:54 PM, Edwin Lu 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 causes

Re: [PATCH] alpha: Fix alpha_setup_incoming_varargs [PR114175]

On 3/18/24 12:40 PM, Jakub Jelinek wrote: Hi! Like in the r14-9503 change on x86-64, I think Alpha also needs to function_arg_advance after the hidden return pointer argument if any. At least, the following patch changes the assembly of s1-s6 functions on the

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

On Mon, Mar 18, 2024 at 3:10 PM Evgeny Karpov wrote: > > > Monday, March 18, 2024 2:34 PM > Christophe Lyon wrote: > > > I had a look at the v2 series, and besides a minor comment patch #8, ISTM > > than > > all the comments your received about v1 have been addressed, indeed. > > > > > While

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

On Mon, Mar 18, 2024 at 3:59 PM Fangrui Song wrote: > > On Mon, Mar 18, 2024 at 3:10 PM Evgeny Karpov > wrote: > > > > > > Monday, March 18, 2024 2:34 PM > > Christophe Lyon wrote: > > > > > I had a look at the v2 series, and besides a minor comment patch #8, ISTM > > > than > > > all the

[PATCH v5] LoongArch: Add support for TLS descriptors

Add support for TLS descriptors on normal code model and extreme code model. Normal code model instruction sequence: -mno-explicit-relocs: la.tls.desc $r4, s add.d $r12, $r4, $r2 -mexplicit-relocs: pcalau12i $r4,%desc_pc_hi20(s) addi.d $r4,$r4,%desc_pc_lo12(s)

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/16/24 13:21, Jeff Law wrote: > | 59944:add s0,sp,2047 < > | 59948:mv a2,a0 > | 5994c:mv a3,a1 > | 59950:mv a0,sp > | 59954:li a4,1 > | 59958:lui a1,0x1 > | 5995c:add s0,s0,1 <--- > | 59960:jal

Re: [PATCH v3] c++: Fix handling of no-linkage decls for modules

On 3/16/24 07:23, Nathaniel Shead wrote: On Mon, Mar 11, 2024 at 02:13:34PM -0400, Jason Merrill wrote: On 3/8/24 18:18, Nathaniel Shead wrote: On Fri, Mar 08, 2024 at 10:19:52AM -0500, Jason Merrill wrote: On 3/7/24 21:55, Nathaniel Shead wrote: On Mon, Nov 27, 2023 at 03:59:39PM +1100,

Re: [PATCH] Document -fexcess-precision=16.

On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers wrote: > > On Mon, 18 Mar 2024, liuhongt wrote: > > > +If @option{-fexcess-precision=16} is specified, casts and assignments of > > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their > > +semantic types if they're supported by

Re: [PATCH] RISC-V: Add XiangShan Nanhu microarchitecture.

On 2/27/24 1:52 AM, Jiawei wrote: From: Chen Jiawei Co-Authored by: Lin Jiawei This patch add XiangShan Nanhu cpu microarchitecture, Nanhu is a 6-issue, superscalar, out-of-order processor. More details see: https://xiangshan-doc.readthedocs.io/zh-cn/latest/arch gcc/ChangeLog:

[PING^0][PATCH V3 0/2] aarch64: Place target independent and dependent changed and unchanged code in one file.

Hello Richard/Alex: Ping! Please reply. Thanks & Regards Ajit On 27/02/24 12:33 pm, Ajit Agarwal wrote: > Hello Richard/Alex: > > This patch has better diff with changed and unchanged code. > Unchanged code and some of the changed code will be extracted > into target independent headers and

[PATCH] i386: Unify {general, timode}_scalar_chain::convert_op [PR111822]

Recent PR111822 fix implemented REG_EH_REGION note copying to a STV converted preload instruction in general_scalar_chain::convert_op. However, the same issue remains in timode_scalar_chain::convert_op. Instead of copying the newly introduced code to timode_scalar_chain::convert_op, the patch

Re: [PATCH] arm: [MVE intrinsics] Fix support for loads [PR target/114323]

On 15/03/2024 20:08, Christophe Lyon wrote: The testcase in this PR shows that we would load from an uninitialized location, because the vld1 instrinsics are reported as "const". This is because function_instance::reads_global_state_p() does not take CP_READ_MEMORY into account. Fixing this

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

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 causes gcc.dg/c23-stdarg-[68].c to fail Fix the issue by checking if

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

Monday, March 18, 2024 2:34 PM Christophe Lyon wrote: > I had a look at the v2 series, and besides a minor comment patch #8, ISTM than > all the comments your received about v1 have been addressed, indeed. > > > While unit testing for the x86_64-w64-mingw32 target is still in > > progress, the

Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]

Le 17/03/2024 à 23:10, Harald Anlauf a écrit : Hi Mikael, On 3/17/24 22:04, Mikael Morin wrote: diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 3673fa40720..a7717a8107e 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -7526,6 +7526,17 @@

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

Both committed now. Just to confirm, those 2 last patches should be backported to gcc-13 branch, right ? I might have a try to update version.h but if you want to do it before don't hesitate. François On 18/03/2024 08:45, Jonathan Wakely wrote: On Sun, 17 Mar 2024 at 18:14, François

Re: [PATCH] cpp: new built-in __EXP_COUNTER__

On Mon, 18 Mar 2024 at 16:46, Kaz Kylheku wrote: > > On 2024-03-18 00:30, Jonathan Wakely wrote: > >>+@item __EXP_COUNTER__ > >>+This macro's name means "(macro) expansion counter". > >>+Outside of macro replacement sequences, it expands to the integer > >>+token @code{1}. This make it possible

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

Hello, everyone. Currently, we are able to provide results of regression testing for `x86_64-w64-mingw32` target with `--enable-languages=c,lto,c++,fortran` running in WSL only. The summarized results, both for the branch with patch set applied and its corresponding base branch, show: 517501

[PATCH] alpha: Fix alpha_setup_incoming_varargs [PR114175]

Hi! Like in the r14-9503 change on x86-64, I think Alpha also needs to function_arg_advance after the hidden return pointer argument if any. At least, the following patch changes the assembly of s1-s6 functions on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html c23-stdarg-9.c

[PATCH, committed] Fortran: error recovery in frontend optimization [PR103715]

Dear all, I've committed the attached simple & obvious patch for an ICE due to an invalid read in frontend optimization after regtesting and an OK by Jerry in the PR. Pushed: https://gcc.gnu.org/g:3be2b8f475f22c531d6cef1b041c0573b3ea5133 As this PR is marked as a regression, I plan to backport

Re: [PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P

On 1/22/24 6:30 AM, Mary Bennett wrote: On 09/01/2024 18:43, Jeff Law wrote: On 1/8/24 06:14, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/ corev-builtin-spec.md Contributors:    Mary Bennett    Nandni Jamnadas    Pietra Ferreira    Charlie

Re: [PATCH v3] testsuite: Add a test case for negating FP vectors containing zeros

On 3/5/24 4:40 AM, Xi Ruoyao wrote: Recently I've fixed two wrong FP vector negate implementation which caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To prevent a similar issue from happening again, add a test case. Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F),

Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence

On 2/6/24 6:14 AM, Robin Dapp wrote: The root cause is this following RTL pattern, after fwprop1: (insn 82 78 84 9 (set (reg:DI 230)         (sign_extend:DI (minus:SI (subreg/s/v:SI (reg:DI 150 [ niters.10 ]) 0)                 (subreg:SI (reg:DI 221) 0 13 {subsi3_extended}      

Re: [PATCH, RFC] combine: Don't truncate const operand of AND if it's no benefits

On 3/10/24 11:41 PM, HAO CHEN GUI wrote: Hi, This patch tries to fix the problem when a canonical form doesn't benefit on a specific target. The const operand of AND is and with the nonzero bits of another operand in combine pass. It's a canonical form, but it's no benefits for the target

Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak

On 3/16/24 11:35 AM, Vineet Gupta wrote: Hi, This set of patches (for gcc-15) help improve stack/array accesses by improving constant materialization. Details are in respective patches. The first patch is the main change which improves SPEC cactu by 10%. Just to confirm. Yup, 10% reduction

Re: [PATCH V2] RISC-V: Update test expectancies with recent scheduler change

On 3/12/24 3:56 PM, Edwin Lu wrote: Given the recent change with adding the scheduler pipeline descriptions, many scan-dump failures emerged. Relax the expected assembler output conditions on the affected tests to reduce noise. gcc/testsuite/ChangeLog: *

Re: [PATCH] LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]

在 2024/3/18 下午5:34, Xi Ruoyao 写道: We were assuming 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 is causing

Re: RISC-V: Use convert instructions instead of calling library functions

On 3/18/24 3:09 AM, Jivan Hakobyan wrote: As RV has round instructions it is reasonable to use them instead of calling the library functions. With my patch for the following C code: double foo(double a) {     return ceil(a); } GCC generates the following ASM code (before it was tail call)