[PATCH] i386: Fix up *jcc_bt*_mask{,_1} [PR111408]

Hi! The following testcase is miscompiled in GCC 14 because the *jcc_bt_mask and *jcc_bt_mask_1 patterns have just one argument in (match_operator 0 "bt_comparison_operator" [...]) but as bt_comparison_operator is eq,ne, we need two. The md readers don't warn about it, after all, some checks can

Re: libstdc++: Speed up push_back

On Fri, 24 Nov 2023 at 20:07, Jan Hubicka wrote: > The vector.tcc change was regtested on x86_64-linux, OK? > > libstdc++-v3/ChangeLog: > > * include/bits/vector.tcc (reserve): Copy _M_start and _M_finish > to local variables to allow propagation across call to >

Re: [PATCH] aarch64: Fix up aarch64_simd_stp [PR109977]

Jakub Jelinek writes: > Hi! > > The aarch64_simd_stp pattern uses w constraint in one alternative and > r in another, but for the latter incorrectly uses iterator in %1 > which > expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to > the pattern) and %w1 for others, so it

Re: [wwwdocs][patch][OpenMP] gcc-14/changes.html + projects/gomp/: OpenMP update

On Fri, 24 Nov 2023, Tobias Burnus wrote: > While I expect more changes, I want to cleanup my stashed changes. Good approach! + The destory now optionally accepts the depend object as + argument. Is "depend object" a well known technical term in that context? And is it "the depend

Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

Okay within about half an hour today I think I've figured out what the main issue is for my problem. For the static lambda case, while I don't like the hack that's currently present, I reckon we just leave it as it is, as it works just fine right now. For my issue, I'm not totally sure how to

Re: [PATCH] c++/modules: more checks for exporting names with using-declarations

On 11/10/23 17:52, Nathaniel Shead wrote: I noticed while fixing PR106849 that we don't currently check validity of exporting non-functions via using-declarations either; this patch adds those checks factored out into a new function. I also tried to make the error messages a bit more

Re: [PATCH] c++: Allow exporting a typedef redeclaration [PR102341]

On 11/23/23 21:10, Nathaniel Shead wrote: On Thu, Nov 23, 2023 at 11:45:31AM -0500, Nathan Sidwell wrote: On 11/13/23 01:09, Nathaniel Shead wrote: I happened to be browsing the standard a bit later and noticed that we incorrectly reject the example given below. Bootstrapped on

Re: [wwwdocs][patch][GCN] gcc-14/changes.html: GCN - Mention improvements due to VGPR register use

On Fri, 24 Nov 2023, Tobias Burnus wrote: > As in a set of benchmarks, an geometric-mean improvement of 9% (noise to > 25%) was found, I think we should mention this improvement proudly. Definitely! > Comments? The ", hence," broke my reading flow; maybe simply omit it? Either way, okay.

Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

OKAY, I figured out SOMETHING, I think this should be fine. As noted in the comments, this might be a better way of handling the static lambda case too. This is still a nasty hack so it should probably be done differently, but I question if making a whole new fntype node in tsubst_lambda_expr

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

On Fri, 2023-11-24 at 16:36 +0800, chenglulu wrote: > > 在 2023/11/24 下午4:26, Xi Ruoyao 写道: > > On Fri, 2023-11-24 at 16:01 +0800, chenglulu wrote: > > > I only saw lrint llrint in n2310 with this description: > > > > > > F7.12.9.5 > > > > > > "The lrint and llrint functions round their argument

Re: [PATCH] rs6000: Disassemble opaque modes using subregs to allow optimizations [PR109116]

Hi Peter, on 2023/11/16 07:50, Peter Bergner wrote: > PR109116 exposes an issue where using unspecs to access each vector component > of an opaque mode variable leads to unneeded register copies, because our rtl > optimizers cannot handle unspecs. Instead, use subregs to access each vector >

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

