Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote: > > So, this patch is an alternative to the > > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html > > patch, which had the major problem that it required changing all the > > DWARF consumers to be able to debug C17 or

Re: [PATCH] match.pd: Fold pattern of round semantics.

在 2025/1/7 下午10:45, Richard Biener 写道: On Thu, 2 Jan 2025, 赵洲 wrote: Add Reviewer Richard Biener. -原始邮件- 发件人: "Zhou Zhao" 发送时间:2025-01-02 19:37:07 (星期四) 收件人: gcc-patches@gcc.gnu.org 抄送: xry...@xry111.site, i...@xen0n.name, chengl...@loongson.cn, xucheng...@loongson.cn, zhaoz...@l

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

> So, this patch is an alternative to the > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html > patch, which had the major problem that it required changing all the > DWARF consumers to be able to debug C17 or later or C++17 or later > sources. Do you plan to salvage the non-obso

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

May be add a feature request PR for this for Ada and Fortran to prevent us from forgetting to evaluate the necessity or ability to provide that flag/information? Sorry for me using a wrong term or expression above. I have not yet any knowledge or gotten in touch with DWARF stuff. - Andre On Wed,

[PATCH] match.pd: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization [PR117927]

Hi! As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar match.pd optimization which has been introduced in GCC 15 can introduce UB which wasn't there before, in particular if b is equal at runtime to bitsize, then a r<< 0 is turned into a r>> bitsize. The following patch fixes it

[PATCH] rs6000: Adding missed ISA 3.0 atomic memory operation instructions.

Hi All, The following patch has been bootstrapped and regtested on powerpc64le-linux. Changes to amo.h include the addition of the following load atomic operations: Compare and Swap Not Equal, Fetch and Increment Bounded, Fetch and Increment Equal, and Fetch and Decrement Bounded. Additionally, S

Re: [PATCH] riscv: add mising masking in lrsc expander (PR118137)

Please fix your git to strip the subject prefix. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

[PATCH V4 1/2] RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.

From: yulong This commit adds intrinsics support for Xsfvcp extension. Diff with V3: Add new RTL mode and sifive_vector.h file. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan Chen gcc/ChangeLog: * config.gcc: Add sifive_vector.h. * config/ris

[PATCH V4 0/2] RISC-V: Add intrinsics support and testcases for SiFive Xsfvcp extension.

From: yulong This patch implements the Sifvie vendor extension Xsfvcp[1] support to gcc. Providing a flexible mechanism to extend application processors with custom coprocessors and variable-latency arithmetic units intrinsics. [1] https://www.sifive.com/document-file/sifive-vector-coproces

[PATCH V4 2/2] RISC-V: Add intrinsics testcases for SiFive Xsfvcp extensions.

From: yulong This commit adds testcases for Xsfvcp. Diff with V3: Change h file from riscv_vector.h to sifive_vector.h. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan Chen gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xsfvector/sf_vc_f.c: New test.

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi Paul-Antoine! On 2024-12-16T19:35:01+0100, Paul-Antoine Arras wrote: > On 15/11/2024 14:59, Tobias Burnus wrote: >> Paul-Antoine Arras wrote: >>> This patch adds support for the `dispatch` construct and the >>> `adjust_args` clause to the Fortran front-end. >>> >>> Handling of `adjust_args` ac

Re: [PATCH] match.pd: Fold pattern of round semantics.

On Wed, 8 Jan 2025, Zhou Zhao wrote: > > 在 2025/1/7 下午10:45, Richard Biener 写道: > > On Thu, 2 Jan 2025, 赵洲 wrote: > > > >> Add Reviewer Richard Biener. > >> > >> > >>> -原始邮件- > >>> 发件人: "Zhou Zhao" > >>> 发送时间:2025-01-02 19:37:07 (星期四) > >>> 收件人: gcc-patches@gcc.gnu.org > >>> 抄送: xry...@x

Re: [PATCH] match.pd: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization [PR117927]

On Wed, 8 Jan 2025, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar > match.pd optimization which has been introduced in GCC 15 can introduce > UB which wasn't there before, in particular if b is equal at runtime > to bitsize, then a r<< 0 is tu

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

On Wed, 8 Jan 2025, Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote: > > > So, this patch is an alternative to the > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html > > > patch, which had the major problem that it required changing all t

