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

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

Contents of PO file 'cpplib-14.1-b20240218.sv.po'

cpplib-14.1-b20240218.sv.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

Re: [PATCH] c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange

On Tue, 20 Feb 2024, Jakub Jelinek wrote: > On Tue, Feb 20, 2024 at 12:12:11AM +, Jason Merrill wrote: > > On 2/19/24 02:55, Jakub Jelinek wrote: > > > On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote: > > > > Ah, although __atomic_compare_exchange only takes pointers, the > >

[PATCH] fix link to feature test macros

--- htdocs/gcc-14/porting_to.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 3527469..37b860e 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @@ -133,7 +133,7 @@ On GNU

Re: [PATCH] bpf: add inline memmove and memcpy expansion

Hi David. Thanks for the patch. See a couple of comments regarding error handling below. > BPF programs are not typically linked, which means we cannot fall back > on library calls to implement __builtin_{memmove,memcpy} and should > always expand them inline if possible. > > GCC already

[PATCH] c++: Fix explicit instantiation of const variable templates after earlier implicit instantation [PR113976]

Hi! Already previously instantiated const variable templates had cp_apply_type_quals_to_decl called when they were instantiated, but if they need runtime initialization, their TREE_READONLY flag has been subsequently cleared. Explicit variable template instantiation calls grokdeclarator which

Re: [PATCH] AArch64: Update system register database.

Victor Do Nascimento writes: > [...] > diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h > index 157a0b9dfa5..45e901cda64 100644 > --- a/gcc/config/aarch64/aarch64.h > +++ b/gcc/config/aarch64/aarch64.h > @@ -297,6 +297,26 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = >

[PATCH] libgcc, aarch64: Allow for BE platforms in heap trampolines.

Andrew Pinski pointed out on irc, that the current implementation of the heap trampoline code fragment would make the instruction byte order follow memory byte order for BE AArch64, which is not what is required. This patch revises the initializers so that instruction byte order is independent of

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote: > On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote: > > > So I think that without worrying about performance and ensuring that > > there is no problem > > > > with binutils, I think we can make the following modifications: > > > >    -/*

Re: [PATCH] RISC-V: Set require-effective-target rv64 for PR113742

Hi Edwin, I think just replace to: /* { dg-options "-O2 -finstrument-functions -mabi=lp64d -march=rv64gc -mtune=sifive-p600-series" } */ On Thu, Feb 15, 2024 at 7:43 PM Robin Dapp wrote: > > Ah oops I glanced over the /* { dg-do compile } */part. It should be > > fine to add '-march=rv64gc'

Re: [PATCH]AArch64: remove ls64 from being mandatory on armv8.7-a..

Tamar Christina writes: > Hi, this I a new version of the patch updating some additional tests > because some of the LTO tests required a newer binutils than my distro had. > > --- > > The Arm Architectural Reference Manual (Version J.a, section A2.9 on > FEAT_LS64) > shows that ls64 is an

[PATCH 1/5] btf: fixed type id in BTF_KIND_FUNC struct data.

This patch correct the aditition of +1 on the type id, which originally was done in the wrong location and leaded to func_sts->dtd_type for BTF_KIND_FUNCS struct data to contain the type id of the previous entry. gcc/ChangeLog: * btfout.cc (btf_collect_dataset): Corrected BTF type id. ---

bpf: PR target/113453 func_info .BTF.ext implementation

Good morning, This is a patch series with the implementation of func_info region within bpf target .BTF.ext section. Considering the required changes it also implied some changes in BTF and in the original CO-RE implementation, more specifically the structure used and how the relocations were

[PATCH 4/5] bpf: implementation of func_info in .BTF.ext.

Kernel verifier complains in some particular cases for missing func_info implementation in .BTF.ext. This patch implements it. Strings are cached locally in coreout.cc to avoid adding duplicated strings in the string list. This string deduplication should eventually be moved to the CTFC functions