在 2023/11/24 上午10:39, Xi Ruoyao 写道: On Thu, 2023-11-23 at 18:03 +, Joseph Myers wrote: The rint functions indeed don't set errno (don't have domain or range errors, at least if you ignore the option for signaling NaNs arguments to be domain errors - which is in TS 18661-1, but not what

Re: [PATCH] RISC-V: Fix inconsistency among all vectorization hooks

LGTM. Regards Robin

[PATCH][Binutils] AArch64: Enable Debug (FEAT_DEBUGv8p9) extension

Hey, This patch enables FEAT_DEBUGv8p9 extension for AArch64 and adds its system registers. FEAT_DEBUGv8p9 is default from Armv8.9-A Architecture. Did regression testing for aarch64-none-elf target and found no regressions. Ok for master? I don't have commit access so I need someone to

Re: [PATCH v2] rs6000: Add new pass for replacement of contiguous addresses vector load lxv with lxvp

Hi Ajit, Don't forget to CC David (CC-ed) :), some comments are inlined below. on 2023/10/8 03:04, Ajit Agarwal wrote: > Hello All: > > This patch add new pass to replace contiguous addresses vector load lxv with > mma instruction > lxvp. IMHO the current binding lxvp (and lxvpx, stxvp{x,})

Re: [PATCH] match.pd: Avoid simplification into invalid BIT_FIELD_REFs [PR112673]

On Fri, 24 Nov 2023, Jakub Jelinek wrote: > Hi! > > The following testcase is lowered by the bitint lowering pass, then > vectorizer vectorizes one of the loops in it, so we have > vect__18.6_34 = VIEW_CONVERT_EXPR(x_35(D)); > _8 = BIT_FIELD_REF ; > ... > _18 = BIT_FIELD_REF ; > etc. where

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

在 2023/11/24 下午4:42, Xi Ruoyao 写道: On Fri, 2023-11-24 at 16:36 +0800, chenglulu wrote: 在 2023/11/24 下午4:26, Xi Ruoyao 写道: On Fri, 2023-11-24 at 16:01 +0800, chenglulu wrote: I only saw lrint llrint in n2310 with this description: F7.12.9.5 "The lrint and llrint functions round their

[PATCH] lower-bitint: Lower FLOAT_EXPR from BITINT_TYPE INTEGER_CST [PR112679]

Hi! The bitint lowering pass only does something if it sees BITINT_TYPE (medium, large, huge) SSA_NAMEs. In the past I've already ran into one special case where the above doesn't work well, if there is a store of medium/large/huge BITINT_TYPE INTEGER_CST into memory, there might not be any

[PATCH] match.pd: Avoid simplification into invalid BIT_FIELD_REFs [PR112673]

Hi! The following testcase is lowered by the bitint lowering pass, then vectorizer vectorizes one of the loops in it, so we have vect__18.6_34 = VIEW_CONVERT_EXPR(x_35(D)); _8 = BIT_FIELD_REF ; ... _18 = BIT_FIELD_REF ; etc. where x_35(D) is _BitInt(256) argument. That is valid

[PATCH] c++, v3: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349]

On Mon, Sep 18, 2023 at 07:12:40PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Tue, Aug 22, 2023 at 09:39:11AM +0200, Jakub Jelinek via Gcc-patches wrote: > > The following patch implements the C++26 P2169R4 paper. > > As written in the PR, the patch expects that: > > 1)

[PATCH] RISC-V: Fix inconsistency among all vectorization hooks

This patches 200+ ICEs exposed by testing with rv64gc_zve64d. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112694 The rootcause is we disallow poly (1,1) size vectorization in preferred_simd_mode. with this following code: - if (TARGET_MIN_VLEN < 128 && TARGET_MAX_LMUL < RVV_M2) -

[PATCH v2] Only allow (int)trunc(x) to (int)x simplification with -ffp-int-builtin-inexact [PR107723]