[PATCH] RISC-V: Refine registered_functions list for rvv overloaded intrinsics.

From: xuli Before this patch, each rvv overloaded intrinsic was registered twice, both in gcc and g++. Take vint8mf8_t __riscv_vle8(vbool64_t vm, const int8_t *rs1, size_t vl) as an example. For gcc, one decl is void __riscv_vle8(void), and the other is integer_zero_node, which is redundant. Fo

[PATCH] fortran: Bump MOD_VERSION to "16" [PR118337]

Hi! As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic modules, because new entries have been added to those modules in the middle, causing changes in the constants emitted in the *.mod files. Also, I

Re: [PATCH 2/4] cfgloopmanip: Add infrastructure for scaling of multi-exit loops [PR117790]

On 6 January 2025 12:34:45 CET, Alex Coplan wrote: nit: s/caling/calling/ thanks

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

Hi Jakub, marking the vtypes as recursive is odd, but should not be taken as any incompatibility marker. Pre version 15 gfortran does not check the recursive attr on types. So whether it is set or not, is of no concern to gfortran <= 14. The pr that motivated the change is: https://gcc.gnu.org/bug

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote: > marking the vtypes as recursive is odd, but should not be taken as any > incompatibility marker. Pre version 15 gfortran does not check the recursive > attr on types. So whether it is set or not, is of no concern to gfortran <= >

[PATCH] match.pd, v2: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization [PR117927]

On Wed, Jan 08, 2025 at 10:17:59AM +0100, Richard Biener wrote: > > As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar > > match.pd optimization which has been introduced in GCC 15 can introduce > > UB which wasn't there before, in particular if b is equal at runtime > > to bitsiz

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

Hello, Le 08/01/2025 à 11:34, Andre Vehreschild a écrit : The flag is used now to indicate, that a type can (indirectly) reference itself. Not having the marker lead to endless recursion during construction of copy or deallocate operations on an object of the type. Can it be removed from the

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

Ok, I was merely asking, if I need to stop my current fault finding immediately and fix it within the next hours, or if a fix is ok by say beginning of next at latest. I will finish my current fault finding and then extend your patch. - Andre On Wed, 8 Jan 2025 12:04:15 +0100 Jakub Jelinek wrot

Re: [PATCH] libstdc++: add a constexpr macro for C++26

On Wed, Jan 08, 2025 at 11:57:32AM +0100, Giuseppe D'Angelo wrote: > On 08/01/2025 11:49, Jakub Jelinek wrote: > > > +#ifndef _GLIBCXX26_CONSTEXPR > > > +# if __cplusplus >= 202303L > > Shouldn't that be 202400L instead? I mean that is what > > -std=c++26/-std=gnu++26 predefines and has been histo

Re: [PATCH v3] AArch64: Add LUTI ACLE for SVE2

writes: > This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. > > LUTI instructions are used for efficient table lookups with 2-bit > or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from > the low 128 bits of the table vector using packed 2-bit indices, > while LUTI4 can re

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

That sounds like a feasible solution when finding the erroneous (to my belief) setting of flag takes longer than expect. Mikael, do you know your way around the module export stuff and can you point me directly to the line in question? I haven't worked in that area. Just asking. If you don't know

Re: [PATCH] match.pd, v2: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization [PR117927]

On Wed, 8 Jan 2025, Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 10:17:59AM +0100, Richard Biener wrote: > > > As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar > > > match.pd optimization which has been introduced in GCC 15 can introduce > > > UB which wasn't there before, in

Re: [PATCH] libstdc++: add a constexpr macro for C++26

On Wed, 8 Jan 2025 at 11:00, Jakub Jelinek wrote: > > On Wed, Jan 08, 2025 at 11:57:32AM +0100, Giuseppe D'Angelo wrote: > > On 08/01/2025 11:49, Jakub Jelinek wrote: > > > > +#ifndef _GLIBCXX26_CONSTEXPR > > > > +# if __cplusplus >= 202303L > > > Shouldn't that be 202400L instead? I mean that is

Re: [PATCH] RISC-V: Refine registered_functions list for rvv overloaded intrinsics.

