[PATCH] [i386] Remove storage only description for _Float16 w/o avx512fp16.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580207.html gcc/ChangeLog: * doc/extend.texi (Half-Precision): Remove storage only description for _Float16 w/o avx512fp16. --- gcc/doc/extend.texi | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-)

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi Tobias, OK for mainline? As promised on IRC, here's the review. Maybe you can add a test case which shows that the call to the size intrinsic really does not happen. OK with that. Thanks for the patch! Best regards Thomas

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

On 8/28/21 07:54, nick huang via Gcc-patches wrote: Reference with cv-qualifiers should be ignored instead of causing an error because standard accepts cv-qualified references introduced by typedef which is ignored. Therefore, the fix prevents GCC from reporting error by not setting variable

Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

I already responded to this patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579527.html

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

On Fri, Sep 24, 2021 at 11:14 AM Fāng-ruì Sòng wrote: > > On Fri, Sep 24, 2021 at 10:41 AM H.J. Lu wrote: > > > > On Fri, Sep 24, 2021 at 10:29 AM Fāng-ruì Sòng wrote: > > > > > > On Tue, Sep 21, 2021 at 7:08 PM Fāng-ruì Sòng wrote: > > > > > > > > On Tue, Sep 21, 2021 at 6:57 PM H.J. Lu

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

On Fri, Sep 24, 2021 at 10:41 AM H.J. Lu wrote: > > On Fri, Sep 24, 2021 at 10:29 AM Fāng-ruì Sòng wrote: > > > > On Tue, Sep 21, 2021 at 7:08 PM Fāng-ruì Sòng wrote: > > > > > > On Tue, Sep 21, 2021 at 6:57 PM H.J. Lu wrote: > > > > > > > > On Tue, Sep 21, 2021 at 9:16 AM Uros Bizjak wrote:

[PATCH] Add a simulate_record_decl lang hook

This patch adds a lang hook for defining a struct/RECORD_TYPE “as if” it had appeared directly in the source code. It follows the similar existing hook for enums. It's the caller's responsibility to create the fields (as FIELD_DECLs) but the hook's responsibility to create and declare the

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

On Fri, Sep 24, 2021 at 10:29 AM Fāng-ruì Sòng wrote: > > On Tue, Sep 21, 2021 at 7:08 PM Fāng-ruì Sòng wrote: > > > > On Tue, Sep 21, 2021 at 6:57 PM H.J. Lu wrote: > > > > > > On Tue, Sep 21, 2021 at 9:16 AM Uros Bizjak wrote: > > > > > > > > On Mon, Sep 20, 2021 at 8:20 PM Fāng-ruì Sòng