[PATCH] aarch64: Allow aarch64-linux-muscl for heap trampolines [PR113971].

Tested on aarch64-linux-gnu, aarch64-darwin by me and on aarch64-linux-musl by Sam James (thanks!). OK for trunk? thanks Iain --- 8< --- This allows the same trampoline pattern to be used on all linux variants rather than restricting it to linux gnu. PR target/113971.

Re: [PATCH] rs6000: Neuter option -mpower{8,9}-vector [PR109987]

On Tue, Feb 20, 2024 at 05:27:07PM +0800, Kewen.Lin wrote: > > -mcpu=power8 implies -mvsx already. > > Yes, but users can specify -mno-vsx in RUNTESTFLAGS, dejagnu > framework can have different behaviors (options order) for > different versions, this explicit -mvsx is mainly for the >

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote: > So I think that without worrying about performance and ensuring that > there is no problem > > with binutils, I think we can make the following modifications: > >    -/* "nop" instruction 54525952 (andi $r0,$r0,0) is >    -   used for

Re: [PATCH] rs6000: Neuter option -mpower{8,9}-vector [PR109987]

Hi Segher, Thanks for the review comments! on 2024/2/20 02:45, Segher Boessenkool wrote: > Hi! > > On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote: >> As PR109987 and its duplicated bugs show, -mno-power8-vector >> (and -mno-power9-vector) cause some problems and as Segher >> pointed

Re: [Committed] analyzer: Fix maybe_undo_optimize_bit_field_compare vs non-scalar types [PR113983]

On Mon, Feb 19, 2024 at 01:33:33PM -0800, Andrew Pinski wrote: > * gcc.dg/analyzer/torture/vector-extract-1.c: New test. The testcase fails on i686-linux with .../gcc/testsuite/gcc.dg/analyzer/torture/vector-extract-1.c:11:1: warning: MMX vector return without MMX enabled changes the ABI

[PATCH 3/5] btf: moved btf deallocation to final.

Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of allocation/deallocation of BTF structures. Moving deallocation to final when needed. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_option_override): Make BTF.ext enabled by default for BPF.

[PATCH 2/5] btf: added KIND_FUNC traversal function.

Added a traversal function to traverse all BTF_KIND_FUNC nodes with a callback function. Used for .BTF.ext section content creation. gcc/ChangeLog * btfout.cc (output_btf_func_types): use FOR_EACH_VEC_ELT. (traverse_btf_func_types): Defined function. * ctfc.h

[PATCH 5/5] bpf: renamed coreout.* files to btfext-out.*.

gcc/ChangeLog: * config.gcc (target_gtfiles): changed coreout to btfext-out. (extra_objs): changed coreout to btfext-out. * config/bpf/coreout.cc: Renamed to btfext-out.cc * config/bpf/btfext-out.cc: Added * config/bpf/coreout.h: Renamed to btfext-out.h

Re: [PATCH][GCC 12] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

Alex Coplan writes: > On 14/02/2024 11:18, Richard Sandiford wrote: >> Alex Coplan writes: >> > This is a backport of the GCC 13 fix for PR111677 to the GCC 12 branch. >> > The only part of the patch that isn't a straight cherry-pick is due to >> > the TX iterator lacking TDmode for GCC 12, so

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

在 2024/2/20 下午7:31, Xi Ruoyao 写道: On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote: On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote: So I think that without worrying about performance and ensuring that there is no problem with binutils, I think we can make the following modifications:

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

On Tue, 2024-02-20 at 19:50 +0800, chenglulu wrote: > > 在 2024/2/20 下午7:31, Xi Ruoyao 写道: > > On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote: > > > On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote: > > > > > > > So I think that without worrying about performance and ensuring that > > > >

Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?

在 2024/2/20 下午7:54, Xi Ruoyao 写道: On Tue, 2024-02-20 at 19:50 +0800, chenglulu wrote: 在 2024/2/20 下午7:31, Xi Ruoyao 写道: On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote: On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote: So I think that without worrying about performance and ensuring

Re: GCN RDNA2+ vs. GCC SLP vectorizer

On Tue, 20 Feb 2024, Thomas Schwinge wrote: > Hi Richard! > > On 2024-02-20T08:44:35+0100, Richard Biener wrote: > > On Mon, 19 Feb 2024, Thomas Schwinge wrote: > >> On 2024-02-19T17:31:20+0100, I wrote: > >> > On 2024-02-19T11:52:55+0100, Richard Biener wrote: > >> >> On Mon, 19 Feb 2024,

[PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange

On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote: > I'm not sure those would be really equivalent (MEM_REF vs. V_C_E > as well as combined vs. split). It really depends how RTL expansion > handles this (as you can see padding can be fun here). > > So I'd be nervous for a match.pd

Re: [PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange

On Tue, Feb 20, 2024 at 11:11:22AM +0100, Richard Biener wrote: > > --- gcc/c-family/c-common.cc.jj 2024-02-17 16:40:42.831571693 +0100 > > +++ gcc/c-family/c-common.cc2024-02-20 10:58:56.599865656 +0100 > > @@ -7793,9 +7793,14 @@ resolve_overloaded_atomic_exchange (loca > >/*

Re: GCN RDNA2+ vs. GCC SLP vectorizer

Hi Richard! On 2024-02-20T08:44:35+0100, Richard Biener wrote: > On Mon, 19 Feb 2024, Thomas Schwinge wrote: >> On 2024-02-19T17:31:20+0100, I wrote: >> > On 2024-02-19T11:52:55+0100, Richard Biener wrote: >> >> On Mon, 19 Feb 2024, Thomas Schwinge wrote: >> >>> On 2024-02-16T14:53:04+0100, I

Re: [PATCH] rs6000: Update instruction counts due to combine changes [PR112103]

Hi Peter, on 2024/2/20 06:35, Peter Bergner wrote: > rs6000: Update instruction counts due to combine changes [PR112103] > > The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c. > Adjust expected instruction counts accordingly. > > This passed on both powerpc64le-linux

Re: [PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange

On Tue, 20 Feb 2024, Jakub Jelinek wrote: > On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote: > > I'm not sure those would be really equivalent (MEM_REF vs. V_C_E > > as well as combined vs. split). It really depends how RTL expansion > > handles this (as you can see padding can be

Re: [PATCH] ipa: Convert lattices from pure array to vector (PR 113476)

> On Tue, Feb 13 2024, Martin Jambor wrote: > > On Mon, Feb 12 2024, Jan Hubicka wrote: > >>> Believe it or not, even though I have re-worked the internals of the > >>> lattices completely, the array itself is older than my involvement with > >>> GCC (or at least with ipa-cp.c ;-). > >>> > >>> So

Re: [PATCH]AArch64: update vget_set_lane_1.c test output

Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Thursday, February 1, 2024 4:42 PM >> To: Tamar Christina >> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; nd >> ; Richard Earnshaw ; Marcus >> Shawcroft ; Kyrylo Tkachov >> >> Subject: Re: [PATCH]AArch64:

Re: Repost [PATCH 1/6] Add -mcpu=future

Hi Mike, Sorry for late reply (just back from vacation). on 2024/2/8 03:58, Michael Meissner wrote: > On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote: >> on 2024/2/6 14:01, Michael Meissner wrote: >> Sorry for the possible confusion here, the "tune_proc" that I referred to is >> the

[pushed] aarch64: Fix streaming-compatible code with -mtrack-speculation [PR113805]

This patch makes -mtrack-speculation work on streaming-compatible functions. There were two related issues. The first is that the streaming-compatible code was using TB(N)Z unconditionally, whereas those instructions are not allowed with speculation tracking. That part can be fixed in a similar

Re: [PATCH] aarch64: Allow aarch64-linux-muscl for heap trampolines [PR113971].

On Tue, Feb 20, 2024 at 11:27 AM Iain Sandoe wrote: > > Tested on aarch64-linux-gnu, aarch64-darwin by me and on aarch64-linux-musl > by Sam James (thanks!). OK for trunk? OK > thanks > Iain > > --- 8< --- > > > This allows the same trampoline pattern to be used on all linux variants > rather

Re: [PATCH] libcpp: Improve location for macro names [PR66290]

On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote: > > This backport for gcc-13 is the first of two required for the > g++.dg/pch/line-map-3.C test to stop hitting a variant of the known > problem mentioned in that testcase: on riscv64-elf and riscv32-elf, > after restoring the PCH, the

Re: [PATCH] bpf: Add documentation for the -mcpu option

Hello Will. Thanks for the patch. I just installed it on your behalf. > Add documentation describing the meaning and values for the -mcpu > command-line option. > > Tested for bpf-unknown-none on x86_64-linux-gnu host. > > gcc/ChangeLog: > > * config/bpf/bpf.opt: Add help information for

Re: [PATCH] RISC-V: Fix riscv/arch-19.c with different ISA spec version

LGTM :) On Tue, Feb 20, 2024 at 12:03 PM Alexandre Oliva wrote: > > This testcase is failing with riscv64-elf and riscv32-elf in the gcc-13 > branch, if configured to use an assembler that supports -misa-spec; with > an assembler that doesn't, the test passes both with and without the >

Re: [PATCH] RISC-V: Fix CTZ unnecessary sign extension [PR #106888]

On Feb 20, 2024, Jeff Law wrote: > On 2/19/24 21:26, Alexandre Oliva wrote: >> This backport for gcc-13 is required for pr90838.c to get the expected >> count of andi instructions on riscv64-elf . > In general, shouldn't backports be focused on correctness issues? *nod*. > It's unclear what

[patch,avr,applied] Use @defbuiltin to document built-ins.

This patch uses @defbuiltin to document built-in functions so that the functions are listed in the index. Previously, @table @code was used. Johann -- AVR: extend.texi - Use @defbuiltin to document built-ins. gcc/ * doc/extend.texi (AVR Built-in Functions): Use @defbuiltin

[patch,avr,applied] Use int types of exact width and signedness in built-ins prototypes

AVR: Use types of exact size and signedness in built-ins. The AVR built-ins used types like "int" or "char" that don't have exact signedness or type size which depend on -mint8 and -f[no-][un-]signed-char etc. As the built-ins are modelling machine instructions of given type sizes and

[PATCH] doc: RISC-V: Document that -mcpu doesn't override -march or -mtune

This came up recently as Edwin was looking through the test suite. A few of us were talking about this during the patchwork meeting and were surprised. Looks like this is the desired behavior, so let's at least document it. gcc/ChangeLog: * doc/invoke.texi: Document -mcpu.

[PATCH v9 23/24] c++: Implement __is_invocable built-in trait

This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE. * semantics.cc (trait_expr_value): Likewise. (finish_trait_expr): Likewise.

rs6000, built-in cleanup patch series

GCC maintainers: The following series of patches cleanup some of the rs6000 built-in support. Some of the first patches fix errors in the definition of a few of the built-ins. The built-ins are supposed to have unsigned arguments but are listed as signed. Some of the built-ins are supposed

[PATCH 01/11] rs6000, Fix __builtin_vsx_cmple* args and documentation, builtins

GCC maintainers: This patch fixes the arguments and return type for the various __builtin_vsx_cmple* built-ins. They were defined as signed but should have been defined as unsigned. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable

[PATCH 03/11] rs6000, remove duplicated built-ins

GCC maintainers: There are a number of undocumented built-ins that are duplicates of other documented built-ins. This patch removes the duplicates so users will only use the documented built-in. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is

[PATCH 09/11] rs6000, add test cases for the vec_cmpne built-ins

GCC maintainers: The patch adds test cases for the vec_cmpne of built-ins. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

[PATCH 07/11] rs6000, __builtin_vsx_xvcmpeq[sp, dp, sp_p] add, documentation and test case

GCC maintainers: The patch adds documentation and test case for the __builtin_vsx_xvcmpeq[sp, dp, sp_p] built-ins. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

Re: [Patch] OpenMP/nvptx: support 'arch(nvptx64)' as context selector

On Tue, Feb 20, 2024 at 05:39:39PM +0100, Tobias Burnus wrote: > clang/lib/Headers/openmp_wrappers/complex:device = {arch(amdgcn, nvptx, > nvptx64)}, \ That one doesn't really need the nvptx64 support. > --- a/gcc/config/nvptx/nvptx.cc > +++

[PATCH 04/11] rs6000, Update comment for the __builtin_vsx_vper*, built-ins.

GCC maintainers: The patch expands an existing comment to document that the duplicates are covered by an overloaded built-in. I am wondering if we should just go ahead and remove the duplicates? The patch has been tested on Power 10 with no regressions. Please let me know if this patch is

PATCH 10/11] rs6000, add test cases for __builtin_vec_init* and, __builtin_vec_set*

GCC maintainers: The patch adds test cases for the __builtin_vec_init* and __builtin_vec_set* built-ins. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

PATCH 11/11] rs6000, make test vec-cmpne.c a runnable test

GCC maintainers: The patch changes the vec-cmpne.c from a compile only test to a runnable test. The macros to create the functions needed to test the built-ins and verify the restults are all there in the include file. The .c file just needed to have the macro definitions inserted and

Re: [PATCH] bpf: Add documentation for the -mcpu option

On Tue, Feb 20, 2024 at 7:35 AM Jose E. Marchesi wrote: > > > Hello Will. > > Thanks for the patch. > I just installed it on your behalf. Thank you! > > > Add documentation describing the meaning and values for the -mcpu > > command-line option. > > > > Tested for bpf-unknown-none on

[PATCH 02/11] rs6000, fix arguments, add documentation for vector, element conversions

GCC maintainers: This patch fixes the return type for the __builtin_vsx_xvcvdpuxws and __builtin_vsx_xvcvspuxds built-ins. They were defined as signed but should have been defined as unsigned. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is

[PATCH 05/11] rs6000, __builtin_vsx_xvneg[sp,dp] add documentation, and test cases

GCC maintainers: The patch adds documentation and test cases for the __builtin_vsx_xvnegsp, __builtin_vsx_xvnegdp built-ins. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior

   libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_wrap behavior     In _GLIBCXX_DEBUG mode the std::__niter_base can remove 2 layers, the     __gnu_debug::_Safe_iterator<> and the __gnu_cxx::__normal_iterator<>.     When std::__niter_wrap is called to build a __gnu_debug::_Safe_iterator<>    

[PATCH v2] bpf: add inline memmove and memcpy expansion

[Changes from v1: Jose's review comments, all of which I agree with. - Fix 'implments' typo in commit message. - Change check that alignment is CONST_INT to gcc_assert (). - Change default case in alignment switch to gcc_unreachable (). - Reword error message for non-constant size

Re: [PATCH] rs6000: Update instruction counts due to combine changes [PR112103]

On 2/20/24 3:29 AM, Kewen.Lin wrote: > on 2024/2/20 06:35, Peter Bergner wrote: >> rs6000: Update instruction counts due to combine changes [PR112103] >> >> The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c. >> Adjust expected instruction counts accordingly. >> >> This

Re: [PATCH] Fortran: fix passing array component to polymorphic argument [PR105658]

On 2/19/24 16:19, Peter Hill wrote: Hi Harald, Thanks for your help, please see the updated and signed-off patch below. Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2

Re: [PATCH] libgcc, aarch64: Allow for BE platforms in heap trampolines.

Iain Sandoe writes: > Andrew Pinski pointed out on irc, that the current implementation of the > heap trampoline code fragment would make the instruction byte order follow > memory byte order for BE AArch64, which is not what is required. > > This patch revises the initializers so that

Re: [PATCH v2] bpf: add inline memmove and memcpy expansion

Hi Faust. > +bool > +bpf_expand_cpymem (rtx *operands, bool is_move) > +{ > + /* Size must be constant for this expansion to work. */ > + if (!CONST_INT_P (operands[2])) > +{ > + const char *name = is_move ? "memmove" : "memcpy"; > + if (flag_building_libgcc) > + warning

Re: [PATCH 3/5] btf: moved btf deallocation to final.

Hi Cupertino, On 2/20/24 02:24, Cupertino Miranda wrote: > Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of > allocation/deallocation of BTF structures. Moving deallocation to final > when needed. > > gcc/ChangeLog: > > * config/bpf/bpf.cc (bpf_option_override):

Re: [PATCH] libgccjit: Add option to allow special characters in function names

On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote: > Hi. > This patch adds a new option to allow special characters like . and $ > in function names. > This is useful to allow for mangling using those characters. > Thanks for the review. Thanks for the patch. > diff --git

Re: [PATCH] libgccjit: Add option to allow special characters in function names

> On 20 Feb 2024, at 20:50, David Malcolm wrote: > > On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote: >> Hi. >> This patch adds a new option to allow special characters like . and $ >> in function names. >> This is useful to allow for mangling using those characters. >> Thanks for the

[Patch] OpenMP/nvptx: support 'arch(nvptx64)' as context selector

I just encountered 'arch(nvptx64)'. I think it makes sense to support it as alias for 'nvptx' in the context selector for better compatibility. Comments, remarks, suggestions? Tobias PS: See the LLVM documentation below. I do note that those are not identical as LLVM uses 'nvptx' for 32bit

[PATCH 06/11] rs6000, __builtin_vsx_xxpermdi_1ti add documentation, and test case

GCC maintainers: The patch adds documentation and test case for the __builtin_vsx_xxpermdi_1ti built-in. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

[PATCH 08/11] rs6000, add tests and documentation for various, built-ins

GCC maintainers: The patch adds documentation a number of built-ins. The patch has been tested on Power 10 with no regressions. Please let me know if this patch is acceptable for mainline. Thanks. Carl

Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior

On Tue, 20 Feb 2024 at 18:43, François Dumont wrote: > >libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_wrap behavior > > In _GLIBCXX_DEBUG mode the std::__niter_base can remove 2 layers, the > __gnu_debug::_Safe_iterator<> and the __gnu_cxx::__normal_iterator<>. > When

Re: [PATCH 1/5] btf: fixed type id in BTF_KIND_FUNC struct data.

On 2/20/24 02:24, Cupertino Miranda wrote: > This patch correct the aditition of +1 on the type id, which originally > was done in the wrong location and leaded to func_sts->dtd_type for > BTF_KIND_FUNCS struct data to contain the type id of the previous entry. > > gcc/ChangeLog: > *

Re: [PATCH] Fortran: fix passing array component to polymorphic argument [PR105658]

On Tue, Feb 20, 2024 at 08:53:37PM +0100, Harald Anlauf wrote: > On 2/19/24 16:19, Peter Hill wrote: > > Hi Harald, > > > > Thanks for your help, please see the updated and signed-off patch below. > > Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2 > Harald, Thanks for

[PATCH V2] RISC-V: Specify mtune and march for PR113742

The testcase pr113742.c is failing for 32 bit targets due to the following cc1 error: cc1: error: ABI requries '-march=rv64' Specify '-march=rv64gc' with '-mtune=sifive-p600-series' V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645609.html PR target/113742

[PATCH v10 24/24] libstdc++: Optimize std::is_invocable compilation performance

This patch optimizes the compilation performance of std::is_invocable by dispatching to the new __is_invocable built-in trait. libstdc++-v3/ChangeLog: * include/std/type_traits (is_invocable): Use __is_invocable built-in trait. *

[PATCH v1 2/4] LoongArch: Check whether binutils supports the relax function. If supported, explicit relocs are turned off by default.

gcc/ChangeLog: * config.in: Regenerate. * config/loongarch/genopts/loongarch.opt.in: Add compilation option mrelax. And set the initial value of explicit-relocs according to the detection status. * config/loongarch/gnu-user.h: When compiling with

[PATCH] c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224]

