[PATCH v3] vect: Recog mul_highpart pattern

on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: > on 2021/7/14 下午2:38, Richard Biener wrote: >> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote: >>> >>> on 2021/7/13 下午8:42, Richard Biener wrote: On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote: >> >>> I guess the proposed IFN would be

Re: [PATCH v3] vect: Recog mul_highpart pattern

On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: > > on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: > > on 2021/7/14 下午2:38, Richard Biener wrote: > >> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote: > >>> > >>> on 2021/7/13 下午8:42, Richard Biener wrote: > On Tue, Jul 13, 2021 at 12:

Re: [PATCH] handle vector and aggregate stores in -Wstringop-overflow [PR 97027]

On Wed, Jul 14, 2021 at 8:46 PM Martin Sebor wrote: > > On 7/14/21 1:01 AM, Richard Biener wrote: > > On Tue, Jul 13, 2021 at 9:27 PM Martin Sebor via Gcc-patches > > wrote: > >> > >> An existing, previously xfailed test that I recently removed > >> the xfail from made me realize that -Wstringop-

Re: [PATCH V2] Use preferred mode for doloop iv [PR61837].

> On 15 Jul 2021, at 06:09, guojiufu via Gcc-patches > wrote: > > On 2021-07-15 02:04, Segher Boessenkool wrote: > >>> +@deftypefn {Target Hook} machine_mode TARGET_PREFERRED_DOLOOP_MODE >>> (machine_mode @var{mode}) >>> +This hook takes a @var{mode} which is the original mode of doloop IV.

Re: [pushed] c++: enable -fdelete-dead-exceptions by default

On Wed, 14 Jul 2021, Jason Merrill wrote: > As I was discussing with richi, I don't think it makes sense to protect > calls to pure/const functions from DCE just because they aren't explicitly > declared noexcept. PR100382 indicates that there are different > considerations for Go, which has non-

Re: [llvm-dev] [PATCH 0/2] Initial support for AVX512FP16

On Thu, Jul 15, 2021 at 2:58 PM Wang, Pengfei wrote: > > It seems Clang doesn't support -fexcess-precision=xxx: > https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/clang_f_opts.c#L403 > > Thanks > Pengfei > > -Original Message- > From: Hongtao Liu > Sent: Thursday, July 15,

[PATCH] c++: Optimize away NULLPTR_TYPE comparisons [PR101443]

Hi! Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the middle-end and in fold-const.c, various optimizations assume that if they see e.g. a non-equality comparison with one of the operands being INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE), they c

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Jul 14, 2021 at 4:10 PM Qing Zhao wrote: > > Hi, Richard, > > > On Jul 14, 2021, at 2:14 AM, Richard Biener > > wrote: > > > > On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote: > >> > >> Hi, Kees, > >> > >> I took a look at the kernel testing case you attached in the previous > >> email

Re: [PATCH] Remove legacy external declarations in toplev.h [PR101447]

On Thu, Jul 15, 2021 at 3:54 AM ashimida via Gcc-patches wrote: > > > External declarations in ./gcc/toplev.h is no longer used in newest > version of gcc and should be cleaned up to avoid misunderstandings. OK > gcc/ChangeLog: > > * toplev.h (set_random_seed): > > --- > diff --git a/gc

Re: [PATCH 1/4] force decls to be allocated through build_decl to initialize them

On Thu, Jul 15, 2021 at 4:24 AM Trevor Saunders wrote: > > On Wed, Jul 14, 2021 at 01:27:54PM +0200, Richard Biener wrote: > > On Wed, Jul 14, 2021 at 10:20 AM Trevor Saunders > > wrote: > > > > > > prior to this commit all calls to build_decl used input_location, even if > > > temporarily unti

[PATCH] gimplify: Fix endless recursion on volatile empty type reads/writes [PR101437]

Hi! Andrew's recent change to optimize away during gimplification not just assignments of zero sized types, but also assignments of empty types, caused infinite recursion in the gimplifier. If such assignment is optimized away, we gimplify separately the to_p and from_p operands and throw away the

Re: [PATCH v3] vect: Recog mul_highpart pattern