With -fno-fp-int-builtin-inexact, trunc is not allowed to raise FE_INEXACT and it should produce an integral result (if the input is not NaN or Inf). Thus FE_INEXACT should not be raised. But (int)x may raise FE_INEXACT when x is a non-integer, non-NaN, and non-Inf value. C23 recommends to do

Re: [PATCH] lower-bitint: Lower FLOAT_EXPR from BITINT_TYPE INTEGER_CST [PR112679]

On Fri, 24 Nov 2023, Jakub Jelinek wrote: > Hi! > > The bitint lowering pass only does something if it sees BITINT_TYPE (medium, > large, huge) SSA_NAMEs. In the past I've already ran into one special case > where the above doesn't work well, if there is a store of medium/large/huge >

Re: [PATCH 0/4] Add vector pair support to PowerPC attribute((vector_size(32)))

on 2023/11/20 16:56, Michael Meissner wrote: > On Mon, Nov 20, 2023 at 08:24:35AM +0100, Richard Biener wrote: >> I wouldn't expose the "fake" larger modes to the vectorizer but rather >> adjust m_suggested_unroll_factor (which you already do to some extent). > > Thanks. I figure I first need to

Re: [PATCH 0/5] Add support for operand-specific alignment requirements

"juzhe.zh...@rivai.ai" writes: > Hi, Richard. > > Here is an example for vsext.vf2. > > The general pattern for this instruction as follows: > > (set (operand 0) (unspec:...(operand 1))) > > We have a TARGET_MIN_VLEN macro which specify minimum VLEN according to -march > > Consider this case

Re: [PATCH 1/2] libcpp: configure: drop unused Valgrind detection

On Thu, Nov 23, 2023 at 7:14 PM Alexander Monakov wrote: > > When top-level configure has either --enable-checking=valgrind or > --enable-valgrind-annotations, we want to activate a couple of workarounds > in libcpp. They do not use anything from the Valgrind API, so just > delete all detection.

Re: [PATCH 2/2] gcc: configure: drop Valgrind 3.1 compatibility

On Thu, Nov 23, 2023 at 7:14 PM Alexander Monakov wrote: > > Our system.h and configure.ac try to accommodate valgrind-3.1, but it is > more than 15 years old at this point. As Valgrind-based checking is a > developer-oriented feature, drop the compatibility stuff and streamline > the detection.

Re: [PATCH] Only allow (int)trunc(x) to (int)x simplification with -ffp-int-builtin-inexact [PR107723]

On Fri, Nov 24, 2023 at 6:33 AM Xi Ruoyao wrote: > > With -fno-fp-int-builtin-inexact, trunc is not allowed to raise > FE_INEXACT and it should produce an integral result (if the input is not > NaN or Inf). Thus FE_INEXACT should not be raised. > > But (int)x may raise FE_INEXACT when x is a

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

On Fri, 2023-11-24 at 16:01 +0800, chenglulu wrote: > I only saw lrint llrint in n2310 with this description: > > F7.12.9.5 > > "The lrint and llrint functions round their argument to the nearest > integer value, rounding > according to the current rounding direction. If the rounded value is >

[PATCH] i386: Fix ICE during cbranchv16qi4 expansion [PR112681]