After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the

[PATCH v1] RISC-V: Upgrade RVV intrinsic version to 0.12

From: Pan Li Upgrade the version of RVV intrinsic from 0.11 to 0.12. PR target/114017 gcc/ChangeLog: * config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Upgrade the version to 0.12. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-__riscv_v_intrinsic.c:

[PATCH v11 23/24] c++: Implement __is_invocable built-in trait

This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE. * semantics.cc (trait_expr_value): Likewise. (finish_trait_expr): Likewise.

Re: Repost [PATCH 1/6] Add -mcpu=future

On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote: > Hi Mike, > > Sorry for late reply (just back from vacation). > > on 2024/2/8 03:58, Michael Meissner wrote: > > On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote: > >> on 2024/2/6 14:01, Michael Meissner wrote: > >> Sorry for

[PATCH v3] bpf: add inline memmove and memcpy expansion

[Changes from v2: - Fix incorrectly passing a location instead of OPT_W* for warning (). - Reword warning/error message and test accordingly. ] [Changes from v1: Jose's review comments, all of which I agree with. - Fix 'implments' typo in commit message. - Change check that alignment is

[PATCH v1 0/4] Fix a series of problems caused by

Because binutils2.42 corrects the implementation of ".align [abs-expr,[abs-expr[,abs-expr]]]". The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive, and an error occurs. See link below for detailed description. https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html

[PATCH v1 1/4] LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP.

There are two reasons for removing this macro definition: 1. The default in the assembler is to use the nop instruction for filling. 2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]] The third expression it is the maximum number of bytes that should be skipped by this

