Re: Re [PATCH v3] replace atoi with strtol in varasm.cc (decode_reg_name_and_count) [PR114540]

On Tue, Nov 26, 2024 at 06:51:40AM +0100, Heiko Eißfeldt wrote: > Would it make sense to have a nullptr check for asmspec at the > beginning, too? No. There is already if (asmspec != 0) around it which guarantees it and strip_reg_name will never return NULL. > diff --git a/gcc/varasm.cc b/gcc/v

Re [PATCH v3] replace atoi with strtol in varasm.cc (decode_reg_name_and_count) [PR114540]

Thanks for your feedback! On 11/23/24 11:02 PM, Jakub Jelinek wrote: On Sat, Nov 23, 2024 at 07:26:55PM +0100, Heiko Eißfeldt wrote: --- a/gcc/varasm.cc +++ b/gcc/varasm.cc @@ -993,9 +993,12 @@ decode_reg_name_and_count (const char *asmspec, int *pnregs) break; if (asmspec[0]

[PATCH] aarch64: Extend SVE2 bit-select instructions for Neon modes.

NBSL, BSL1N, and BSL2N are bit-select intructions on SVE2 with certain operands inverted. These can be extended to work with Neon modes. Since these instructions are unpredicated, duplicate patterns were added with the predicate removed to generate these instructions for Neon modes. The patch was

RE: [RFC] PR81358: Enable automatic linking of libatomic

> -Original Message- > From: Prathamesh Kulkarni > Sent: 19 November 2024 22:46 > To: Xi Ruoyao ; josmy...@redhat.com; Matthew > Malcomson ; gcc-patches@gcc.gnu.org > Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic > > External email: Use caution opening links or attac

[PATCH] c: special-case some "bool" errors with C23 [PR117629]

This patch attempts to provide better error messages for code compiled with C23 that hasn't been updated for "bool", "true", and "false" becoming keywords (based on a brief review of the Gentoo bug tracker links given at https://gcc.gnu.org/pipermail/gcc/2024-November/245185.html). Specifically:

[committed] c: Fix ICEs from invalid atomic compound assignment [PR98195, PR117755]

As reported in bug 98195, there are ICEs from an _Atomic compound assignment with an incomplete type on the RHS, arising from an invalid temporary being created with such a type. As reported in bug 117755, there are also (different) ICEs in cases with complete types where the binary operation itse

[PATCH v3] I386: Add more testcases for unsigned SAT_ADD vector pattern

From: Pan Li There are some forms like below failed to recog the SAT_ADD pattern for target i386. It is related to some match pattern extraction but get fixed after the refactor of the SAT_ADD pattern. Thus, add testcases to ensure we may have similar issue in futrue. #define DEF_SAT_ADD(T)

[PATCH 2/3] PR tree-optimization/117467 - Add a range query to inferred ranges.

This patch is also going to be needed by Jakub for his non-null work, I just foudn another use for it. hiis patch adds a range-query to the instantiation of an inferred range manager so that inferred range processing can make a range query.  THe follow on patch makes use of it to avoid registe

[PATCH 3/3] PR tree-optimization/117647 - Only add inferred ranges if they change the value.

Once an inferred range such as non-null has been registered, its a waste of time to register and apply them over and over. Pointers that are frequently used often are registered in each basic block as non-null.  This patch prevents them from being registered if a dominator block has already ind

[PATCH 1/3] tree-optimization/117467 - Do not calculate an entry range for invariant names.

A lot of time was being spent processing inferred ranges during a cache update.  Requesting the range of an argument during processing of inferred ranges was suppose to be cheap because they have already been calculated during folding, and so should just be available.  The problem demonstrated

Re: [PATCH] RISC-V: avlprop: Do not propagate VL from slidedown.

LGTM juzhe.zh...@rivai.ai From: Robin Dapp Date: 2024-11-25 22:39 To: gcc-patches CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com Subject: [PATCH] RISC-V: avlprop: Do not propagate VL from slidedown. Hi, in th

Re: [PATCH] Introduce feeble_inline attribute [PR93008]

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > This patch introduces a new attribute for weaker inline semantics (basically > it behaves as inline for the FE/debug info purposes, just for the > optimization decisions acts as if it wasn't explicitly inline); I haven't > used weak_inline for the attrib

RE: [committed] c: Default to -std=gnu23

On Mon, 25 Nov 2024, Jiang, Haochen wrote: > A quick question: Should we add this in gcc-wwwdocs porting doc or > somewhere else? The upgrade does cause some old code fail to compile > although it should fail. In general we should (collectively, by the time GCC 15 is out) update changes.html wit

Re: [PATCH 10/10] aarch64: Try to avoid passing new flags to assembler

Sorry for the slow review. Andrew Carlotti writes: > These new flags (+fcma, +jscvt, +rcpc2, +jscvt, +frintts, +wfxt and +xs) > were only recently added to the assembler. To improve compatibility > with older assemblers, we try to avoid passing these new flags to the > assembler if we can expres

[PATCH] libstdc++: Add conditional noexcept to range access functions

As an extension, this adds conditional noexcept to std::begin, std::end, and std::ssize. libstdc++-v3/ChangeLog: * include/bits/range_access.h (begin, end, ssize): Add conditional noexcept. * testsuite/18_support/initializer_list/range_access.cc: Check results and

[PATCH] libstdc++: Move std::error_category symbol to separate file [PR117630]

As described in PR 117630 the cow-stdexcept.cc file pulls in symbols from system_error.cc, which are not actually needed there. Moving the definition of error_category::_M_message to a separate file should solve it. libstdc++-v3/ChangeLog: PR libstdc++/117630 * src/c++11/Makefile.

[PUSHED] build: Move sstream include above safe-ctype.h {PR117771]

sstream in some versions of libstdc++ include locale which might not have been included yet. safe-ctype.h defines the toupper, tolower, etc. as macros so the c++ header files needed to be included before hand as comment in system.h says: /* Include C++ standard headers before "safe-ctype.h" to avoi

Re: [PATCH] Fortran: passing inquiry ref of complex array to assumed rank dummy [PR117774]

On Mon, Nov 25, 2024 at 10:05:49PM +, Harald Anlauf wrote: > Dear all, > > the attached patch fixes an ICE when passing an inquiry reference of a complex > array to an assumed-rank dummy argument by terminating the search for the > array reference before we hit the inquiry reference. (The arr

[PATCH] Fortran: passing inquiry ref of complex array to assumed rank dummy [PR117774]

Dear all, the attached patch fixes an ICE when passing an inquiry reference of a complex array to an assumed-rank dummy argument by terminating the search for the array reference before we hit the inquiry reference. (The array reference is needed for a possible descriptor update w.r.t. bounds.)

[committed] hppa: Revise TImode aritmetic patterns to support arith11_operands

Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- hppa: Revise TImode aritmetic patterns to support arith11_operands 2024-11-25 John David Anglin gcc/ChangeLog: PR target/117645 * config/pa/pa.md (addti3): Revise pattern to support arith11_operands. Use "

[PATCH] c++: ICE with nested anonymous union [PR117153]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- In a template, for union { union { T d; }; }; build_anon_union_vars crates a malformed COMPONENT_REF: we have no DECL_NAME for the nested anon union so we create something like "object.". Most of the front

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Hi Qing, Am Montag, dem 25.11.2024 um 17:40 + schrieb Qing Zhao: > Hi, Martin, > > I didn’t go through all the details of your patch. > > But I have one question: > > Did you consider the effect of the option -fstrict-flex-array > (https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/C-Dialect-

[pushed][PR117105][LRA]: Use unique value reload pseudo for early clobber operand

The following patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117105 The patch was successfully tested and bootstrapped on x86-64, ppc64le, aarch64. commit 4b09e2c67ef593db171b0755b46378964421782b Author: Vladimir N. Makarov Date: Mon Nov 25 16:09:00 2024 -0500 [PR117105][LRA]

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Hi Richard, here is another version. This now just ignores the size for all trailing arrays which I think is the right thing to do. It also modifies the lto hashing which also seems to work (but needs more testing and I haven't added tests to the patch yet). I also added back the missing comp

Re: [PATCH] c++: Implement C++26 P3176R1 - The Oxford variadic comma

On Mon, Nov 25, 2024 at 07:21:03PM +0100, Jakub Jelinek wrote: > Hi! > > While we are already in stage3, I wonder if implementing this small paper > wouldn't be useful even for GCC 15, so that we have in the GCC world one > extra year of deprecation of variadic ellipsis without preceding comma. >

Re: [PATCH] c++: Implement C++26 P3176R1 - The Oxford variadic comma

On Mon, 25 Nov 2024 at 18:22, Jakub Jelinek wrote: > > Hi! > > While we are already in stage3, I wonder if implementing this small paper > wouldn't be useful even for GCC 15, so that we have in the GCC world one > extra year of deprecation of variadic ellipsis without preceding comma. > > The pape

[PATCH v3] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

In this PR, we have to handle a case where MVE predicates are supplied as a const_int, where individual predicates have illegal boolean values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE, fix the constant (any non-zero value is converted to all 1s) and emit a warning. On MVE, V8

[committed]: i386: Generalize x >> 32-y to x >> -y conversion with multiples of 32

Optimize also cases where immediate value is a multiple of 32 for 32-bit shifts (or multiple of 64 for 64-bit shifts). gcc/ChangeLog: * config/i386/i386.md (*ashl3_negcnt): For SImode shifts allow multiples of 32 (or multiples of 64 for DImode shifts) for immediate operand 3. (*as

Re: [Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

Jerry D writes: > On 11/25/24 3:09 AM, Paul Richard Thomas wrote: >> Hi All, >> The breakage was caused by the patch for PR109345. As it happens, >> this part of the patch was not required to fix the PR and looked to >> be a considerable simplification of the condition. Although correct >> that a

Re: [committed]: i386: Generalize x >> 32-y to x >> -y conversion with multiples of 32

On Mon, Nov 25, 2024 at 08:08:58PM +0100, Uros Bizjak wrote: > Optimize also cases where immediate value is a multiple of 32 for 32-bit > shifts (or multiple of 64 for 64-bit shifts). > > gcc/ChangeLog: > > * config/i386/i386.md (*ashl3_negcnt): > For SImode shifts allow multiples of 32 (

[PUSHED] Regeernate .opt.urls after nios2 removal

The index markers changed slightly when nios2 were removed. This just regenerates the files. gcc/ChangeLog: * config/g.opt.urls: Regenerate. * config/i386/i386.opt.urls: Regenerate. * config/i386/nto.opt.urls: Regenerate. * config/nvptx/nvptx.opt.urls: Regenerate.

[PATCH] c++: Implement C++26 P3176R1 - The Oxford variadic comma

Hi! While we are already in stage3, I wonder if implementing this small paper wouldn't be useful even for GCC 15, so that we have in the GCC world one extra year of deprecation of variadic ellipsis without preceding comma. The paper just deprecates something, I'd hope most of the C++ code in the

[COMMITTED, wwwdocs] gcc-15: Document removal of Nios II back end

--- htdocs/gcc-15/changes.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 80604ab8..6c9ebaac 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@ -29,7 +29,9 @@ a work-in-progress. C

Re: [Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

On 11/25/24 3:09 AM, Paul Richard Thomas wrote: Hi All, The breakage was caused by the patch for PR109345. As it happens, this part of the patch was not required to fix the PR and looked to be a considerable simplification of the condition. Although correct that all is left are class dummies,

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Hi, Martin, I didn’t go through all the details of your patch. But I have one question: Did you consider the effect of the option -fstrict-flex-array (https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays) on how gcc treats the zero size trailing array,

Re: improve std::deque::_M_reallocate_map

On 24/11/24 16:26 +0100, Jan Hubicka wrote: Hi, looking into reason why we still do throw_bad_alloc in clang binary I noticed that quite few calls come from deque::_M_reallocate_map. This patch adds unreachable to limit the size of realloc_map. _M_reallocate_map is called only if new size is sm

Re: optimize basic_string

On 24/11/24 01:42 +0100, Jan Hubicka wrote: Hi, another common source of unnecesary throw_bad_alloc calls is basic_string::_M_create. basic_string<_CharT, _Traits, _Alloc>:: _M_create(size_type& __capacity, size_type __old_capacity) { // _GLIBCXX_RESOLVE_LIB_DEFECTS // 83. St

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 25 Nov 2024, Richard Biener wrote: > > The full `-msafe-bwa' feature is required for a fix, as the data race > > comes from *outside* rather than from any lack of atomicity of the store > > to the object itself. As the previous value of the object itself is > > discarded, a plain RMW

Re: [patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

Thanks Paul, got it. On Mon, Nov 25, 2024, 3:13 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > OK by me. > > A small nit: s/too/to/ in the ChangeLog. > > Thanks for the patch > > Paul > > > On Mon, 25 Nov 2024 at 02:50, Jerry D wrote: > >> I would like to commit t

Re: [PATCH] simplify-rtx: Limit number of elts in when encoding.

> Am 25.11.2024 um 15:36 schrieb Robin Dapp : > >  >> >> ...it's not clear to me that we should define the upper bits of the >> byte to be zero. What would rely on that? Is it something that we'd >> require for all loads and stores of such modes? Btw, we’ve been there on the tree level wit

Re: Fix type compatibility for types with flexible array member [PR113688, PR114014, PR117724]

> Am 25.11.2024 um 16:34 schrieb Martin Uecker : > > Am Montag, dem 25.11.2024 um 10:35 +0100 schrieb Richard Biener: >>> On Mon, 25 Nov 2024, Richard Biener wrote: >>> On Sat, 23 Nov 2024, Martin Uecker wrote: >>> This patch tries fixes the errors we have because of fle

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

Am Montag, dem 25.11.2024 um 10:35 +0100 schrieb Richard Biener: > On Mon, 25 Nov 2024, Richard Biener wrote: > > > On Sat, 23 Nov 2024, Martin Uecker wrote: > > > > > > > > This patch tries fixes the errors we have because of > > > flexible array members. I am bit unsure about the exception >

[PATCH] RISC-V: avlprop: Do not propagate VL from slidedown.

Hi, in the following situation (found in the rvv/autovec/vls-vlmax/shuffle-slide.c test which is not yet pushed) vsetivlizero,4,e8,mf4,ta,ma vle8.v v2,0(a1)# (1) vle8.v v1,0(a2)# (2) vsetivlizero,2,e

Re: [PATCH] simplify-rtx: Limit number of elts in when encoding.

> ...it's not clear to me that we should define the upper bits of the > byte to be zero. What would rely on that? Is it something that we'd > require for all loads and stores of such modes? Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's "balanced" mask representation i

[PATCH] target/116760 - 416.gamess slowdown with SLP

For the TWOTFF loop vectorization the backend scales constructor and vector extract cost to make higher VFs less profitable. This heuristic currently fails to consider VMAT_STRIDED_SLP which we now get with single-lane SLP, causing a huge regression in SPEC 2k6 416.gamess for the respective loop n

Re: [PATCH 00/15] aarch64: Add support for SVE2.1

Hi Richard > On 6 Nov 2024, at 18:16, Richard Sandiford wrote: > > This series adds support for FEAT_SVE2p1 (-march=...+sve2p1). > One thing that the extension does is make some SME and SME2 instructions > available outside of streaming mode. It also adds quite a few new > instructions. Some o

Re: [PATCH v2] sibcall: Check partial != 0 for BLKmode argument

"H.J. Lu" writes: > The outgoing stack slot size may be different from the BLKmode argument > size due to parameter alignment. Check partial != 0 for BLKmode argument > passed on stack. > > gcc/ > > PR middle-end/117098 > * calls.cc (store_one_arg): Check artial != 0 for BLKmode argum

Re: [PATCH] simplify-rtx: Limit number of elts in when encoding.

"Robin Dapp" writes: > Hi, > > this came up when testing even/odd permutes on riscv > (https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669181.html). > I didn't yet continue with the patch but it's clear it > exposes an issue with encoding vector masks. > > When we encode a vector mask with

Re: [PATCH v1] autoupdate: replace obsolete macros in libiberty

Matthieu Longo writes: > Autoreconf-2.72 warns about obsolete macros. This patch aims at removing > the noise from a future upgrade to autoreconf-2.72 or later. This is in > no a way a complete patch allowing the upgrade to autoreconf-2.72. > > - AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS > https

Re: [PATCH] [RFC] Add extra 64bit SSE vector epilogue in some cases

On Mon, 25 Nov 2024, Richard Biener wrote: > On Mon, 25 Nov 2024, Hongtao Liu wrote: > > > On Sun, Nov 24, 2024 at 8:05 PM Richard Biener wrote: > > > > > > > > > > > > > Am 24.11.2024 um 09:17 schrieb Hongtao Liu : > > > > > > > > On Fri, Nov 22, 2024 at 9:33 PM Richard Biener > > > > wrote:

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 25 Nov 2024, Maciej W. Rozycki wrote: > On Sat, 23 Nov 2024, Maciej W. Rozycki wrote: > > > I found no previous bug report, so this is now PR target/117759[1]. An > > obvious bug fix has been posted for review as well[2]. > > I gave this issue some thought as I travelled across Europ

Re: [Bug fortran/84869] [12/13/14/15 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

Hi Paul, commit r15-4610-gbf43fe6aa966ea initially added it, commit r15-5603-gb3f1b9e2aa079f removed it last Friday, so something might have got intermixed. I think you should remove it. If unsure, ask the authors of the above commits. Cheers, Harald Am 25.11.24 um 12:25 schrieb Paul Richard

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Sat, 23 Nov 2024, Maciej W. Rozycki wrote: > I found no previous bug report, so this is now PR target/117759[1]. An > obvious bug fix has been posted for review as well[2]. I gave this issue some thought as I travelled across Europe over the weekend and I have now withdrawn the proposed f

Re: [Bug fortran/84869] [12/13/14/15 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

Hi Harald, The pull said that the rebase was successful. Where that #define came from is a mystery to me. What do I do with it? Cheers Paul On Sun, 24 Nov 2024 at 21:26, Harald Anlauf wrote: > Am 24.11.24 um 17:40 schrieb Paul Richard Thomas: > > Fixed as 'obvious' on 13-branch to mainline w

Re: [PATCH] Alpha: Respect `_Atomic' keyword for HI and QI data on !BWX [PR117759]

On Sat, 23 Nov 2024, Maciej W. Rozycki wrote: > Correct an issue with 8-bit/16-bit stores to `_Atomic' QI and HI data > objects producing non-BWX assembly such as: > > mb > insql $17,$16,$17 > ldq_u $1,0($16) > mskwl $1,$16,$1 > bis $17,$1,$17 > stq_u $17,0($1

Re: [PATCH v2] I386: Add more testcases for unsigned SAT_ADD vector pattern

On Mon, Nov 25, 2024 at 12:13 PM Li, Pan2 wrote: > > > This doesn't look right, you need scan-tree-dump-times with tree dumps. > > Oh, yes, interesting the make check doesn't complain anything about it. > > Summaries valid vectorize cases as blow, is there anything missing? > > X86 uint8_t uint16_

Re: [committed] i386: x86 can use x >> -y for x >> 32-y [PR36503]

On Mon, Nov 25, 2024 at 12:10 PM Jakub Jelinek wrote: > > On Mon, Nov 25, 2024 at 11:52:31AM +0100, Uros Bizjak wrote: > > > Any reason for an exact comparison rather than > > > && (INTVAL (operands[3]) & ( * BITS_PER_UNIT - 1)) == 0 > > > ? > > > I mean, we can optimize this way 1U << (32 - x)

Re: [patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

Hi Jerry, OK by me. A small nit: s/too/to/ in the ChangeLog. Thanks for the patch Paul On Mon, 25 Nov 2024 at 02:50, Jerry D wrote: > I would like to commit the attached patch for Steve. > > Regression tested on x86-64-linux-gnu. > > OK for trunk? > > Author: Steve Kargl > Date: Sun Nov

RE: [PATCH v2] I386: Add more testcases for unsigned SAT_ADD vector pattern

> This doesn't look right, you need scan-tree-dump-times with tree dumps. Oh, yes, interesting the make check doesn't complain anything about it. Summaries valid vectorize cases as blow, is there anything missing? X86 uint8_t uint16_t X86_32 uint8_t, uint16_t, uint32_t X86_64 uint8_t, uint16_t,

Re: [committed] i386: x86 can use x >> -y for x >> 32-y [PR36503]

On Mon, Nov 25, 2024 at 11:52:31AM +0100, Uros Bizjak wrote: > > Any reason for an exact comparison rather than > > && (INTVAL (operands[3]) & ( * BITS_PER_UNIT - 1)) == 0 > > ? > > I mean, we can optimize this way 1U << (32 - x) or > > 1U << (1504 - x) or any other multiply of 32. > > Count val

[Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

Hi All, The breakage was caused by the patch for PR109345. As it happens, this part of the patch was not required to fix the PR and looked to be a considerable simplification of the condition. Although correct that all is left are class dummies, it caused the regression by not checking that it is

Re: [committed] i386: x86 can use x >> -y for x >> 32-y [PR36503]

On Mon, Nov 25, 2024 at 10:39 AM Jakub Jelinek wrote: > > On Sun, Nov 24, 2024 at 10:02:22PM +0100, Uros Bizjak wrote: > > PR target/36503 > > > > gcc/ChangeLog: > > > > * config/i386/i386.md (*ashl3_negcnt): > > New define_insn_and_split pattern. > > (*ashl3_negcnt_1): Ditto. > >

Re: optimize basic_string

Hi Honza, please CC the libstdc++ list on patches, thanks. On Sun, 24 Nov 2024 at 00:43, Jan Hubicka wrote: > > Hi, > another common source of unnecesary throw_bad_alloc calls is > basic_string::_M_create. > basic_string<_CharT, _Traits, _Alloc>:: > _M_create(size_type& __capacity, size_

Re: Rust: Work around 'error[E0658]: `let...else` statements are unstable'

Hi Thomas! Thanks, this patch (and your other one on the matter) looks good but I have a slight issue with it. We had previously done something similar to adapt to Rust 1.72 when we originally reused the format_args parser: https://github.com/Rust-GCC/gccrs/pull/2964 This was later reverted

[pushed] wwwdocs: readings: Update AVR entry

Remove Atmel and add a link to the avr-gcc Wiki, both as suggested by Georg-Johann Lay. Pushed. Gerald --- htdocs/readings.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index b5cbf414..103fd453 100644 --- a/htdocs/reading

Re: [PATCH] [RFC] Add extra 64bit SSE vector epilogue in some cases

On Mon, 25 Nov 2024, Hongtao Liu wrote: > On Sun, Nov 24, 2024 at 8:05 PM Richard Biener wrote: > > > > > > > > > Am 24.11.2024 um 09:17 schrieb Hongtao Liu : > > > > > > On Fri, Nov 22, 2024 at 9:33 PM Richard Biener wrote: > > >> > > >> Similar to the X86_TUNE_AVX512_TWO_EPILOGUES tuning whic

[PATCH] tree-optimization/117767 - VMAT_STRIDED_SLP and alignment

This plugs another hole in alignment checking with VMAT_STRIDED_SLP. When using an alternate load or store type we have to check whether that's supported with respect to required vector alignment. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/117767

Re: [PATCH] ifcombine: skip fallback conjunction on noncontiguous blocks

On Fri, 22 Nov 2024, Alexandre Oliva wrote: > > When everything else fails, if enabled by the target or by a > parameter, and when other requirements are satisfied, ifcombine > generates an AND of both conditions. > > That may be good for contiguous conditions, but it's unlikely to be an > optim

Re: [committed] i386: x86 can use x >> -y for x >> 32-y [PR36503]

On Sun, Nov 24, 2024 at 10:02:22PM +0100, Uros Bizjak wrote: > PR target/36503 > > gcc/ChangeLog: > > * config/i386/i386.md (*ashl3_negcnt): > New define_insn_and_split pattern. > (*ashl3_negcnt_1): Ditto. > (*3_negcnt): Ditto. > (*3_negcnt_1): Ditto. > > gcc/testsuite/Ch

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

On Mon, 25 Nov 2024, Richard Biener wrote: > On Sat, 23 Nov 2024, Martin Uecker wrote: > > > > > This patch tries fixes the errors we have because of > > flexible array members. I am bit unsure about the exception > > for the mode. > > > > Bootstrapped and regression tested on x86_64. > > >

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

On Sat, 23 Nov 2024, Martin Uecker wrote: > > This patch tries fixes the errors we have because of > flexible array members. I am bit unsure about the exception > for the mode. > > Bootstrapped and regression tested on x86_64. > > > > Fix type compatibility for types with flexible array

Re: [patch,avr] Adjust comment headers

On Mon, 18 Nov 2024, Georg-Johann Lay wrote: >> We also have >> >>AVR >>Manufacturer: Atmel >>> >> href="https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus";>AVR >>documentation >> >> >> in https://gcc.gnu.org/readings.html .

Re: [PATCH v2 10/14] Support for 64-bit location_t: gimple parts

On Sun, Nov 24, 2024 at 7:22 PM Hans-Peter Nilsson wrote: > > On Sat, 16 Nov 2024, Lewis Hyatt wrote: > > The size of struct gimple increases by 8 bytes with the change in size of > > location_t from 32- to 64-bit > > Half-way scrolling through the patches, this seems a good time > for a possibly

RE: [PATCH][ivopts]: perform affine fold to unsigned on non address expressions. [PR114932]

Ping > -Original Message- > From: Tamar Christina > Sent: Thursday, November 7, 2024 11:50 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de > Subject: [PATCH][ivopts]: perform affine fold to unsigned on non address > expressions. [PR114932] > > Hi All, > > When the patch fo

Re: [PATCH v2] I386: Add more testcases for unsigned SAT_ADD vector pattern

On Mon, Nov 25, 2024 at 3:27 AM wrote: > > From: Pan Li > > Update in v2: > > * Skip lto build as no such dump files. > * scan dump check for optimized. > > Original log: > > There are some forms like below failed to recog the SAT_ADD > pattern for target i386. It is related to some match patter

RE: [PATCH 1/2]middle-end: refactor type to be explicit in operand_equal_p [PR114932]

ping > -Original Message- > From: Tamar Christina > Sent: Tuesday, November 5, 2024 9:04 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 1/2]middle-end: refactor type to be explicit in > operand_equal_p [PR114932] > > ping > > >

RE: [PATCH 2/2]middle-end: use two's complement equality when comparing IVs during candidate selection [PR114932]

ping > -Original Message- > From: Tamar Christina > Sent: Tuesday, November 5, 2024 9:04 AM > To: gcc-patches@gcc.gnu.org > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com > Subject: RE: [PATCH 2/2]middle-end: use two's complement equality when > comparing IVs during candidate selection