Thanks for optimizing it. Did you do the RVV intrinsic CI test ? riscv-non-isa/rvv-intrinsic-doc LGTM if you finished the full coverage testing of rvv intrinsic. juzhe.zh...@rivai.ai From: Li Xu Date: 2025-01-08 17:36 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; pan2.li; xuli Subject:

Re: [PATCH v3] AArch64: Add LUTI ACLE for SVE2

On Wed, Jan 08, 2025 at 11:13:41AM +, Richard Sandiford wrote: > writes: > > This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. > > > > LUTI instructions are used for efficient table lookups with 2-bit > > or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from > > the lo

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

On Wed, Jan 08, 2025 at 02:35:56PM +0100, Mark Wielaard wrote: > > --- gcc/dwarf2out.cc.jj 2025-01-02 11:23:35.541251268 +0100 > > +++ gcc/dwarf2out.cc2025-01-07 10:09:16.866866563 +0100 > > @@ -8755,6 +8755,14 @@ break_out_comdat_types (dw_die_ref die) > > unit = new_die (DW_T

[PING] [PATCH 1/6] Add tunables for input buffer

I wanted to ping this patch series. Thanks. -Andi

Re: [PATCH 2/2] c++: constexpr potentiality of CAST_EXPR [PR117925]

On Thu, Dec 12, 2024 at 3:29 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk/14? Ping. > > This fixes the testcase in the PR but doesn't thoroughly fix the > underlying issue since if we replace fnPtr with e.g. a constexpr variable > s

Re: [PATCH 1/2] c++: relax ICE for unexpected trees during constexpr [PR117925]

On Thu, Dec 12, 2024 at 3:29 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk and perhpas 14? Ping. > > -- >8 -- > > When we encounter an unexpected (likely templated) tree code during > constexpr evaluation we currently ICE even in rel

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

One of the issues are lines: module.cc 7125-7130: Here it is assumed that the signed and unsigned types are adjacent maybe?! I have changed this: diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc index c4312b641c1..05bc802957e 100644 --- a/gcc/fortran/module.cc +++ b/gcc/fortran/module.

RE: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok

> -Original Message- > From: Richard Earnshaw (lists) > Sent: Wednesday, January 8, 2025 1:18 PM > To: Christophe Lyon ; gcc-patches@gcc.gnu.org; > Richard Sandiford ; Tamar Christina > ; Andre Simoes Dias Vieira > ; ktkac...@nvidia.com; > raman...@nvidia.com > Subject: Re: [PATCH 3/4] arm

Re: [PATCH] c/c++: UX improvements to 'too {few, many} arguments' errors [PR118112]

On Tue, Jan 07, 2025 at 06:52:29PM -0500, David Malcolm wrote: > On Tue, 2025-01-07 at 15:08 -0500, Marek Polacek wrote: > > > @@ -4548,22 +4553,28 @@ error_args_num (location_t loc, tree > > > fndecl, bool too_many_p) > > >     == DECL_NAME (TYPE_NAME (DECL_CONTEXT > > > (fndecl) > > >

[PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

The previous fix only worked for C, for C++ we need to add more information to the underlying type so that finish_class_member_access_expr accepts it. This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++ mode. gcc/ChangeLog: PR target/118332 * config/arm/arm-mve-

[PING] [PATCH] c++: Suppress note linked to error suppressed by -Wno-template-body [PR118163]

Hi, On 21 Dec 2024, at 17:35, Simon Martin wrote: > When erroring out due to an incomplete type, we add a contextual note > about the type. However, when the error is suppressed by > -Wno-template-body, the note remains, making the compiler output quite > puzzling. > > This patch makes sure the n

[PATCH] ree: Skip extension on stack pointer

Skip extension on stack pointer since we can't turn (insn 27 26 139 2 (parallel [ (set (reg/f:SI 7 sp) (plus:SI (reg/f:SI 7 sp) (const_int 16 [0x10]))) (clobber (reg:CC 17 flags)) ]) "x.ii":14:17 discrim 1 283 {*addsi_1} (exp

Re: [PATCH] match.pd: Fold pattern of round semantics.

On Thu, 9 Jan 2025, Zhou Zhao wrote: > > 在 2025/1/8 下午6:30, Richard Biener 写道: > > On Wed, 8 Jan 2025, Zhou Zhao wrote: > > > >> 在 2025/1/8 下午5:04, Richard Biener 写道: > >>> On Wed, 8 Jan 2025, Zhou Zhao wrote: > >>> > 在 2025/1/7 下午10:45, Richard Biener 写道: > > On Thu, 2 Jan 2025, 赵洲 wrot

[PATCH] libgomp: avoid unused-variable-error when configured with CFLAGS=-DNDEBUG

>From 929fb2091ffe50a35a1b2dae1f1ce20357bc435b Mon Sep 17 00:00:00 2001 From: shynur Date: Thu, 9 Jan 2025 14:11:38 +0800 Subject: [PATCH] Avoid unused-variable-error when configured with 'CFLAGS=-DNDEBUG' --- libgomp/target.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --g

Re: [PATCH] c++: template-id dependence wrt local static arg [PR117792]

On 11/27/24 12:29 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14/13? OK. -- >8 -- Here we end up ICEing at instantiation time for the call to f ultimately because we wrongly consider the call to be non-dependent, and so we specializ

Re: [PATCH] Prefer scalar_int_mode if the size - 1 is equal to UNITS_PER_WORD.

Thank you all. Jim Jeff Law 於 2025年1月8日 週三 上午5:51寫道： > > > > On 1/2/25 12:13 AM, Tsung Chun Lin wrote: > > Don't use the QI vector if its size is equal to UNITS_PER_WORD for > > better code generation. > > > > Before patch: > > > > vsetivlizero,4,e8,mf4,ta,ma > > vmv.v.i v1,0 > > addi

Re: [PATCH] c++: template-id dependence wrt local static arg [PR117792]

On Wed, Dec 11, 2024 at 10:19 AM Patrick Palka wrote: > > On Wed, 27 Nov 2024, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > for trunk/14/13? > > Ping. Ping. > > It occurred to me that another way to fix this PR might be to tweak the > overlo

Re: [PATCH] c++: current inst w/ indirect dependent bases [PR117993]

On Wed, 8 Jan 2025, Patrick Palka wrote: > On Thu, Dec 12, 2024 at 2:34 PM Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk? The older regression does not seem worth fixing. Oops, does not seem worth fixing _on release branches_ rat

Re: [PATCH] c++: convert_to_void during requires-expr partial subst [PR118060]

On Tue, Dec 17, 2024 at 11:04 AM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > for trunk/14/13? Ping. > > -- >8 -- > > Here during partial substitution of the requires-expression (as part of > CTAD constraint rewriting) we segfault from the INDIR

Re: [PATCH] gcc/configure: Fix check for assembler section merging support on Arm

On 27/12/2024 21:47, Thiago Jung Bauermann wrote: > In 32-bit Arm assembly, the @ character is the start of a comment so > the section type needs to use the % character instead. > > configure.ac attempts to account for this difference by doing a second > try when checking the assembler for section

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

Hi all, I like to take Jakub's patch a little bit further and add two things, that annoy me: First of all the recursive attr must not be set on vtypes, neither on module ones nor anywhere else. Strictly speaking is a vtype recursive, because by its extends member it references itself through a po

[PATCH] fortran, v2: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote: > I'm testing for that instead: > --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100 > +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100 > @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (void) > >i = 0; > #defin

Re: [PATCH] fortran: Bump MOD_VERSION to "16" [PR118337]

On Wed, Jan 08, 2025 at 10:33:53AM +0100, Jakub Jelinek wrote: > > As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and > GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic > modules, because new entries have been added to those modules in the middle, > c

Re: [PATCH v2] AArch64: Block combine_and_move from creating FP literal loads

Wilco Dijkstra writes: > Hi Richard, > >> ...I still think we should avoid testing can_create_pseudo_p. >> Does it work with the last part replaced by: >> >>  if (!DECIMAL_FLOAT_MODE_P (mode)) >>    { >>  if (aarch64_can_const_movi_rtx_p (src, mode) >>  || aarch64_float_const_represent

Re: [PATCH] libstdc++: Handle errors from strxfrm in std::collate::transform [PR85824]

On Wed, 18 Dec 2024 at 21:19, Jonathan Wakely wrote: > > std::regex builds a cache of equivalence classes by calling > std::regex_traits::transform_primary(c) for every char, which then > calls std::collate::transform which calls strxfrm. On several > targets strxfrm fails for non-ASCII characters

Re: [PATCH] libstdc++: Fix future.wait_until when given a negative time_point

On Wed, 18 Dec 2024 at 00:35, Jonathan Wakely wrote: > > On Tue, 17 Dec 2024 at 19:38, Jonathan Wakely wrote: > > > > On Wed, 31 Jul 2024 at 22:39, Jonathan Wakely wrote: > > > > > > On Wed, 24 Jul 2024 at 14:14, William Tsai > > > wrote: > > > > > > > > The template `future.wait_until` will e

Re: [PATCH] libstdc++: Fix std::deque::emplace calling wrong _M_insert_aux [PR90389]

On Wed, 18 Dec 2024 at 00:40, Jonathan Wakely wrote: > > We have several overloads of std::deque::_M_insert_aux, one of which is > variadic and called by std::deque::emplace. With a suitable set of > arguments to emplace, it's possible for one of the non-variadic > _M_insert_aux overloads to be se

Re: [PATCH v3 0/4] Hard Register Constraints

Hi Vladimir, Would you be willing to have a look at the LRA part? This basically only involves patch number 1, i.e., https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666455.html Would be great to get some feedback whether the current approach is feasible or whether I should drop this patch.

[committed] libstdc++: Use preprocessor conditions in std module [PR118177]

The std-clib.cc module definition file assumes that all names are available unconditionally, but that's not true for all targets. Use the same preprocessor conditions as are present in the headers. A similar change is needed in std.cc.in for the features that depend on the SSO std::string, guard

[committed] libstdc++: Make GDB skip over some library functions [PR118260]

libstdc++-v3/ChangeLog: PR libstdc++/118260 * python/hook.in: Run 'skip' commands for some simple accessor functions. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/python/hook.in | 5 + 1 file changed, 5 insertions(+) diff --git a/libstdc++-v3/python/hook.i

Re: [PATCH] libstdc++: Avoid redundant assertions in std::span constructors

On Thu, 12 Dec 2024 at 00:05, Jonathan Wakely wrote: > > Any std::span constructor with a runtime length has a precondition > that the length is equal to N (except when N == std::dynamic_extent). > > Currently every constructor with a runtime length does: > > if constexpr (extent != dynamic_extent

[committed] libstdc++: Adjust indentation of new std::span constructor

libstdc++-v3/ChangeLog: * include/std/span: Fix indentation. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/include/std/span | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/libstdc++-v3/include/std/span b/libstdc++-v3/include/std/span index 4b40

Re: [PATCH 2/4] arm, testsuite: fix fast-math-bb-slp-complex-mla-float.c dg-add-options

On 19/12/2024 12:17, Christophe Lyon wrote: > The test uses floats, not fp16 so it should use arm_v8_3a_complex_neon > instead of arm_v8_3a_fp16_complex_neon. > > This makes it PASS on arm-linux-gnueabihf instead of being UNRESOLVED. > > gcc/testsuite/ChangeLog: > * gcc.dg/vect/comple

Re: [PATCH 1/4] arm, testsuite: remove duplicate dg-add-options arm_v8_3a_complex_neon

On 19/12/2024 12:17, Christophe Lyon wrote: > These two testcases have twice the same dg-add-options > arm_v8_3a_complex_neon, the patch removes one of them. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/complex/complex-operations-run.c: Remove duplicate > dg-add-options arm_v8_3a_co

Re: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok

On 19/12/2024 12:17, Christophe Lyon wrote: > Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail > to compile on arm-linux-gnueabihf with > fatal error: gnu/stubs-soft.h: No such file or directory > because they are actually compiled with > -mfloat-abi=softfp -mfpu=auto -mcpu=unse

[committed] libstdc++: Add always_inline to casting/forwarding functions in bits/move.h

libstdc++-v3/ChangeLog: * include/bits/move.h (__addressof, forward, forward_like, move) (move_if_noexcept, addressof): Add always_inline attribute. Replace _GLIBCXX_NODISCARD with [[__nodiscard__]]. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/include/bits/mov

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote: > Le 08/01/2025 à 11:42, Jakub Jelinek a écrit : > > > > The full list of changes with the posted patches is > > (first a.mod, then b.mod, 14 -> 15) below. > > I have no idea what adds those __copy_* elts etc. and whether they could be

Re: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok

On 08/01/2025 13:56, Tamar Christina wrote: >> -Original Message- >> From: Richard Earnshaw (lists) >> Sent: Wednesday, January 8, 2025 1:18 PM >> To: Christophe Lyon ; gcc-patches@gcc.gnu.org; >> Richard Sandiford ; Tamar Christina >> ; Andre Simoes Dias Vieira >> ; ktkac...@nvidia.com; >

Re: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok

On Wed, 8 Jan 2025 at 14:17, Richard Earnshaw (lists) wrote: > > On 19/12/2024 12:17, Christophe Lyon wrote: > > Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail > > to compile on arm-linux-gnueabihf with > > fatal error: gnu/stubs-soft.h: No such file or directory > > because

[PATCH] c++, v2: Fix up ICEs on constexpr inline asm strings in templates [PR118277]

On Tue, Jan 07, 2025 at 03:20:35PM -0800, Andi Kleen wrote: > > There is one case I didn't handle and I'd like to discuss. > > The initial commit to enable this new extension also changed > > cp_parser_asm_specification_opt to use cp_parser_asm_string_expression. > > That function doesn't have anyt

Re: [PATCH] docs: Document new hardreg PRE pass.

On 1/8/25 2:34 AM, Richard Sandiford wrote: Jeff Law writes: On 1/7/25 11:17 AM, Richard Sandiford wrote: Andrew Carlotti writes: I forgot to include this in the earlier patch; is this ok for master (once the pass is merged, of course)? gcc/ChangeLog: * doc/passes.texi: Document

nvptx: Support '-march=sm_37': update '-march-map=sm_50' documentation (was: [PUSHED] nvptx: Support '-march=sm_37')

Hi! On 2024-12-06T12:29:12+0100, I wrote: > --- a/gcc/config/nvptx/nvptx.opt > +++ b/gcc/config/nvptx/nvptx.opt > march-map=sm_50 > -Target RejectNegative Alias(misa=,sm_35) > +Target RejectNegative Alias(misa=,sm_37) Pushed to trunk branch commit 59a4089ccab5a8ae3ddfa7b1b762caf2125a49a7 "nvptx

Re: [PATCH] Disable a broken multiversioning optimisation

Andrew Carlotti writes: > This patch skips redirect_to_specific clone for aarch64 and riscv, > because the optimisation has two flaws: > > 1. It checks the value of the "target" attribute, even on targets that > don't use this attribute for multiversioning. > > 2. The algorithm used is too aggress

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote: > I think your patch is enough, we don't need to target same-bytes formats > between module versions. I can confirm the ICE on the small reproducer I've posted is gone with the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729

Re: [PATCH] Disable a broken multiversioning optimisation

On 1/8/25 19:48, Andrew Carlotti wrote: This patch skips redirect_to_specific clone for aarch64 and riscv, because the optimisation has two flaws: 1. It checks the value of the "target" attribute, even on targets that don't use this attribute for multiversioning. 2. The algorithm used is too

Re: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok

On 08/01/2025 13:37, Christophe Lyon wrote: > On Wed, 8 Jan 2025 at 14:17, Richard Earnshaw (lists) > wrote: >> >> On 19/12/2024 12:17, Christophe Lyon wrote: >>> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail >>> to compile on arm-linux-gnueabihf with >>> fatal error: gnu/st

nvptx: Re-enable "Stack alignment causes use of alloca" test cases

Hi! On 2022-12-02T13:03:14+0100, I wrote: > Generally PASS with: > > $ ptxas --version > ptxas: NVIDIA (R) Ptx optimizing assembler > Copyright (c) 2005-2018 NVIDIA Corporation > Built on Sun_Sep__9_21:06:46_CDT_2018 > Cuda compilation tools, release 10.0, V10.0.145 > > ..., an

Re: Mark const parameters passed by invisible reference as readonly in the function body

> On Wed, 8 Jan 2025, Jan Hubicka wrote: > > > > On Tue, 10 Dec 2024, Jan Hubicka wrote: > > > > > > > Hi, > > > > int: > > > > struct foo > > > > { > > > > int a; > > > > void bar() const; > > > > ~foo() > > > > { > > > > if (a != 42) > > > > __builtin_abort (); > > > > } > >

Re: [PATCH] LoongArch: Adjust the cost of ADDRESS_REG_REG [PR114978].

On Tue, 2025-01-07 at 10:44 +0800, Lulu Cheng wrote: > After changing this cost from 1 to 3, the performance of spec2006 > 401 473 416 465 482 can be improved by about 2% on LA664. Would this fix https://gcc.gnu.org/PR114978 (or at least make it latent)? > > Add option '-maddr-reg-reg-cost='. >

Re: [PATCH] c++: tf_partial and instantiate_template [PR117887]

On Thu, Dec 12, 2024 at 4:08 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk only? The original testcase from the PR seems to compile > successfully on the release branches so I'm avoiding doing anything on > the release branches for no

Re: [PATCH] c++: current inst w/ indirect dependent bases [PR117993]

On Thu, Dec 12, 2024 at 2:34 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? The older regression does not seem worth fixing. Ping. > > -- >8 -- > > In the first testcase we're overeagerly diagnosing qualified name lookup > failure f

Re: [PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

On Mon, Dec 9, 2024 at 11:15 PM Lewis Hyatt wrote: > > On Mon, Dec 09, 2024 at 02:07:07PM +0100, Richard Biener wrote: > > On Tue, Dec 3, 2024 at 2:42 PM Richard Biener > > wrote: > > > > > > On Tue, Dec 3, 2024 at 2:07 PM Lewis Hyatt wrote: > > > > > > > > On Tue, Dec 03, 2024 at 01:28:28PM +01

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

Hi, I have added this small patch (attached). Unfortunately I got regressions some in iso_fortran_env_8.f90 and several in unsigned_NN.f90 tests. Just retesting w/o my patch and already seeing the iso_fortran_env one again. I am also not totally sure, that I applied both your patches correctly.

Re: [PATCH] c++: Honor complain in cp_build_function_call_vec for check_function_arguments warnings [PR117825]

On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs due to re-entering diagnostics. > When diagnosing -Wformat-security warning, we try to print instantiation > context, which calls tsubst with tf_none, but that in the end calls > cp_build_function_

Re: [PATCH] c++: Honor complain in cp_build_function_call_vec for check_function_arguments warnings [PR117825]

On Wed, Jan 08, 2025 at 01:33:15PM -0500, Marek Polacek wrote: > On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote: > > Hi! > > > > The following testcase ICEs due to re-entering diagnostics. > > When diagnosing -Wformat-security warning, we try to print instantiation > > context, whic

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

Hi Jakub, On Tue, 2025-01-07 at 20:22 +0100, Jakub Jelinek wrote: > DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html , > which is basically just a guarantee that the DWARF 6 draft > DW_AT_language_{name,version} attribute codes and content of > https://dwarfstd.org/languages-

Re: [PATCH 4/4] arm, testsuite: add +simd to arm_v8_3a_complex_neon_ok

On 19/12/2024 12:17, Christophe Lyon wrote: > The vect testsuite adds -mfpu=neon before the arm_v8_3a_complex_neon > flags via check_vect_support_and_set_flags, so before this change > testcases are compiled with -mfpu=neon (and no -march/-mfloat-abi > flag) with an arm-linux-gnueabihf toolchain co

Re: Mark const parameters passed by invisible reference as readonly in the function body

> On Tue, 10 Dec 2024, Jan Hubicka wrote: > > > Hi, > > int: > > struct foo > > { > > int a; > > void bar() const; > > ~foo() > > { > > if (a != 42) > > __builtin_abort (); > > } > > }; > > __attribute__ ((noinline)) > > void test(const struct foo a) > > { > > int b = a

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote: > Hi, > > I have added this small patch (attached). Unfortunately I got regressions > > some in iso_fortran_env_8.f90 > and several in unsigned_NN.f90 tests. > > Just retesting w/o my patch and already seeing the iso_fortran_env

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote: > gcc/fortran/ChangeLog: > > PR fortran/118337 > * module.cc (use_iso_fortran_env_module): Prevent additional run > over (un-)signed ints and assign kind directly. > --- > gcc/fortran/module.cc | 13 ++---

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 7, 2025, at 07:29, Richard Biener wrote: > > On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote: >> >> >> >>> On Jan 6, 2025, at 11:01, Richard Biener wrote: >>> >>> On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote: > On Jan 6, 2025, at 09:21, Jeff Law wrote: >>

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

Le 08/01/2025 à 14:13, Jakub Jelinek a écrit : On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote: Le 08/01/2025 à 11:42, Jakub Jelinek a écrit : The full list of changes with the posted patches is (first a.mod, then b.mod, 14 -> 15) below. I have no idea what adds those __copy_* elt

Re: Mark const parameters passed by invisible reference as readonly in the function body

On Wed, 8 Jan 2025, Jan Hubicka wrote: > > On Tue, 10 Dec 2024, Jan Hubicka wrote: > > > > > Hi, > > > int: > > > struct foo > > > { > > > int a; > > > void bar() const; > > > ~foo() > > > { > > > if (a != 42) > > > __builtin_abort (); > > > } > > > }; > > > __attribute__ ((no

Re: [Bug tree-optimization/109429] [PATCH v2] ivopts: fixed complexities

On Wed, Dec 18, 2024 at 2:55 PM Aleksandar Rakic wrote: > > Hi, > > > > > > > Hi, > > > > > > I think I managed to fix indentation from the previous version. > > > > > > When comparing the tables showing the candidates for the group 1 > > > before and after applying this patch, it can be observed

[PATCH v3 1/2] aarch64: Use standard names for saturating arithmetic

Hi Kyrill, Thanks for the feedback on V2. I found a pattern which works for the open-coded signed arithmetic, and I've implemented the other feedback you provided as well. I've send the modified patch in this thread as the SVE patch [2/2] hasn't been changed, but I'm happy to send the entire V3 p

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote: > One of the issues are lines: > > module.cc 7125-7130: Here it is assumed that the signed and unsigned types are > adjacent maybe?! > > I have changed this: > > diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc > index

Re: [PATCH] c++: Honor complain in cp_build_function_call_vec for check_function_arguments warnings [PR117825]

On Wed, Jan 08, 2025 at 07:40:32PM +0100, Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 01:33:15PM -0500, Marek Polacek wrote: > > On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote: > > > Hi! > > > > > > The following testcase ICEs due to re-entering diagnostics. > > > When diagnosing

Re: [PATCH] match.pd, v2: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization [PR117927]

On Wed, Jan 8, 2025 at 3:08 AM Jakub Jelinek wrote: > > On Wed, Jan 08, 2025 at 10:17:59AM +0100, Richard Biener wrote: > > > As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar > > > match.pd optimization which has been introduced in GCC 15 can introduce > > > UB which wasn't the

[PATCH 1/3] c++: fix conversion issues

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Some issues caught by a check from another patch: In the convert_like_internal bad_p handling, we are iterating from outside to inside, so once we recurse into convert_like we need to stop looping. In build_ramp_function, we're assigning R

[PATCH 2/3] c++: print stub object as std::declval

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- If the result of build_stub_object gets printed by %E it looks something like '(A&&)1', which seems confusing. Let's instead print it as 'std::declval()' since that's how the library writes the same idea. gcc/cp/ChangeLog: * metho

Re: [PATCH] ree: Skip extension on stack pointer

On 1/8/25 1:53 PM, H.J. Lu wrote: Skip extension on stack pointer since we can't turn (insn 27 26 139 2 (parallel [ (set (reg/f:SI 7 sp) (plus:SI (reg/f:SI 7 sp) (const_int 16 [0x10]))) (clobber (reg:CC 17 flags)) ]) "x.

nvptx: Add 'sorry, unimplemented: target cannot support alloca' test cases [PR65181] (was: [nvptx] alloca & stack alignment)

Hi! On 2015-08-21T15:31:06-0400, Nathan Sidwell wrote: > 1) alloca. PTX defines but doesn't implement support. and if one passes > types > suitable for a 64-bit ABI ptxas emits errors. This patch gives a clear error > at > compilation time, rather than an obscure failure later. > --- confi

[PUSHED] nvptx: Add a test case where 'alloca's evaporate [PR65181]

Documenting the status quo. PR target/65181 gcc/testsuite/ * gcc.target/nvptx/alloca-2-O1.c: New. --- gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c d

  1   2   >