[PATCH v1 4/4] LoongArch: Define HAVE_AS_TLS to 0 if it's undefined [PR112299]

From: Xi Ruoyao Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure building a cross compiler if the cross assembler is not installed yet. gcc/ChangeLog: PR target/112299 * config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0 if not defined yet.

Re: [PATCH v1 0/4] Fix a series of problems caused by

Sorry, this title is incomplete and has been resent. 在 2024/2/21 上午11:08, Lulu Cheng 写道: Because binutils2.42 corrects the implementation of ".align [abs-expr,[abs-expr[,abs-expr]]]". The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive, and an error occurs. See link below

Re: [PATCH V2] RISC-V: Specify mtune and march for PR113742

LGTM, thanks for fixing that issue :) On Wed, Feb 21, 2024 at 6:03 AM Edwin Lu wrote: > > The testcase pr113742.c is failing for 32 bit targets due to the following cc1 > error: > cc1: error: ABI requries '-march=rv64' > > Specify '-march=rv64gc' with '-mtune=sifive-p600-series' > > V1:

Re: [PATCH] rs6000: Update instruction counts due to combine changes [PR112103]

On Tue, Feb 20, 2024 at 01:49:30PM -0600, Peter Bergner wrote: > I think this will become less fragile after we fix PR114004 which is You call it "fragile". I call it the testcase found the exact kind of bug this testcase was meant to find! Yes, the test should become quieter when the compiler