Hi! The following testcase ICEs, because cbranchv16qi4 expansion calls ix86_expand_branch with op1 being a pre-AVX unaligned memory and ix86_expand_branch emits a xorv16qi3 instruction without making sure the operand predicates are satisfied. While I could manually check if the argument (or

Re: [PATCH] Only allow (int)trunc(x) to (int)x simplification with -ffp-int-builtin-inexact [PR107723]

On Fri, 2023-11-24 at 09:27 +0100, Richard Biener wrote: > > diff --git a/gcc/convert.cc b/gcc/convert.cc > > index 46c8bcb31f8..31f63ea783b 100644 > > --- a/gcc/convert.cc > > +++ b/gcc/convert.cc > > @@ -591,7 +591,8 @@ convert_to_integer_1 (tree type, tree expr, bool dofold) > >

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

在 2023/11/24 下午4:26, Xi Ruoyao 写道: On Fri, 2023-11-24 at 16:01 +0800, chenglulu wrote: I only saw lrint llrint in n2310 with this description: F7.12.9.5 "The lrint and llrint functions round their argument to the nearest integer value, rounding according to the current rounding direction.

RE: [PATCH 4/21]middle-end: update loop peeling code to maintain LCSSA form for early breaks

Hi All, Here's an updated patch, which takes a slightly different approach but makes things much easier later on. Peeling for early breaks works by redirecting all early break exits to a single "early break" block and combine them and the normal exit edge together later in a different block

Re: libstdc++: Speed up push_back

On Fri, 24 Nov 2023, Martin Jambor wrote: > Hello, > > On Thu, Nov 23 2023, Jonathan Wakely wrote: > > On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote: > >> > > [...] > > >> > >> I also wonder, if default operator new and malloc can be handled as not > >> reading/modifying anything visible to

[PATCH v2] c++: Follow module grammar more closely [PR110808]

On Thu, Nov 23, 2023 at 12:11:58PM -0500, Nathan Sidwell wrote: > On 11/14/23 01:24, Nathaniel Shead wrote: > > I'll also note that the comments above the parsing functions here no > > longer exactly match with the grammar in the standard, should they be > > updated as well? > > please. > As I

Re: [PATCH 2/5] aarch64: rcpc3: Add relevant iterators to handle Neon intrinsics

Victor Do Nascimento writes: > The LDAP1 and STL1 Neon ACLE intrinsics, operating on 64-bit data > values, operate on single-lane (Vt.1D) or twin-lane (Vt.2D) SIMD > register configurations, either in the DI or DF modes. This leads to > the need for a mode iterator accounting for the V1DI, V1DF,

Re: [PATCH][Binutils] AArch64: Enable Debug (FEAT_DEBUGv8p9) extension

Hey, On 11/24/2023 8:42 AM, Saurabh Jha wrote: Hey, This patch enables FEAT_DEBUGv8p9 extension for AArch64 and adds its system registers. FEAT_DEBUGv8p9 is default from Armv8.9-A Architecture. Did regression testing for aarch64-none-elf target and found no regressions. Ok for master?

Gcc - Everything for the Guest 2023

Hi, Hope you are doing well. Everything for the Guest 2023 list is available for the Snap up. Please let me know if you would like to know the Counts, Value and other details. I await your response. Tons of thanks, Kacie Miller - Demand Generation

[PATCH] tree-optimization/112677 - stack corruption with .COND_* reduction

The following makes sure to allocate enough space for vectype_op in vectorizable_reduction. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/112677 * tree-vect-loop.cc (vectorizable_reduction): Use alloca to allocate vectype_op. ---

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

On Fri, 2023-11-24 at 17:46 +0800, chenglulu wrote: > It's just that I'm confused that the description of rint in n2310, > including Joseph's email, > all say that rint will not set errno, but linux-man says "which might > set errno to ERANGE" . Annex F has: The C floating types match the IEC

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

On Fri, 24 Nov 2023, Tamar Christina wrote: > Hi, > > Having simplified peeling this patch becomes smaller as well: > > This changes the PHI node updates to support early breaks. > It has to support both the case where the loop's exit matches the normal loop > exit and one where the early exit

testsuite: Add 'only_for_offload_target' wrapper for 'scan-offload-tree-dump' etc. (was: drop -aux{dir,base}, revamp -dump{dir,base})

Hi! On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote: > handle dumpbase in offloading, adjust testsuite > Adjust the testsuite offload dump scanning machinery to look for dump > files named under the new conventions, iterating internally over all > configured offload targets, or recognizing

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

Good morning, This is a respun patch with a fix for VLA. This adds support to vectorizable_live_reduction to handle multiple exits by doing a search for which exit the live value should be materialized in. Additionally which value in the index we're after depends on whether the exit it's

Re: libstdc++: Speed up push_back

Hello, On Thu, Nov 23 2023, Jonathan Wakely wrote: > On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote: >> [...] >> >> I also wonder, if default operator new and malloc can be handled as not >> reading/modifying anything visible to the user code. > > No, there's no way to know if the default

Re: [PATCH] i386: Fix ICE during cbranchv16qi4 expansion [PR112681]

On Fri, Nov 24, 2023 at 9:31 AM Jakub Jelinek wrote: > > Hi! > > The following testcase ICEs, because cbranchv16qi4 expansion calls > ix86_expand_branch with op1 being a pre-AVX unaligned memory and > ix86_expand_branch emits a xorv16qi3 instruction without making sure > the operand predicates

Re: [PATCH 3/5] aarch64: rcpc3: Add Neon ACLE intrinsics

Victor Do Nascimento writes: > Register the target specific builtins in `aarch64-simd-builtins.def' > and implement their associated backend patterns in `aarch64-simd.md'. > > gcc/ChangeLog: > > * config/aarch64/aarch64-simd-builtins.def > (vec_ldap1_lane): New. >

Re: [PATCH 4/5] aarch64: rcpc3: add Neon ACLE wrapper functions to `arm_neon.h'

Victor Do Nascimento writes: > Create the necessary mappings from the ACLE-defined Neon intrinsics > names[1] to the internal builtin function names. > > [1] https://arm-software.github.io/acle/neon_intrinsics/advsimd.html > > gcc/ChangeLog: > > * gcc/config/aarch64/arm_neon.h

Re: [PATCH 5/5] aarch64: rcpc3: Add intrinsics tests

Victor Do Nascimento writes: > Add unit test to ensure that added intrinsics compile to the correct > `LDAP1 {Vt.D}[lane],[Xn]' and `STL1 {Vt.d}[lane],[Xn]' instructions. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/acle/rcpc3.c: New. OK, thanks. Richard > --- >

RE: [PATCH 4/21]middle-end: update loop peeling code to maintain LCSSA form for early breaks

On Fri, 24 Nov 2023, Tamar Christina wrote: > Hi All, > > Here's an updated patch, which takes a slightly different approach but makes > things much easier later on. > > Peeling for early breaks works by redirecting all early break exits to a > single "early break" block and combine them and

Re: [PATCH] sra: SRA of non-escaped aggregates passed by reference to calls

Hello, thanks a lot for your review. On Fri, Nov 17 2023, Richard Biener wrote: > On Thu, 16 Nov 2023, Martin Jambor wrote: > >> Hello, >> >> PR109849 shows that a loop that heavily pushes and pops from a stack >> implemented by a C++ std::vec results in slow code, mainly because the >> vector

[PATCH v1 1/1] RISC-V: Initial RV64E and LP64E support

From: Tsukasa OI Along with RV32E, RV64E is ratified. Though ILP32E and LP64E ABIs are still draft, it's worth supporting it. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_ext_version_table): Set version to ratified 2.0.

RE: [PATCH 7/21]middle-end: update IV update code to support early breaks and arbitrary exits

Hi, Having simplified peeling this patch becomes smaller as well: This changes the PHI node updates to support early breaks. It has to support both the case where the loop's exit matches the normal loop exit and one where the early exit is "inverted", i.e. it's an early exit edge. In the latter

[PATCH v1 0/1] RISC-V: Initial RV64E and LP64E support

Hi all, This single commit patch is intended to add initial support for RV64E and LP64E ABI. Following the discussion at: , "__riscv_64e" preprocessor macro will be a part of the RISC-V C API Specification, I will submit this patch as

Re: [PATCH 1/5] aarch64: rcpc3: Add +rcpc3 extension

Victor Do Nascimento writes: > Given the optional LRCPC3 target support for Armv8.2-a cores onwards, > the +rcpc3 arch feature modifier is added to GCC's command-line options. > > gcc/ChangeLog: > > * config/aarch64/aarch64-option-extensions.def (rcpc3): New. > *

[Patch,v3] OpenMP: Accept argument to depobj's destroy clause

As discussed on IRC, we now go for a warning and useOEP_LEXICOGRAPHIC - at least until the spec issue has been solve. [The OpenMP spec Issue 3739 tracks the open questions/issues mentioned in this thread.] Updated patch attached. Tobias - Siemens Electronic Design Automation

[patch] OpenMP: Add -Wopenmp and use it

Following the general trend to add a "[-W...]" to the warning messages for both better grouping of the warnings and - more importantly - for providing a means to silence such a warning (or to -Werror= them explicitly), this patch replaces several '0' by OPT_Wopenmp. Comments or remarks before I

Re: [PATCH] lower-bitint: Lower FLOAT_EXPR from BITINT_TYPE INTEGER_CST [PR112679]

On Fri, Nov 24, 2023 at 10:20:01AM +0100, Richard Biener wrote: > > + /* Similarly, e.g. with -frounding-math casts from _BitInt > > INTEGER_CSTs > > +to floating point types need to be rewritten. */ > > + else if (SCALAR_FLOAT_TYPE_P (type)) > > + { > > + gimple *g =

Re: [PATCH] lower-bitint: Lower FLOAT_EXPR from BITINT_TYPE INTEGER_CST [PR112679]

On Fri, 24 Nov 2023, Jakub Jelinek wrote: > On Fri, Nov 24, 2023 at 10:20:01AM +0100, Richard Biener wrote: > > > + /* Similarly, e.g. with -frounding-math casts from _BitInt > > > INTEGER_CSTs > > > + to floating point types need to be rewritten. */ > > > + else if

RE: [PATCH 8/21]middle-end: update vectorizable_live_reduction with support for multiple exits and different exits

On Fri, 24 Nov 2023, Tamar Christina wrote: > Good morning, > > This is a respun patch with a fix for VLA. > > This adds support to vectorizable_live_reduction to handle multiple exits by > doing a search for which exit the live value should be materialized in. > > Additionally which value in

GCN: Remove 'last_arg' spec function (was: GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves [PR112669])

Hi! On 2023-11-24T15:55:52+0100, I wrote: > OK to push the attached > "GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves > [PR112669]"? With that in place, we may then "GCN: Remove 'last_arg' spec function", see attached; OK to push? Grüße Thomas - Siemens

[PATCH] mips: Fix up mips*-sde-elf* build [PR112300]

Hi! As reported in the PR, mipsisa64r2-sde-elf doesn't build because HEAP_TRAMPOLINES_INIT macro isn't defined anywhere. It is normally defined by # Figure out if we need to enable heap trampolines by default case ${target} in *-*-darwin2*) # Currently, we do this for macOS 11 and above.

Re: GCN: Remove 'last_arg' spec function

On 24/11/2023 15:06, Thomas Schwinge wrote: Hi! On 2023-11-24T15:55:52+0100, I wrote: OK to push the attached "GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves [PR112669]"? With that in place, we may then "GCN: Remove 'last_arg' spec function", see attached; OK to push?

[patch][GCN] install.texi: Update GCN entry - @uref and LLVM version remark

Stumbled over this. I wondered whether we should recommend newlib >= 12e3bac3c (31st Oct 2023), but given that gfx1030 is not yet supported, I decided against it. We can revisit this once newlib 4.4 is available. Current version is: https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa

[wwwdocs][patch][GCN] gcc-14/changes.html: GCN - Mention improvements due to VGPR register use

As in a set of benchmarks, an geometric-mean improvement of 9% (noise to 25%) was found, I think we should mention this improvement proudly. (Kudos goes to two Andrews - Jenner and Stubbs!) Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn Comments? Tobias -

Re: [PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

Hi Cuper. Sorry, I missed this patch last week. This is OK. Thanks! > This patch forces __builtin_memcmp calls upto data sizes of 1024 to > become inline in caller. > This is a requirement by BPF and it mimics the default behaviour of the > clang BPF implementation. > > gcc/ChangeLog: >

Re: [patch] OpenMP: Add -Wopenmp and use it

On Fri, Nov 24, 2023 at 02:51:28PM +0100, Tobias Burnus wrote: > Following the general trend to add a "[-W...]" to the warning messages > for both better grouping of the warnings and - more importantly - for > providing > a means to silence such a warning (or to -Werror= them explicitly), this

Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()

On 23.11.23 18:29, Sebastian Huber wrote: On 23.11.23 09:20, Sebastian Huber wrote: On 23.11.23 09:11, Jiang, Haochen wrote: -Original Message- From: Sebastian Huber Sent: Wednesday, November 22, 2023 10:24 PM To: Christophe Lyon Cc: Jakub Jelinek;gcc-patches@gcc.gnu.org Subject: Re:

Re: GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves [PR112669]

On 24/11/2023 14:55, Thomas Schwinge wrote: Hi! On 2017-06-21T11:06:24+0100, Andrew Stubbs wrote: --- a/gcc/config/gcn/gcn.opt +++ b/gcc/config/gcn/gcn.opt +march= +Target RejectNegative Joined ToLower Enum(gpu_type) Var(gcn_arch) Init(PROCESSOR_CARRIZO) +Specify the name of the target

[committed] i386: Fix ICE with -fsplit-stack -mcmodel=large [PR112686]

For -mcmodel=large, we have to load function address to a register. PR target/112686 gcc/ChangeLog: * config/i386/i386.cc (ix86_expand_split_stack_prologue): Load function address to a register for ix86_cmodel == CM_LARGE. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112686.c:

[PATCH] PR tree-optimization/111922 - Ensure wi_fold arguments match precisions.

This problem here is that IPA is calling something like operator_minus with 2 operands, one with precision 32 (int) and one with precision 64 (pointer). There are various ways this can happen as mentioned in the PR. Regardless of whether IPA should be doing promoting types or not calling into

Re: [PATCH] arm: libgcc: provide implementations of __sync_synchronize

On 21/11/2023 16:06, Richard Earnshaw wrote: I'm going to hold off for 24 hours on this to give some chance for feedback before committing. Is using EXTRA_PARTS in this way acceptable? If not, what method would you recommend? Is there a better way of achieving this than using --defsym

Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

在 2023/11/24 下午6:30, Xi Ruoyao 写道: On Fri, 2023-11-24 at 17:46 +0800, chenglulu wrote: It's just that I'm confused that the description of rint in n2310, including Joseph's email, all say that rint will not set errno, but linux-man says "which might set errno to ERANGE" . Annex F has: The C

Re: [PATCH v2 5/5] aarch64: Add function multiversioning support

Andrew Carlotti writes: > This adds initial support for function multiversioning on aarch64 using > the target_version and target_clones attributes. This loosely follows > the Beta specification in the ACLE [1], although with some differences > that still need to be resolved (possibly as

[wwwdocs][patch][OpenACC] gcc-14/changes.html: OpenACC - mention support for first 2.7 features

Comments before I commit it? Current version: https://gcc.gnu.org/gcc-14/changes.html#general Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf;

Re: [wwwdocs][patch][OpenMP] gcc-14/changes.html + projects/gomp/: OpenMP update

On Fri, Nov 24, 2023 at 05:26:44PM +0100, Tobias Burnus wrote: > @@ -65,8 +72,11 @@ >was extended. Additionally, the spec change has been implemented for >default implicit mapping of C/C++ pointers pointing to unmapped > storage. > + The destory now optionally accepts the

GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves [PR112669] (was: [gcn][patch] Add -mgpu option and plumb in assembler/linker)

Hi! On 2017-06-21T11:06:24+0100, Andrew Stubbs wrote: > --- a/gcc/config/gcn/gcn.opt > +++ b/gcc/config/gcn/gcn.opt > +march= > +Target RejectNegative Joined ToLower Enum(gpu_type) Var(gcn_arch) > Init(PROCESSOR_CARRIZO) > +Specify the name of the target GPU. > + > +mtune= > +Target

Re: [PATCH] preprocessor: Reinitialize frontend parser after loading a PCH [PR112319]

On Wed, Nov 01, 2023 at 05:54:57PM -0400, Lewis Hyatt wrote: > Since r14-2893, the frontend parser object needs to exist when running in > preprocess-only mode, because pragma_lex() is now called in that mode and > needs to make use of it. This is handled by calling c_init_preprocess() at >

[wwwdocs][patch][OpenMP] gcc-14/changes.html + projects/gomp/: OpenMP update

While I expect more changes, I want to cleanup my stashed changes. Current version: https://gcc.gnu.org/gcc-14/changes.html#openmp Comments? Tobias PS: stack variable support in C++ for 'allocate' is pending review; I also expect a Fortran parser update for 'indirect'. Several more features

bpf: Throw error when external libcalls are generated.

Hi everyone, The attached patch is a temporary solution for the lack of proper linker and external library linking of the eBPF platform. Any calls created by the compiler, that would usually be defined within libgcc, will endup being undefined in bpftool, when GCC the compiled code is passed.

Re: [patch][GCN] install.texi: Update GCN entry - @uref and LLVM version remark

On 24/11/2023 16:07, Tobias Burnus wrote: Stumbled over this. I wondered whether we should recommend newlib >= 12e3bac3c (31st Oct 2023), but given that gfx1030 is not yet supported, I decided against it. We can revisit this once newlib 4.4 is available. This makes sense to me. We can

[PATCH] aarch64: Fix up aarch64_simd_stp [PR109977]

Hi! The aarch64_simd_stp pattern uses w constraint in one alternative and r in another, but for the latter incorrectly uses iterator in %1 which expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to the pattern) and %w1 for others, so it ICEs if the alternative is selected

[PATCH] c++/modules: alias CTAD and specializations table

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- A rewritten guide for alias CTAD isn't really a specialization of the original guide, so we shouldn't register it as such. This avoids an ICE in the below modules testcase which otherwise tries to inspect

[committed] c-family/c.opt (-Wopenmp): Add missing tailing '.'

Committed as r14-5835-g6eb1507107dee3 Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München,

[committed] hppa: Use INT14_OK_STRICT in a couple of places in pa_emit_move_sequence

This fixes a couple of places in pa_emit_move_sequence that should be using the INT14_OK_STRICT macro. Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- hppa: Use INT14_OK_STRICT in a couple of places in pa_emit_move_sequence 64-bit Linux target has relocation issue and can't use

Re: libstdc++: Speed up push_back

On Thu, 23 Nov 2023, Jonathan Wakely wrote: That's why we need -fsane-operator-new Although the standard forbids it, some of us just provide an inline implementation inline void* operator new(std::size_t n){return malloc(n);} inline void operator delete(void*p)noexcept{free(p);} inline

Re: [PATCH] c++: Implement P2582R1, CTAD from inherited constructors

On Wed, 22 Nov 2023, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? > > -- >8 -- > > This patch implements C++23 class template argument deduction from > inherited constructors, which is specified in terms of C++20 alias > CTAD which we

Re: libstdc++: Speed up push_back

> With my changes at -O3 we now inline push_back, so we could optimize the > first loop to the second. However with > ~/trunk-install/bin/gcc -O3 auto.C -S -fdump-tree-all-details > -fno-exceptions -fno-store-merging -fno-tree-slp-vectorize > the fist problem is right at the begining: > >

[PATCH] testsuite/gcc.dg/uninit-pred-9_b.c:20: Fix XPASS for various targets

While looking at the various targets, I found that the m32r target has two options implemented as opposites: -mbranch-cost=1 and -mbranch-cost=2, that have a bug that makes them yield their functionally opposite effect; i.e. -mbranch-cost=$arg, arg={1, 2} yields BRANCH_COST(x, y) 3-$arg. Anyway,