Re: [PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC

On Tue, Sep 21, 2021 at 7:08 PM Fāng-ruì Sòng wrote: > > On Tue, Sep 21, 2021 at 6:57 PM H.J. Lu wrote: > > > > On Tue, Sep 21, 2021 at 9:16 AM Uros Bizjak wrote: > > > > > > On Mon, Sep 20, 2021 at 8:20 PM Fāng-ruì Sòng via Gcc-patches > > > wrote: > > > > > > > > PING^5

Re: [PATCH] Allow different vector types for stmt groups

Richard Biener writes: > This allows vectorization (in practice non-loop vectorization) to > have a stmt participate in different vector type vectorizations. > It allows us to remove vect_update_shared_vectype and replace it > by pushing/popping STMT_VINFO_VECTYPE from SLP_TREE_VECTYPE around >

Re: [PATCH] top-level: merge Makefile.def patches from binutils-gdb repository

* Richard Biener [2021-09-24 13:58:20 +0200]: > On Fri, Sep 24, 2021 at 12:49 PM Andrew Burgess > wrote: > > > > This commit back-ports two patches to Makefile.def from the > > binutils-gdb repository, these patches were committed over there > > without first being merged in to the gcc

[PING}[PATCH] libgcc, emutls: Allow building weak definitions of the emutls functions.

Hi, as noted below the non-Darwin parts of this are trivial (and a no-OP). I’d like to apply this to start work towards solving Darwin’s libgcc issues, OTOH, the two raised questions remain… thanks Iain > On 20 Sep 2021, at 09:25, Iain Sandoe wrote: > > Hi, > > The non-Darwin part of this

Re: [PATCH] [GIMPLE] Simplify (_Float16) ceil ((double) x) to .CEIL (x) when available.

On Fri, Sep 24, 2021 at 1:26 PM liuhongt wrote: > > Hi: > Related discussion in [1] and PR. > > Bootstrapped and regtest on x86_64-linux-gnu{-m32,}. > Ok for trunk? > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574330.html > > gcc/ChangeLog: > > PR target/102464 >

Re: [PATCH] Avoid invalid loop transformations in jump threading registry.

On 9/24/2021 5:34 AM, Aldy Hernandez wrote: On 9/23/21 6:10 PM, Jeff Law wrote: On 9/23/2021 5:15 AM, Aldy Hernandez wrote: My upcoming improvements to the forward jump threader make it thread more aggressively.  In investigating some "regressions", I noticed that it has always allowed

[PATCH] Replace VRP threader with a hybrid forward threader.

This patch implements the new hybrid forward threader and replaces the embedded VRP threader with it. With all the pieces that have gone in, the implementation of the hybrid threader is straightforward: convert the current state into SSA imports that the solver will understand, and let the path

[pushed] IRA: Make profitability calculation of RA conflict presentations independent of host compiler type sizes of RA conflict presentations independent of host compiler type sizes [PR102147]

The following patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 The patch was successfully bootstrapped and tested on x86-64. commit ec4c30b64942e615b4bb4b9761cd3b2635158608 (HEAD -> master) Author: Vladimir N. Makarov Date:   Fri Sep 24 10:06:45 2021 -0400     Make

[PATCH] rs6000: Fix vec_cpsgn parameter order (PR101985)

Hi! This fixes a bug reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985. The vec_cpsgn built-in function API differs in argument order from the copysign3 convention. Currently that pattern is incorrctly used to implement vec_cpsgn. Fix that while leaving the existing pattern in

[COMMITTED] path solver: Avoid further lookups when range is defined in block.

If an SSA is defined in the current block, there is no need to query range_on_path_entry for additional information. Tested on x86-64 Linux. gcc/ChangeLog: * gimple-range-path.cc (path_range_query::path_range_query): Move debugging header...

[committed] libstdc++: Remove redundant 'inline' specifiers

These functions are constexpr, which means they are implicitly inline. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: * include/bits/range_access.h (cbegin, cend): Remove redundant 'inline' specifier. Tested x86_64-linux. Committed to trunk. commit

PING [PATCH] warn for more impossible null pointer tests [PR102103]

Ping: Jeff, with the C++ part approved, can you please confirm your approval with the C parts of the patch? https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html On 9/21/21 6:34 PM, Martin Sebor wrote: On 9/21/21 3:40 PM, Jason Merrill wrote: The C++ changes are OK.

Re: [PATCH] Enable auto-vectorization at O2 with very-cheap cost model.

On 9/23/21 9:32 PM, Hongtao Liu wrote: On Thu, Sep 23, 2021 at 11:18 PM Martin Sebor wrote: On 9/23/21 12:30 AM, Richard Biener wrote: On Thu, 23 Sep 2021, Hongtao Liu wrote: On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu wrote: On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor wrote: On

Re: [PATCH] Avoid invalid loop transformations in jump threading registry.

On 23/09/2021 13:15, Aldy Hernandez via Gcc-patches wrote: My upcoming improvements to the forward jump threader make it thread more aggressively. In investigating some "regressions", I noticed that it has always allowed threading through empty latches and across loop boundaries. As we have

Re: [PATCH] Relax condition of (vec_concat:M(vec_select op0 idx0)(vec_select op0 idx1)) to allow different modes between op0 and M, but have same inner mode.

On Mon, Sep 13, 2021 at 04:24:13PM +0200, Richard Biener wrote: > On Mon, Sep 13, 2021 at 4:10 PM Jeff Law via Gcc-patches > wrote: > > I'm not convinced that we need the inner mode to match anything. As > > long as the vec_concat's mode is twice the size of the vec_select modes > > and the

FW: [PING] Re: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) under -ffast-math on aarch64

Hi, Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577846.html The patch is attached as text for ease of use. Is there anything that needs to change? Ok for master? If OK, can it be committed for me, I have no commit rights. Jirui Wu -Original Message- From: Jirui Wu

[PATCH] aarch64: Fix type qualifiers for qtbl1 and qtbx1 Neon builtins

Hi, This patch fixes type qualifiers for the qtbl1 and qtbx1 Neon builtins and removes the casts from the Neon intrinsic function bodies that use these builtins. Regression tested and bootstrapped on aarch64-none-linux-gnu - no issues. Ok for master? Thanks, Jonathan --- gcc/ChangeLog:

Re: [PATCH] top-level: merge Makefile.def patches from binutils-gdb repository

On Fri, Sep 24, 2021 at 12:49 PM Andrew Burgess wrote: > > This commit back-ports two patches to Makefile.def from the > binutils-gdb repository, these patches were committed over there > without first being merged in to the gcc repository. > > These commits all relate to dependencies for

Re: [PATCH] Avoid invalid loop transformations in jump threading registry.

On 9/23/21 6:10 PM, Jeff Law wrote: On 9/23/2021 5:15 AM, Aldy Hernandez wrote: My upcoming improvements to the forward jump threader make it thread more aggressively.  In investigating some "regressions", I noticed that it has always allowed threading through empty latches and across loop