[PATCH v1 3/4] LoongArch: Disable relaxation if the assembler don't support conditional branch relaxation [PR112330]

From: Xi Ruoyao As the commit message of r14-4674 has indicated, if the assembler does not support conditional branch relaxation, a relocation overflow may happen on conditional branches when relaxation is enabled because the number of NOP instructions inserted by the assembler will be more than

[PATCH v1 0/4] Fix a series of problems caused by ASM_OUTPUT_ALIGN_WITH_NOP (release/gcc-12).

Because binutils2.42 corrects the implementation of ".align [abs-expr,[abs-expr[,abs-expr]]]". The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive, and an error occurs. See link below for detailed description. https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html

[PATCH v1 2/4] LoongArch: Check whether binutils supports the relax function. If supported, explicit relocs are turned off by default.

gcc/ChangeLog: * config.in: Regenerate. * config/loongarch/genopts/loongarch.opt.in: Add compilation option mrelax. And set the initial value of explicit-relocs according to the detection status. * config/loongarch/gnu-user.h: When compiling with

[PATCH v1 1/4] LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP.

There are two reasons for removing this macro definition: 1. The default in the assembler is to use the nop instruction for filling. 2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]] The third expression it is the maximum number of bytes that should be skipped by this

[PATCH v2] LoongArch: Split loongarch_option_override_internal into smaller procedures