Hi Uros, on 2021/7/15 下午3:17, Uros Bizjak wrote: > On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: >> >> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: >>> on 2021/7/14 下午2:38, Richard Biener wrote: On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote: > > on 2021/7/13 下午8:42, Ri

Re: [pushed] c++: fix tree_contains_struct for C++ types [PR101095]

On Thu, Jul 15, 2021 at 5:19 AM Jason Merrill via Gcc-patches wrote: > > Many of the types from cp-tree.def were only marked as having tree_common, > when actually most of them have type_non_common. This broke > g++.dg/modules/xtreme-header-2, as the modules code relies on > tree_contains_struct

Re: [PATCH V2] Use preferred mode for doloop iv [PR61837].

Iain Sandoe writes: On 15 Jul 2021, at 06:09, guojiufu via Gcc-patches wrote: On 2021-07-15 02:04, Segher Boessenkool wrote: +@deftypefn {Target Hook} machine_mode TARGET_PREFERRED_DOLOOP_MODE (machine_mode @var{mode}) +This hook takes a @var{mode} which is the original mode of doloop

Re: [PATCH] gimplify: Fix endless recursion on volatile empty type reads/writes [PR101437]

On Thu, 15 Jul 2021, Jakub Jelinek wrote: > Hi! > > Andrew's recent change to optimize away during gimplification not just > assignments of zero sized types, but also assignments of empty types, > caused infinite recursion in the gimplifier. > If such assignment is optimized away, we gimplify sep

Re: [PATCH v3] vect: Recog mul_highpart pattern

On Thu, Jul 15, 2021 at 10:04 AM Kewen.Lin wrote: > > Hi Uros, > > on 2021/7/15 下午3:17, Uros Bizjak wrote: > > On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: > >> > >> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: > >>> on 2021/7/14 下午2:38, Richard Biener wrote: > On Tue, Jul 13, 2

Re: [PATCH V2] Use preferred mode for doloop iv [PR61837].

On 2021-07-15 14:06, Richard Biener wrote: On Tue, 13 Jul 2021, Jiufu Guo wrote: Major changes from v1: * Add target hook to query preferred doloop mode. * Recompute doloop iv base from niter under preferred mode. Currently, doloop.xx variable is using the type as niter which may shorter than

Re: [PATCH libatomic/arm] avoid warning on constant addresses (PR 101379)

Hi, On Sat, Jul 10, 2021 at 1:11 AM Martin Sebor via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > The attached tweak avoids the new -Warray-bounds instances when > building libatomic for arm. Christophe confirms it resolves > the problem (thank you!) > > As we have discussed, the main goal of

Re: [PATCH][AArch32]: Correct sdot RTL on aarch32

Hi Tamar, On Tue, May 25, 2021 at 5:41 PM Tamar Christina via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > Hi All, > > The RTL Generated from dot_prod is invalid as operand3 cannot > be > written to, it's a normal input. For the expand it's just another operand > but the caller does not expe

Re: [PATCH v3] vect: Recog mul_highpart pattern

on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote: > Hi Uros, > > on 2021/7/15 下午3:17, Uros Bizjak wrote: >> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: >>> >>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: on 2021/7/14 下午2:38, Richard Biener wrote: > On Tue, Jul 13, 2021

Re: [PATCH v3] vect: Recog mul_highpart pattern

on 2021/7/15 下午4:23, Uros Bizjak wrote: > On Thu, Jul 15, 2021 at 10:04 AM Kewen.Lin wrote: >> >> Hi Uros, >> >> on 2021/7/15 下午3:17, Uros Bizjak wrote: >>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: > on 2021/7/14 下午2:38,

Re: [PATCH V2] gcc: Add vec_select -> subreg RTL simplification

On Mon, Jul 12, 2021 at 5:31 PM Richard Sandiford via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > Jonathan Wright writes: > > Hi, > > > > Version 2 of this patch adds more code generation tests to show the > > benefit of this RTL simplification as well as adding a new helper > function > > 'r

Re: [ARM] PR66791: Replace builtins for fp and unsigned vmul_n intrinsics

Hi Prathamesh, On Mon, Jul 5, 2021 at 11:25 AM Kyrylo Tkachov via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > > > -Original Message- > > From: Prathamesh Kulkarni > > Sent: 05 July 2021 10:18 > > To: gcc Patches ; Kyrylo Tkachov > > > > Subject: [ARM] PR66791: Replace builtins for

