[PATCH] tree-optimization/113197 - bougs assert in PTA

PTA asserts that EAF_NO_DIRECT_READ is not set when flags are set consistently which doesn't make sense. The following removes the assert. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. PR tree-optimization/113197 * tree-ssa-structalias.cc (handle_call_arg): R

Re: [PATCH] libstdc++-v3: Fix signed-overflow warning for newlib/ctype_base.h, PR116895

On Mon, 30 Sept 2024, 01:58 Hans-Peter Nilsson, wrote: > FWIW, I see "typedef char mask;" also for bionic and > openbsd. Tested for cris-elf. > > Ok to commit? > OK thanks > -- >8 -- > There are 100+ regressions when running the g++ testsuite for newlib > targets (probably excepting ARM-base

Re: [PATCH] c++: Avoid "infinite parsing" because of cp_parser_decltype [PR114858]

Friendly ping. Thanks! On 17 Sep 2024, at 14:14, Simon Martin wrote: > The invalid test case in this PR highlights a bad interaction between > the tentative_firewall and error recovery in cp_parser_decltype: the > firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the > parser does

Re: [PATCH] arm: Fix missed CE optimization for armv8.1-m.main [PR 116444]

On Fri, Sep 27, 2024 at 2:11 PM Andre Vieira (lists) wrote: > > > > On 26/09/2024 18:56, Ramana Radhakrishnan wrote: > > > > >> +/* Helper function to determine whether SEQ represents a sequence of > >> + instructions representing the Armv8.1-M Mainline conditional arithmetic > >> + instruct

Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html again and also paging for Jan Hubicka, the x86 expert best regards, Julian

Re: [PATCH] RISC-V: Implement TARGET_CAN_INLINE_P

> On Sep 30, 2024, at 13:58, Kito Cheng wrote: > > Hi Yang-Yu: > >> >> Specially, we can reproduce the result on BananaPi-F3 Hardware: >> >> Use this GCC branch with my patch: >> https://github.com/cyyself/gcc/tree/rv_can_inline >> >> And compile the coremark on this branch: >> https://git

[PATCH] Fix crash with constant initializer

Hi, the attached Ada testcase compiled with -O2 -gnatn makes the compiler crash in vect_can_force_dr_alignment_p during SLP vectorization: if (decl_in_symtab_p (decl) && !symtab_node::get (decl)->can_increase_alignment_p ()) return false; because symtab_node::get (decl) returns a nu

[PATCH v4 0/4] tree-optimization/116024 - match.pd: add 4 int-compare simplifications

Hi, sending a v4 of https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663592.html with the following changes since v3: - Cleaned up the testcases in patches #1, #2, #4 by removing trivially dead initializers. - Added a !TYPE_UNSIGNED () check in patch #3 for clarity. - Removed the use of

[PATCH v4 2/4] tree-optimization/116024 - simplify C1-X cmp C2 for unsigned types

Implement a match.pd transformation inverting the sign of X in C1 - X cmp C2, where C1 and C2 are integer constants and X is of an unsigned type, by observing that: (a) If cmp is == or !=, simply move X and C2 to opposite sides of the comparison to arrive at X cmp C1 - C2. (b) If cmp is <:

[PATCH v4 1/4] tree-optimization/116024 - simplify C1-X cmp C2 for UB-on-overflow types

Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are integer constants and X is of a UB-on-overflow type. The pattern is simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the comparison (with opposite signs). If C1 - C2 happens to overflow, replace the whole expr

[PATCH v4 3/4] tree-optimization/116024 - simplify C1-X cmp C2 for wrapping signed types

Implement a match.pd transformation inverting the sign of X in C1 - X cmp C2, where C1 and C2 are integer constants and X is of a wrapping signed type, by observing that: (a) If cmp is == or !=, simply move X and C2 to opposite sides of the comparison to arrive at X cmp C1 - C2. (b) If cmp is <:

[PATCH v4 4/4] tree-optimization/116024 - simplify some cases of X +- C1 cmp C2

Whenever C1 and C2 are integer constants, X is of a wrapping type, and cmp is a relational operator, the expression X +- C1 cmp C2 can be simplified in the following cases: (a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial comparison in the following way: X +- C1 <= C2 -

Re: [Fortran, Patch, PR81265, v1] Fix passing coarrays always w/ descriptor

Hi Steve, thanks for the review. Committed as: gcc-15-3958-gbac95615b50 Thanks again, Andre On Fri, 27 Sep 2024 10:48:46 -0700 Steve Kargl wrote: > On Fri, Sep 27, 2024 at 03:20:43PM +0200, Andre Vehreschild wrote: > > > > attached patch fixes a runtime issue when a coarray was passed

[COMMITTED] Re: Re: [PATCH] RISC-V: Add an implicit dependency for Zawrs

2024-09-30 14:32  Kito Cheng wrote: > >LGTM, and let me know if you need my help to commit that :) Thank you, Kito. Recently, I received permission from Jeff. > >On Mon, Sep 30, 2024 at 9:37 AM Xiao Zeng wrote: >> >> There is a description in >>

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

* Richard Biener: >> + append (flags & SECTION_RELRO, "RELRO"); >> + append (flags & SECTION_EXCLUDE, "EXCLUDE"); >> + append (flags & SECTION_RETAIN, "RETAIN"); >> + append (flags & SECTION_LINK_ORDER, "LINK_ORDER"); > > I'm not sure printing these internal flags is of help to the user. Ther

[PATCH v2] x86/{,V}AES: adjust when to force EVEX encoding

Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly said "..., but we need to emit {evex} prefix in the assembly if AES ISA is not enabled". Yet it did so only for the TARGET_AES insns. Going from the alternative chosen in the TARGET_VAES insns isn't quite right: If AES is (als

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

* David Malcolm: > I'm not quite sure what you mean by "non-error" and "non-anchored".  Sorry, I'm not familiar with the appropriate terminology. > By "non-error", do you mean that this should this be a warning? If so, > use warning_at. You can use 0 for the option_id whilst prototyping. > Or

Re: [PATCH] lra: emit caller-save register spills before call insn [PR116028]

Hi! Sorry for replying late... On Sat, 10 Aug 2024 at 05:15, Andrew Pinski wrote: > > On Fri, Aug 9, 2024 at 8:11 PM Xi Ruoyao wrote: > > > > On Fri, 2024-08-09 at 17:55 -0400, Vladimir Makarov wrote: > > > > > Still, for GCC developer novice, I think it is important to test all > > > major ta

Re: [PATCH v2] c++: concept in default argument [PR109859]

On 9/27/24 5:30 PM, Marek Polacek wrote: On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote: On 9/18/24 5:06 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) We're hitting the assert in cp_parser_placeholder_type_specifier. It says th

Re: [PATCH 1/3] bpf: make sure CO-RE relocs are never typed with a BTF_KIND_CONST

On 9/27/24 09:49, Cupertino Miranda wrote: > Based on observation within bpf-next selftests and comparisson of GCC > and clang compiled code, the BPF loader expects all CO-RE relocations to > point to BTF non const type nodes. > --- > gcc/btfout.cc | 2 +- > gcc

[PATCH] libstdc++: Workaround glibc header on ia64-linux

We see: ``` FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) ``` ...on ia64-linux. This is due to: * /usr/include/bits/sigcontext.h:32-38: ``` 32

Re: [PATCH 2/2]AArch64: support encoding integer immediates using floating point moves

Tamar Christina writes: > Hi All, > > This patch extends our immediate SIMD generation cases to support generating > integer immediates using floating point operation if the integer immediate > maps > to an exact FP value. > > As an example: > > uint32x4_t f1() { > return vdupq_n_u32(0x3f8000

[PATCH] aarch64: Optimise calls to ldexp with SVE FSCALE instruction

This patch uses the FSCALE instruction provided by SVE to implement the standard ldexp family of functions. Currently, with '-Ofast -mcpu=neoverse-v2', GCC generates libcalls for the following code: float test_ldexpf (float x, int i) { return __builtin_ldexpf (x, i); } double test_ldexp

Patch ping Re: [PATCH] opts: Fix up regenerate-opt-urls dependencies

Hi! On Sat, Sep 21, 2024 at 07:43:25PM +0200, Jakub Jelinek wrote: > It seems that we currently require > 1) enabling at least c,c++,fortran,d in --enable-languages > 2) first doing make html > before one can successfully regenerate-opt-urls, otherwise without 2) > one gets > make regenerate-opt-u

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

On Mon, 2024-09-30 at 09:33 +0200, Florian Weimer wrote: > * David Malcolm: > > > I'm not quite sure what you mean by "non-error" and "non- > > anchored".  > > Sorry, I'm not familiar with the appropriate terminology. > > > By "non-error", do you mean that this should this be a warning?  If > >

Re: [PATCH] Fixup unaligned load/store cost for znver5

> Currently unaligned YMM and ZMM load and store costs are cheaper than > aligned which causes the vectorizer to purposely mis-align accesses > by adding an alignment prologue. It looks like the unaligned costs > were simply copied from the bogus znver4 costs. The following makes > the unaligned

[PATCH] tree-optimization/116566 - single lane SLP for VLA inductions

The following adds SLP support for vectorizing single-lane inductions with variable length vectors. This is a WIP patch, local testing for SVE and riscv is fine but the CI might discover issues. PR tree-optimization/116566 * tree-vect-loop.cc (vectorizable_induction): Handle singl

[pushed: r15-3971] diagnostics: fix memory leak in SARIF selftests

"make selftest-valgrind" was complaining about leaks of artifact objects in SARIF's selftest::test_make_location_object: -fself-test: 7638695 pass(es) in 89.999249 seconds ==3306525== ==3306525== HEAP SUMMARY: ==3306525== in use at exit: 1,215,639 bytes in 2,808 blocks ==3306525== total heap

[pushed: r15-3978] diagnostics: return text buffer from test_show_locus [PR116613]

As work towards supporting multiple diagnostic outputs (where each output has its own pretty_printer), avoid referencing dc.m_printer throughout the selftests of diagnostic-show-locus.cc. Instead have test_diagnostic_context::test_show_locus return the result buffer, hiding the specifics of which

[pushed: r15-3975] diagnostics: avoid using diagnostic_context's m_printer [PR116613]

As work towards supporting multiple diagnostic outputs (where each output has its own pretty_printer), avoid using diagnostic_context's m_printer field. Instead, use the output format's printer. Currently this *is* the dc's printer, but eventually it might not be. No functional change intended.

[pushed: r15-3972] diagnostics: fix typo in XHTML output [PR116792]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r15-3972-g3286b6724ec1d0. gcc/testsuite/ChangeLog: PR other/116792 * gcc.dg/plugin/diagnostic_plugin_xhtml_format.c: Fix stray reference to JSON. Signed-off-by: David Malcolm --- gcc/testsu

[pushed: r15-3974] diagnostics: use "%e" to avoid intermediate strings [PR116613]

Various diagnostics build an intermediate string, potentially with colorization, and then use this in a diagnostic message. This won't work if we have multiple diagnostic sinks, where some might be colorized and some not. This patch reworks such places using "%e" and pp_element subclasses, so tha

[pushed: r15-3973] diagnostics: add "dump" to pretty_printer and output_buffer

No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r15-3973-g4c7a58ac2617e2. gcc/ChangeLog: * pretty-print.cc (output_buffer::dump): New. (pretty_printer::dump): New. * pretty-print.h (output_buffer::dump): New

[pushed: r15-3976] diagnostics: isolate diagnostic_context with interface classes [PR116613]

As work towards supporting multiple diagnostic outputs (where each output has its own pretty_printer), avoid passing around diagnostic_context to the various printing routines, so that we can be more explicit about which pretty_printer is in use. Introduce a set of "policy" classes that capture th

[pushed: r15-3977] diagnostics: require callers of diagnostic_show_locus to be explicit about the printer [PR116613]

As work towards supporting multiple diagnostic outputs (where each output has its own pretty_printer), update diagnostic_show_locus so that the pretty_printer must always be explicitly passed in. No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed

Re: [PATCH] aarch64: Optimise calls to ldexp with SVE FSCALE instruction

Hi Soumya, Thank you for the patch. Two clarifications: In the instruction pattern's output string, why did you add the 'Z' prefix before operands? (%0 -> %Z0). Also, maybe you can make your test cases more precise by specifying which functions generate which instructions. I don't have and S

RE: [PATCH]middle-end: check explicitly for external or constants when checking for loop invariant [PR116817]

On Mon, 30 Sep 2024, Tamar Christina wrote: > > > > Can you explain how you get to see constant/external defs with > > astmt_vec_info? That's somehow a violation of some inherentinvariant in the > > vectorizer. > > > > > > I'm not sure I actually get any. It could be the condition is never hit >

[PATCH 2/2]AArch64: support encoding integer immediates using floating point moves

Hi All, This patch extends our immediate SIMD generation cases to support generating integer immediates using floating point operation if the integer immediate maps to an exact FP value. As an example: uint32x4_t f1() { return vdupq_n_u32(0x3f80); } currently generates: f1: adr

Re: [testcase] Fix absfloat16.c testcase

On 9/29/24 10:46 PM, Kugan Vivekanandarajah wrote: Hi, This patch Fixes absfloat16.c testcase to have the dg-add-options float16 at the correct order. Due to this mixup, this test is failing for some arm variants. Is this OK for trunk? OK jeff

[PATCH] middle-end: Fix ifcvt predicate generation for masked function calls

Up until now, due to a latent bug in the code for the ifcvt pass, irrespective of the branch taken in a conditional statement, the original condition for the if statement was used in masking the function call. Thus, for code such as: if (a[i] > limit) b[i] = fixed_const; else b[i] = f

Re: [PATCH 2/3] bpf: calls do not promote attr access_index on lhs

On 9/27/24 09:49, Cupertino Miranda wrote: > When traversing gimple to introduce CO-RE relocation entries to > expressions that are accesses to attributed perserve_access_index types, > the access is likely to be split in multiple gimple statments. > In order to keep doing the proper CO-RE conve

RE: [PATCH 2/2]AArch64: support encoding integer immediates using floating point moves

Thanks for the review, Will get started on it but one question... > -Original Message- > From: Richard Sandiford > Sent: Monday, September 30, 2024 6:33 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; ktkac...@gcc.gnu.org > Subject:

[PATCH v3] c++: concept in default argument [PR109859]

On Mon, Sep 30, 2024 at 10:53:04AM -0400, Jason Merrill wrote: > On 9/27/24 5:30 PM, Marek Polacek wrote: > > On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote: > > > On 9/18/24 5:06 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > >

Re: [PATCH 3/3] bpf: set index entry for a VAR_DECL in CO-RE relocs

On 9/27/24 09:49, Cupertino Miranda wrote: > CO-RE accesses with non pointer struct variables will also generate a > "0" string access within the CO-RE relocation. > The first index within the access string, has sort of a different > meaning then the remaining of the indexes. > For i0:i1:...:in

RE: [PATCH] i386: Add _MM_FROUND_TO_NEAREST_TIES_EVEN to smmintrin.h

Hi, I'm writing to ask that someone with write access to the git repo apply this patch, which provides the macro definition `_MM_FROUND_TO_NEAREST_TIES_EVEN`. Intrinsics such as `_mm512_add_round_ps` take a rounding mode argument to specify the floating point rounding mode. This and s

RE: [PATCH]middle-end: check explicitly for external or constants when checking for loop invariant [PR116817]

> > > Can you explain how you get to see constant/external defs with > astmt_vec_info? That's somehow a violation of some inherentinvariant in the > vectorizer. > > > > I'm not sure I actually get any. It could be the condition is never hit > > with a stmt_vec_info. I had assumed however since the

[PATCH 1/2]AArch64: refactor aarch64_float_const_representable_p to take additional mode param

Hi All, This is a refactoring to allow aarch64_float_const_representable_p to take an additional mode parameter which is the mode of the constant being analyzed. This will be required by the next patch in the series. No functional change is expected from this change. Bootstrapped Regtested on a

[PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

This implements the C++23 container adaptors std::flat_map and std::flat_multimap from P0429R9. The implementation is shared as much as possible between the two adaptors via a common base class that's parameterized according to key uniqueness. The main known issues are: * the range insert() ov

[PATCH 2/2] libstdc++: Implement C++23 (P1222R4)

This implements the C++23 container adaptors std::flat_set and std::flat_multiset from P1222R4. The implementation is essentially an simpler and pared down version of std::flat_map. The main known issues are: * exception safety is likely incomplete/buggy * unimplemented from_range_t construc

[PATCH v2] RISC-V: Implement TARGET_CAN_INLINE_P

Currently, we lack support for TARGET_CAN_INLINE_P on the RISC-V ISA. As a result, certain functions cannot be optimized with inlining when specific options, such as __attribute__((target("arch=+v"))) . This can lead to potential performance issues when building retargetable binaries for RISC-V. T

[PATCH] tree-optimization/116879 - failure to recognize non-empty latch

When we relaxed the vectorizers constraint on loop structure verifying the emptiness of the latch became too lose as can be seen in the case for PR116879 where the latch effectively contains two basic-blocks which one being an unmerged forwarder that's not empty. Bootstrapped and tested on x86_64-

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

Hi, I have now backported this patch to active branches (12 and 13). Honza

Re: Zen5 tuning part 1: avoid FMA chains

Hi, > > gcc/ChangeLog: > > * config/i386/x86-tune.def (X86_TUNE_AVOID_128FMA_CHAINS): Enable for > znver5. > (X86_TUNE_AVOID_256FMA_CHAINS): Likewise. > (X86_TUNE_AVOID_512FMA_CHAINS): Likewise. This patch is also now backported to active branches. Honza

Re: [PATCH v2] c++: Don't ICE due to artificial constructor parameters [PR116722]

On 9/23/24 4:44 AM, Simon Martin wrote: Hi Jason, On 20 Sep 2024, at 18:01, Jason Merrill wrote: On 9/20/24 5:21 PM, Simon Martin wrote: The following code triggers an ICE === cut here === class base {}; class derived : virtual public base { public: template constexpr derived(Arg) {} };

RE: [PATCH] middle-end: Fix ifcvt predicate generation for masked function calls

Hi Victor, Thanks! This looks good to me with one minor comment: > -Original Message- > From: Victor Do Nascimento > Sent: Monday, September 30, 2024 2:34 PM > To: gcc-patches@gcc.gnu.org > Cc: Tamar Christina ; richard.guent...@gmail.com; > Victor Do Nascimento > Subject: [PATCH] middl

[PATCH] phi-opt: Improve factor heurstic with constants and conversions from bool [PR116890]

Take: ``` if (t_3(D) != 0) goto ; else goto ; _8 = c_4(D) != 0; _9 = (int) _8; # e_2 = PHI <_9(3), 0(2)> ``` We should factor out the conversion here as that will allow a simplfication to `(t_3 != 0) & (c_4 != 0)`. Unlike most other types; `a ? b : CST` will simplify for

Re: [PATCH] c++: Avoid "infinite parsing" because of cp_parser_decltype [PR114858]

On 9/17/24 8:14 AM, Simon Martin wrote: The invalid test case in this PR highlights a bad interaction between the tentative_firewall and error recovery in cp_parser_decltype: the firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the parser does not make any progress, running "fore

Re: [PATCH v3] c++: concept in default argument [PR109859]

On Mon, Sep 30, 2024 at 03:02:39PM -0400, Jason Merrill wrote: > On 9/30/24 1:45 PM, Marek Polacek wrote: > > On Mon, Sep 30, 2024 at 10:53:04AM -0400, Jason Merrill wrote: > > > On 9/27/24 5:30 PM, Marek Polacek wrote: > > > > On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote: > > > >

Re: [PATCH v3] c++: concept in default argument [PR109859]

On 9/30/24 1:45 PM, Marek Polacek wrote: On Mon, Sep 30, 2024 at 10:53:04AM -0400, Jason Merrill wrote: On 9/27/24 5:30 PM, Marek Polacek wrote: On Fri, Sep 27, 2024 at 04:57:58PM -0400, Jason Merrill wrote: On 9/18/24 5:06 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gn

Re: [PATCH 3/4] rs6000, Remove redundant built-in __builtin_vsx_xvcvuxwdp

GCC maintainers: Here is my respnses to the review comments by Kewen.  Unfortunately, Kewen is no longer working on GCC power. I will submit an updated version of the patch with Kewen's suggested changes. Carl On 8/9/24 3:11 AM, Kewen.Lin wrote: rs600

Re: [PATCH 4/4] rs6000, Add tests and documentation for vector, conversions between integer and float

GCC maintainers: Here is my respnses to the review comments by Kewen.  Unfortunately, Kewen is no longer working on GCC power. I will submit an updated version of the patch with Kewen's suggested changes. Carl On 8/20/24 12:54 AM, Kewen.Lin wrote: Hi

Re: [PATCH 1/4] rs6000, add testcases to the overloaded vec_perm built-in

GCC maintainers: Here is my respnses to the review comments by Kewen.  Unfortunately, Kewen is no longer working on GCC power. I will submit an updated version of the patch with Kewen's suggested changes. Carl On 8/9/24 3:11 AM, Kewen.Lin wrote: Hi Car

Re: [PATCH 2/4] rs6000, remove built-ins __builtin_vsx_vperm_8hi and, __builtin_vsx_vperm_8hi_uns

GCC maintainers: Here is my respnses to the review comments by Kewen.  Unfortunately, Kewen is no longer working on GCC power. I will submit an updated version of the patch with Kewen's suggested changes. Carl On 8/9/24 3:11 AM, Kewen.Lin wrote: Hi Ca

[PATCH]middle-end: support SLP early break

Hi all, This patch introduces feature parity for early break int the SLP only vectorizer. The approach taken here is to treat the early exits as root statements for an SLP tree. This means that we don't need any changes to build_slp to support gconds. Codegen for the gcond itself now has to be

Re: [PATCH] aarch64: Optimise calls to ldexp with SVE FSCALE instruction

Hi Soumya > On 30 Sep 2024, at 18:26, Soumya AR wrote: > > External email: Use caution opening links or attachments > > > This patch uses the FSCALE instruction provided by SVE to implement the > standard ldexp family of functions. > > Currently, with '-Ofast -mcpu=neoverse-v2', GCC generates