gcc/ChangeLog: * config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as aliases to -mrecip={all,none}. * config/loongarch/loongarch.opt: Same. * config/loongarch/loongarch-def.h: Modify ABI condition macros for convenience. *

[PATCH] c++: -Wuninitialized when binding a ref to uninit DM [PR113987]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR asks that our -Wuninitialized for mem-initializers does not warn when binding a reference to an uninitialized data member. We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but that won't catch binding a

[PATCH v1 3/4] LoongArch: Disable relaxation if the assembler don't support conditional branch relaxation [PR112330]

From: Xi Ruoyao As the commit message of r14-4674 has indicated, if the assembler does not support conditional branch relaxation, a relocation overflow may happen on conditional branches when relaxation is enabled because the number of NOP instructions inserted by the assembler will be more than

[PATCH v1 4/4] LoongArch: Define HAVE_AS_TLS to 0 if it's undefined [PR112299]

From: Xi Ruoyao Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure building a cross compiler if the cross assembler is not installed yet. gcc/ChangeLog: PR target/112299 * config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0 if not defined yet.

[PATCH v1 1/4] LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP.

There are two reasons for removing this macro definition: 1. The default in the assembler is to use the nop instruction for filling. 2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]] The third expression it is the maximum number of bytes that should be skipped by this