Re: [PATCH v3] vect: Recog mul_highpart pattern

V čet., 15. jul. 2021 10:49 je oseba Kewen.Lin napisala: > on 2021/7/15 下午4:23, Uros Bizjak wrote: > > On Thu, Jul 15, 2021 at 10:04 AM Kewen.Lin wrote: > >> > >> Hi Uros, > >> > >> on 2021/7/15 下午3:17, Uros Bizjak wrote: > >>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: > > on 2

[PATCH V3] Use preferred mode for doloop IV [PR61837]

Refine code for V2 according to review comments: * Use if check instead assert, and refine assert * Use better RE check for test case, e.g. (?n)/(?p) * Use better wording for target.def Currently, doloop.xx variable is using the type as niter which may be shorter than word size. For some targets,

[PATCH 1/2] Streamline vect_gen_while

This adjusts the vect_gen_while API to match that of vect_gen_while_not allowing further patches to generate more than one stmt for the while case. Bootstrapped and tested on x86_64-unknown-linux-gnu, tested a toy example on SVE that it still produces the same code. OK? 2021-07-15 Richard Biene

[PATCH 2/2][RFC] Add loop masking support for x86

The following extends the existing loop masking support using SVE WHILE_ULT to x86 by proving an alternate way to produce the mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage you can now enable masked vectorized epilogues (=1) or fully masked vector loops (=2). What's missing

Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.