[PATCH] [GIMPLE] Simplify (_Float16) ceil ((double) x) to .CEIL (x) when available.

Hi: Related discussion in [1] and PR. Bootstrapped and regtest on x86_64-linux-gnu{-m32,}. Ok for trunk? [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574330.html gcc/ChangeLog: PR target/102464 * config/i386/i386.c (ix86_optab_supported_p): Return true

*PING* Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

Reference with cv-qualifiers should be ignored instead of causing an error because standard accepts cv-qualified references introduced by typedef which is ignored. Therefore, the fix prevents GCC from reporting error by not setting variable "bad_quals" in case the reference is introduced by

*PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

These bugs are considered duplicate cases of PR51851 which has been suspended since 2012, an issue known as "core1001/1322". Considering this background, it deserves a long comment to explain. Many people believed the root cause of this family of bugs is related with the nature of how and when

Re: [PATCH] Relax condition of (vec_concat:M(vec_select op0 idx0)(vec_select op0 idx1)) to allow different modes between op0 and M, but have same inner mode.

ping On Mon, Sep 13, 2021 at 11:19 PM Hongtao Liu wrote: > > On Mon, Sep 13, 2021 at 10:10 PM Jeff Law via Gcc-patches > wrote: > > > > > > > > On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote: > > >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 > > > idx2)), > > >

[PATCH] top-level: merge Makefile.def patches from binutils-gdb repository

This commit back-ports two patches to Makefile.def from the binutils-gdb repository, these patches were committed over there without first being merged in to the gcc repository. These commits all relate to dependencies for binutils-gdb modules, so should have no impact on gcc, I tested a gcc

Re: [PATCH v2 2/3] reassoc: Propagate PHI_LOOP_BIAS along single uses

On Thu, 2021-09-23 at 13:55 +0200, Richard Biener wrote: > On Wed, 22 Sep 2021, Ilya Leoshkevich wrote: > > > PR tree-optimization/49749 introduced code that shortens dependency > > chains containing loop accumulators by placing them last on operand > > lists of associative operations. > > > >

[PATCHv2] top-level configure: setup target_configdirs based on repository

* Thomas Schwinge [2021-09-23 11:29:05 +0200]: > Hi! > > I only had a curious look here; hope that's still useful. > > On 2021-09-22T16:30:42+0100, Andrew Burgess > wrote: > > The top-level configure script is shared between the gcc repository > > and the binutils-gdb repository. > > > > The

Re: [PATCH] top-level configure: setup target_configdirs based on repository

* Richard Biener [2021-09-23 10:53:16 +0200]: > On Wed, Sep 22, 2021 at 5:47 PM Andrew Burgess > wrote: > > > > The top-level configure script is shared between the gcc repository > > and the binutils-gdb repository. > > > > The target_configdirs variable in the configure.ac script, defines > >

Re: [PATCH] combine: Check for paradoxical subreg

Hi, pinging this patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573509.html It introduces a check for a paradoxical subreg in combine that would ICE otherwise. Regards Robin

Re: [PATCH, Fortran] Add missing diagnostic for F2018 C711 (TS29113 C407c)

On 24.09.21 01:19, Sandra Loosemore wrote: Here's another missing-diagnostic patch for the Fortran front end, this time for PR Fortran/101333. OK to commit? That's "C711 An assumed-type actual argument that corresponds to an assumed-rank dummy argument shall be assumed-shape or assumed-rank."

Re: Fortran: Improve file-reading error diagnostic [PR55534] (was: Re: [Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534])

On 23.09.21 23:01, Harald Anlauf via Fortran wrote: compiled with -cpp gives: pr55534-play.f90:4:2: 4 |   type t |  1~~ Fatal Error: no/such/file.inc: No such file or directory compilation terminated. If you have an easy solution for that one, David has an easy but hackish

[PATCH] Verify unallocated edge/BB flags are clear

This adds verification that unused auto_{edge,bb}_flag are not remaining set but correctly cleared by consumers. The intent is that those flags can be cheaply used on a smaller IL region and thus afterwards clearing can be restricted to the same small region as well. Bootstrapped and tested on

Re: [PATCH] real: fix encoding of negative IEEE double/quad values [PR98216]

On Thu, Sep 23, 2021 at 10:44 PM Patrick Palka via Gcc-patches wrote: > > In encode_ieee_double/quad, the assignment > > unsigned long VAL = r->sign << 31; > > is intended to set the 31st bit of VAL whenever the given REAL_CST is > negative. But on LP64 hosts it also unintentionally sets the

Re: [RFC] Don't move cold code out of loop by checking bb count

Update the patch to v3, not sure whether you prefer the paste style and continue to link the previous thread as Segher dislikes this... [PATCH v3] Don't move cold code out of loop by checking bb count Changes: 1. Handle max_loop in determine_max_movement instead of outermost_invariant_loop. 2.