[PATCH v1 0/4] Fix a series of problems caused by

Because binutils2.42 corrects the implementation of ".align [abs-expr,[abs-expr[,abs-expr]]]". The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive, and an error occurs. See link below for detailed description. https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html

[PATCH v1 4/4] LoongArch: Define HAVE_AS_TLS to 0 if it's undefined [PR112299]

From: Xi Ruoyao Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure building a cross compiler if the cross assembler is not installed yet. gcc/ChangeLog: PR target/112299 * config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0 if not defined yet.

Re: [PATCH] rs6000: Neuter option -mpower{8,9}-vector [PR109987]

on 2024/2/21 09:37, Peter Bergner wrote: > On 2/20/24 3:27 AM, Kewen.Lin wrote: >> on 2024/2/20 02:45, Segher Boessenkool wrote: >>> On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote: it consists of some aspects: - effective target powerpc_p{8,9}vector_ok are removed

[pushed] analyzer: handle empty ranges in symbolic_byte_range::intersection [PR113998]

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-9090-g79d4c7ddc83e00. gcc/analyzer/ChangeLog: PR analyzer/113998 * ranges.cc (symbolic_byte_range::intersection): Handle empty

[pushed] analyzer: handle array-initialization from a string_cst [PR113999]

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-9091-g0a6a5f8656ccf9. gcc/analyzer/ChangeLog: PR analyzer/113999 * analyzer.h (get_string_cst_size): New decl. *

  1   2   >