Hi! On 2021-07-02T09:15:27+0200, Richard Biener via Gcc-patches wrote: > On Thu, Jul 1, 2021 at 5:17 PM Hafiz Abid Qadeer > wrote: >> >> Currently, if we look at the debug information for offload kernel >> regions, it looks something like this: >> >> void foo (void) >> { >> #pragma acc kernels

Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.

On 15/07/2021 11:33, Thomas Schwinge wrote: > >> Note that the "parent" should be abstract but I don't think dwarf has a >> way to express a fully abstract parent of a concrete instance child - or >> at least how GCC expresses this causes consumers to "misinterpret" >> that. I wonder if adding a

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, Jul 15, 2021 at 12:30 PM Richard Biener wrote: > > The following extends the existing loop masking support using > SVE WHILE_ULT to x86 by proving an alternate way to produce the > mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage > you can now enable masked vectorized

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

Well, if we don't adjust gimple_call_return_type() to handle built-ins with no LHS, then we must adjust the callers. The attached patch fixes gimple_expr_type() per it's documentation: /* Return the type of the main expression computed by STMT. Return void_type_node if the statement computes

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches wrote: > > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener wrote: > > > > The following extends the existing loop masking support using > > SVE WHILE_ULT to x86 by proving an alternate way to produce the > > mask using VEC_COND_EXPRs.

Re: [ARM] PR66791: Replace builtins for fp and unsigned vmul_n intrinsics

On Thu, 15 Jul 2021 at 14:47, Christophe Lyon wrote: > > Hi Prathamesh, > > On Mon, Jul 5, 2021 at 11:25 AM Kyrylo Tkachov via Gcc-patches > wrote: >> >> >> >> > -Original Message- >> > From: Prathamesh Kulkarni >> > Sent: 05 July 2021 10:18 >> > To: gcc Patches ; Kyrylo Tkachov >> > >

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, 15 Jul 2021, Hongtao Liu wrote: > On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches > wrote: > > > > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener wrote: > > > > > > The following extends the existing loop masking support using > > > SVE WHILE_ULT to x86 by proving an alte

Re: [PATCH v3] vect: Recog mul_highpart pattern

On Thu, Jul 15, 2021 at 10:41 AM Kewen.Lin wrote: > > on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote: > > Hi Uros, > > > > on 2021/7/15 下午3:17, Uros Bizjak wrote: > >> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote: > >>> > >>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote: > o

Re: [PATCH] [DWARF] Fix hierarchy of debug information for offload kernels.

On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer wrote: > > On 15/07/2021 11:33, Thomas Schwinge wrote: > > > >> Note that the "parent" should be abstract but I don't think dwarf has a > >> way to express a fully abstract parent of a concrete instance child - or > >> at least how GCC expresses t

[PUSHED] Abstract out non_null adjustments in ranger.

There are 4 exact copies of the non-null range adjusting code in the ranger. This patch abstracts the functionality into a separate method. As a follow-up I would like to remove the varying_p check, since I have seen incoming ranges such as [0, 0xffef] which are not varying, but are not-null.

[PATCH v3] c++: Add gnu::diagnose_as attribute

Hi Jason, A new revision of the patch is attached. I think I implemented all your suggestions. Please comment on cp/decl2.c (is_alias_template_p). I find it surprising that I had to write this function. Maybe I missed something? In any case, DECL_ALIAS_TEMPLATE_P requires a template_decl and t

Re: [PATCH] Support reduction def re-use for epilogue with different vector size

Hi, On Tue, Jul 13, 2021 at 2:09 PM Richard Biener wrote: > The following adds support for re-using the vector reduction def > from the main loop in vectorized epilogue loops on architectures > which use different vector sizes for the epilogue. That's only > x86 as far as I am aware. > > vect

[PATCH] Disable --param vect-partial-vector-usage by default on x86

The following defaults --param vect-partial-vector-usage to zero for x86_64 matching existing behavior where support for this is not present. OK for trunk? Thanks, Richard/ 2021-07-15 Richard Biener * config/i386/i386-options.c (ix86_option_override_internal): Set param_vect_

Re: [PATCH] Support reduction def re-use for epilogue with different vector size

On Thu, 15 Jul 2021, Christophe Lyon wrote: > Hi, > > > > On Tue, Jul 13, 2021 at 2:09 PM Richard Biener wrote: > > > The following adds support for re-using the vector reduction def > > from the main loop in vectorized epilogue loops on architectures > > which use different vector sizes for

Re: GCC 11.1.1 Status Report (2021-07-06)

On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote: > > > Status > == > > The GCC 11 branch is open for regression and documentation fixes. > It's time for a GCC 11.2 release and we are aiming for a release > candidate in about two weeks which would result in the GCC 11.2 > release about thr

Re: GCC 11.1.1 Status Report (2021-07-06)

On Thu, 15 Jul 2021, H.J. Lu wrote: > On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote: > > > > > > Status > > == > > > > The GCC 11 branch is open for regression and documentation fixes. > > It's time for a GCC 11.2 release and we are aiming for a release > > candidate in about two weeks

Re: [PATCH 1/2] Streamline vect_gen_while

Richard Biener writes: > This adjusts the vect_gen_while API to match that of > vect_gen_while_not allowing further patches to generate more > than one stmt for the while case. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, tested a > toy example on SVE that it still produces the same co

testsuite: aarch64: Fix failing SVE tests on big endian

Hi, A recent change "gcc: Add vec_select -> subreg RTL simplification" updated the expected test results for SVE extraction tests. The new result should only have been changed for little endian. This patch restores the old expected result for big endian. Ok for master? Thanks, Jonathan --- gcc

[PATCH] arm: Fix multilib mapping for CDE extensions [PR100856]

This is a followup to Srinath's recent patch: the newly added test is failing e.g. on arm-linux-gnueabihf without R/M profile multilibs. It is also failing on arm-eabi with R/M profile multilibs if the execution engine does not support v8.1-M instructions. The patch avoids this by adding check_e

RE: [PATCH][AArch32]: Correct sdot RTL on aarch32

Hi Christophe, Sorry about that, the ICEs should be fixed now and the execution tests are being fixed now. They were being hidden by a model bug which kept saying everything passed even when failed ☹ Regards, Tamar From: Christophe Lyon Sent: Thursday, July 15, 2021 9:39 AM To: Tamar Christi

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote: > > Well, if we don't adjust gimple_call_return_type() to handle built-ins > with no LHS, then we must adjust the callers. > > The attached patch fixes gimple_expr_type() per it's documentation: > > /* Return the type of the main expression com

Re: [PATCH V2] gcc: Add vec_select -> subreg RTL simplification

Ah, yes - those test results should have only been changed for little endian. I've submitted a patch to the list restoring the original expected results for big endian. Thanks, Jonathan From: Christophe Lyon Sent: 15 July 2021 10:09 To: Richard Sandiford ; Jonat

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

On 7/15/21 3:06 PM, Richard Biener wrote: On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote: Well, if we don't adjust gimple_call_return_type() to handle built-ins with no LHS, then we must adjust the callers. The attached patch fixes gimple_expr_type() per it's documentation: /* Retur

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote: > > > > On 7/15/21 3:06 PM, Richard Biener wrote: > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote: > >> > >> Well, if we don't adjust gimple_call_return_type() to handle built-ins > >> with no LHS, then we must adjust the callers. > >

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

On Thu, Jul 15, 2021 at 3:21 PM Richard Biener wrote: > > On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote: > > > > > > > > On 7/15/21 3:06 PM, Richard Biener wrote: > > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez wrote: > > >> > > >> Well, if we don't adjust gimple_call_return_type() t

Re: [RFC] Return NULL from gimple_call_return_type if no return available.

On Thu, Jul 15, 2021 at 3:23 PM Richard Biener wrote: > > On Thu, Jul 15, 2021 at 3:21 PM Richard Biener > wrote: > > > > On Thu, Jul 15, 2021 at 3:16 PM Aldy Hernandez wrote: > > > > > > > > > > > > On 7/15/21 3:06 PM, Richard Biener wrote: > > > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez

[PATCH] Add --enable-first-stage-cross configure option

Add --enable-first-stage-cross configure option Build static-only, C-only compiler that is sufficient to cross compile glibc. This option disables various runtime libraries that require libc to compile, turns on --with-newlib, --without-headers, --disable-decimal-float, --disable-shared, --disabl

Re: [PATCH] c++: Optimize away NULLPTR_TYPE comparisons [PR101443]

On 7/15/21 3:53 AM, Jakub Jelinek wrote: Hi! Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the middle-end and in fold-const.c, various optimizations assume that if they see e.g. a non-equality comparison with one of the operands being INTEGER_CST and it is not INTEGRAL_TYPE

Re: [PATCH 2/2][RFC] Add loop masking support for x86

Richard Biener writes: > The following extends the existing loop masking support using > SVE WHILE_ULT to x86 by proving an alternate way to produce the > mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage > you can now enable masked vectorized epilogues (=1) or fully > masked v

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, 15 Jul 2021, Richard Sandiford wrote: > Richard Biener writes: > > The following extends the existing loop masking support using > > SVE WHILE_ULT to x86 by proving an alternate way to produce the > > mask using VEC_COND_EXPRs. So with --param vect-partial-vector-usage > > you can now en

Re: rs6000: Generate an lxvp instead of two adjacent lxv instructions

On 7/14/21 4:12 PM, Peter Bergner wrote: > I'll make the change above and rebuild just to be safe and then commit. Regtesting was clean as expected, so I pushed the commit to trunk. Thanks. Is this ok for backporting to GCC 11 after a day or two on trunk? Given GCC 10 doesn't have the opaque mod

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, > On Jul 15, 2021, at 2:56 AM, Richard Biener > wrote: > >>> On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote: Hi, Kees, I took a look at the kernel testing case you attached in the previous email, and found the testing failed with the following case: >>

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jul 15, 2021, at 9:16 AM, Qing Zhao via Gcc-patches > wrote: > >> Note that I think .DEFERRED_INIT can be elided for variables that do not have their address taken - otherwise we'll also have to worry about aggregate copy initialization and SRA decomposing

Re: [PATCH 1/2] Implement basic block path solver.

Jeff has mentioned that it'll take a while longer to review the threader rewrite, so I've decided to make some minor cleanups while he gets to it. There are few minor changes here: 1. I've renamed the solver to gimple-range-path.* which expresses better that it's part of the ranger tools. The pre

Re: [PATCH 2/2][RFC] Add loop masking support for x86

Richard Biener writes: > On Thu, 15 Jul 2021, Hongtao Liu wrote: > >> On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches >> wrote: >> > >> > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener wrote: >> > > >> > > The following extends the existing loop masking support using >> > > SVE W

Re: [PATCH 2/2] Backwards jump threader rewrite with ranger.

As mentioned in my previous email, these are some minor changes to the previous revision. All I'm changing here is the call into the solver to use range_of_expr and range_of_stmt. Everything else remains the same. Tested on x86-64 Linux. On Mon, Jul 5, 2021 at 5:39 PM Aldy Hernandez wrote: > >

RFA: Libiberty: Fix stack exhaunstion demangling corrupt rust names

Hi Guys, Attached is a proposed patch to fix PR 99935 and 100968, both of which are stack exhaustion problems in libiberty's Rust demangler. The patch adds a recursion limit along the lines of the one already in place for the C++ demangler. OK to apply ? Cheers Nick diff --git a/li

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, 15 Jul 2021, Richard Sandiford wrote: > Richard Biener writes: > > On Thu, 15 Jul 2021, Hongtao Liu wrote: > > > >> On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches > >> wrote: > >> > > >> > On Thu, Jul 15, 2021 at 12:30 PM Richard Biener > >> > wrote: > >> > > > >> > > T

[PATCH] Change the type of return value of profile_count::value to uint64_t

Hi, The field in which profile_count holds the count has 61 bits but the getter method only returns it as a 32 bit number. The getter is (and should be) only used for dumping but even dumps are better when they do not lie. The patch has passed bootstrap and testing on x86_64-linux and Honza has

Re: [PATCH] Support reduction def re-use for epilogue with different vector size

On Thu, Jul 15, 2021 at 2:34 PM Richard Biener wrote: > On Thu, 15 Jul 2021, Christophe Lyon wrote: > > > Hi, > > > > > > > > On Tue, Jul 13, 2021 at 2:09 PM Richard Biener > wrote: > > > > > The following adds support for re-using the vector reduction def > > > from the main loop in vectorized

[PATCH, committed] rs6000: Don't let swaps pass break multiply low-part (PR101129)

Hi, Segher preapproved this patch in https://gcc.gnu.org/PR101129. It differs slightly from what was posted there, needing an additional test to ensure the insn is a SET.  The patch also includes the test case provided by the OP.  Bootstrap and regtest succeeded on P9 little-endian. This bug

Re: [PATCH v2] docs: Add 'S' to Machine Constraints for RISC-V

On Sun, 11 Jul 2021 21:29:13 PDT (-0700), kito.ch...@sifive.com wrote: It was undocument before, but it might used in linux kernel for resolve code model issue, so LLVM community suggest we should document that, so that make it become supported/documented/non-internal machine constraints. gcc/Ch

[committed] libstdc++: Add noexcept to __replacement_assert [PR101429]

This results in slightly smaller code when assertions are enabled when either using Clang (because it adds code to call std::terminate when potentially-throwing functions are called in a noexcept function) or a freestanding or non-verbose build (because it doesn't use printf). Signed-off-by: Jonat

[committed] libstdc++: Fix std::get for std::tuple [PR101427]

The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the implementation of std::get to explicitly check for mor

Re: [committed] libstdc++: Fix std::get for std::tuple [PR101427]

On 15/07/21 16:26 +0100, Jonathan Wakely wrote: The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the impl

Re: [PATCH, committed] rs6000: Don't let swaps pass break multiply low-part (PR101129)

On Thu, Jul 15, 2021 at 11:25 AM Bill Schmidt wrote: > > Hi, > > Segher preapproved this patch in https://gcc.gnu.org/PR101129. It differs > slightly from what was posted there, needing an additional test to ensure the > insn is a SET. The patch also includes the test case provided by the OP.

Re: [PATCH 2/2][RFC] Add loop masking support for x86

On Thu, 15 Jul 2021, Richard Biener wrote: > On Thu, 15 Jul 2021, Richard Sandiford wrote: > > > Richard Biener writes: > > > On Thu, 15 Jul 2021, Hongtao Liu wrote: > > > > > >> On Thu, Jul 15, 2021 at 6:45 PM Richard Biener via Gcc-patches > > >> wrote: > > >> > > > >> > On Thu, Jul 15, 2021

[PATCH 1/2] testsuite: [arm] Add missing effective-target to vusdot-autovec.c

This test fails when forcing an -mcpu option incompatible with -march=armv8.2-a+i8mm. This patch adds the missing arm_v8_2a_i8mm_ok effective-target, as well as the associated dg-add-options arm_v8_2a_i8mm. 2021-07-15 Christophe Lyon gcc/testsuite/ * gcc.target/arm/simd/vusdot

[PATCH 2/2] testsuite: [arm] Remove arm_v8_2a_imm8_neon_ok_nocache

This patch removes this recently-introduced effective-target, as it looks like a typo and duplicate for arm_v8_2a_i8mm_ok (imm8 vs i8mm), and it is not used. 2021-07-15 Christophe Lyon gcc/testsuite/ * lib/target-supports.exp (arm_v8_2a_imm8_neon_ok_nocache): Delete. --

Re: rs6000: Generate an lxvp instead of two adjacent lxv instructions

On Thu, Jul 15, 2021 at 09:15:55AM -0500, Peter Bergner wrote: > On 7/14/21 4:12 PM, Peter Bergner wrote: > > I'll make the change above and rebuild just to be safe and then commit. > > Regtesting was clean as expected, so I pushed the commit to trunk. Thanks. > Is this ok for backporting to GCC

Re: [RFC] ipa: Adjust references to identify read-only globals

> Hi, > > gcc/ChangeLog: > > 2021-06-29 Martin Jambor > > * cgraph.h (ipa_replace_map): New field force_load_ref. > * ipa-prop.h (ipa_param_descriptor): Reduce precision of move_cost, > aded new flag load_dereferenced, adjusted comments. > (ipa_get_param_dereferenced):

Re: [PATCH 1/2] testsuite: [arm] Add missing effective-target to vusdot-autovec.c

Christophe Lyon via Gcc-patches writes: > This test fails when forcing an -mcpu option incompatible with > -march=armv8.2-a+i8mm. > > This patch adds the missing arm_v8_2a_i8mm_ok effective-target, as > well as the associated dg-add-options arm_v8_2a_i8mm. > > 2021-07-15 Christophe Lyon > >

Re: [PATCH 2/2] testsuite: [arm] Remove arm_v8_2a_imm8_neon_ok_nocache

Christophe Lyon via Gcc-patches writes: > This patch removes this recently-introduced effective-target, as it > looks like a typo and duplicate for arm_v8_2a_i8mm_ok (imm8 vs i8mm), > and it is not used. > > 2021-07-15 Christophe Lyon > > gcc/testsuite/ > * lib/target-supports.exp (

Re: [PATCH] consider parameter names in -Wvla-parameter (PR 97548)

On 7/8/21 5:36 PM, Jeff Law wrote: On 7/1/2021 7:02 PM, Martin Sebor via Gcc-patches wrote: -Wvla-parameter relies on operand_equal_p() with OEP_LEXICOGRAPHIC set to compare VLA bounds for equality.  But operand_equal_p() doesn't consider decl names, and so nontrivial expressions that refer to

[PATCH] c++: alias CTAD inside decltype [PR101233]

This is the alias CTAD version of the CTAD bug PR93248, and the fix is the same: clear cp_unevaluated_operand so that the entire chain of DECL_ARGUMENTS gets substituted. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/11? PR c++/101233 gcc/cp/ChangeLog:

[PATCH] c++: covariant reference return type [PR99664]

This implements the wording changes of DR 960 which clarifies that two reference types are covariant only if they're both lvalue references or both rvalue references. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? DR 960 PR c++/99664 gcc/cp/Change

[PATCH 1/4][committed] testsuite: Fix testisms in scalar tests PR101457

Hi All, These testcases accidentally contain the wrong signs for the expected values for the scalar code. The vector code however is correct. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Committed as a trivial fix. Thanks, Tamar gcc/testsuite/ChangeLog: PR middle-e

[PATCH 2/4]AArch64: correct usdot vectorizer and intrinsics optabs

Hi All, There's a slight mismatch between the vectorizer optabs and the intrinsics patterns for NEON. The vectorizer expects operands[3] and operands[0] to be the same but the aarch64 intrinsics expanders expect operands[0] and operands[1] to be the same. This means we need different patterns he

[PATCH 3/4]AArch64: correct dot-product RTL patterns for aarch64.

Hi All, The previous fix for this problem was wrong due to a subtle difference between where NEON expects the RMW values and where intrinsics expects them. The insn pattern is modeled after the intrinsics and so needs an expand for the vectorizer optab to switch the RTL. However operand[3] is no

[PATCH 4/4][AArch32]: correct dot-product RTL patterns.

Hi All, The previous fix for this problem was wrong due to a subtle difference between where NEON expects the RMW values and where intrinsics expects them. The insn pattern is modeled after the intrinsics and so needs an expand for the vectorizer optab to switch the RTL. However operand[3] is no

Re: [PATCH] c++: argument pack expansion inside constraint [PR100138]

On Sat, May 8, 2021 at 8:42 AM Jason Merrill wrote: > > On 5/7/21 12:33 PM, Patrick Palka wrote: > > This PR is about CTAD but the underlying problems are more general; > > CTAD is a good trigger for them because of the necessary substitution > > into constraints that deduction guide generation en

Re: [committed] libstdc++: Add noexcept to __replacement_assert [PR101429]

On 15/07/21 5:26 pm, Jonathan Wakely via Libstdc++ wrote: This results in slightly smaller code when assertions are enabled when either using Clang (because it adds code to call std::terminate when potentially-throwing functions are called in a noexcept function) or a freestanding or non-verbose

[PATCH] x86: Don't set AVX_U128_DIRTY when all bits are zero

In a single SET, all bits of the source YMM/ZMM register are zero when 1. The source is contant zero. 2. The source YMM/ZMM operand are defined from contant zero. and we don't set AVX_U128_DIRTY. gcc/ PR target/101456 * config/i386/i386.c (ix86_avx_u128_mode_needed): Don't set

[PATCH] c++: Add C++20 #__VA_OPT__ support

Hi! The following patch implements C++20 # __VA_OPT__ (...) support. Testcases cover what I came up with myself and what LLVM has for #__VA_OPT__ in its testsuite and the string literals are identical between the two compilers on the va-opt-5.c testcase. Haven't looked at the non-#__VA_OPT__ diff

Re: [PATCH] [android] Disable large files when unsupported

-- João Gabriel Jardim

Re: [PATCH] [android] Disable large files when unsupported

-- João Gabriel Jardim

Re: [PATCH] [android] Disable large files when unsupported

Hey João , I think there's a problem with your email, it's empty! -- *Abraão C. de Santana*

Re: [committed] libstdc++: Add noexcept to __replacement_assert [PR101429]

On Thu, 15 Jul 2021, 18:21 François Dumont via Libstdc++, < libstd...@gcc.gnu.org> wrote: > On 15/07/21 5:26 pm, Jonathan Wakely via Libstdc++ wrote: > > This results in slightly smaller code when assertions are enabled when > > either using Clang (because it adds code to call std::terminate when

[PATCH] gcc_update: use gcc-descr git alias for revision string in gcc/REVISION

This is to make development version string more readable, and to simplify navigation through gcc-testresults. Currently gcc_update uses git log --pretty=tformat:%p:%t:%H to generate version string, which is somewhat excessive since conversion to git because commit hashes are now stable. Even bett

[committed] analyzer: handle self-referential phis

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as a9241df96e1950c630550ada9371c0b4a03496cf. gcc/analyzer/ChangeLog: * state-purge.cc (self_referential_phi_p): New. (state_purge_per_ssa_name::process_point): Don't purge an SSA name at its def-

[committed] analyzer: use DECL_DEBUG_EXPR on SSA names for artificial vars

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as e9711fe482b4abef0e7572809d3593631991276e. gcc/analyzer/ChangeLog: * analyzer.cc (fixup_tree_for_diagnostic_1): Use DECL_DEBUG_EXPR if it's available. * engine.cc (readability): Likewise. Sign

[committed] analyzer: add -fdump-analyzer-exploded-paths

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as 98cd4d123aa14598b1f0d54c22663c8200a96d9c. gcc/analyzer/ChangeLog: * analyzer.opt (fdump-analyzer-exploded-paths): New. * diagnostic-manager.cc (diagnostic_manager::emit_saved_diagnostic): Impl

[committed] analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al]

The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduce

  1   2   >