Cannot reproduce – Re: [r12-4632 Regression] FAIL: gfortran.dg/bind-c-intent-out-2.f90 -Os (test for excess errors) on Linux/x86_64

Hi, for some reasons, I cannot reproduce this. I checked with that I am in sync with master – and I also tried -m32 and -march=cascadelake, running both manually and via DejaGNU but I it passes here. Can someone who sees it show the excess error? Or was that a spurious issue which is now gone?

[r12-4632 Regression] FAIL: gfortran.dg/bind-c-intent-out-2.f90 -Os (test for excess errors) on Linux/x86_64

On Linux/x86_64, 24e99e6ec1cc57f3660c00ff677c7feb16aa94d2 is the first bad commit commit 24e99e6ec1cc57f3660c00ff677c7feb16aa94d2 Author: Tobias Burnus Date: Fri Oct 22 23:23:06 2021 +0200 Fortran: Avoid running into assert with -fcheck= + UBSAN caused FAIL: gfortran.dg/bind-c-intent-out

[Fortran, committed] Add testcase for PR95196

I've committed another testcase from a bugzilla issue that now appears to be fixed. -Sandra commit 9a0e34eb45e36d4f90cedb61191fd31da0bab256 Author: Sandra Loosemore Date: Fri Oct 22 17:22:00 2021 -0700 Add testcase for PR fortran/95196 2021-10-22 José Rui Faustino de Sousa

Re: [committed] doc: Convert mingw-w64.org links to https

On Sat, 23 Oct 2021, Jonathan Wakely wrote: >> (That makes it all the more puzzling how the issue you fixed last >> week did not arise, Jonathan.) > It didn't give a 404, there was a page at the end of the link, just > an empty one. So it probably looks like a good link to your script. Yes, as lo

Re: [committed] doc: Convert mingw-w64.org links to https

On Sat, 23 Oct 2021, 00:43 Jonathan Wakely, wrote: > > > On Fri, 22 Oct 2021, 23:28 Gerald Pfeifer, wrote: > >> It turns out my link checker does catch broken links under >> gcc.gnu.org/install/ - fixed thusly. >> >> (That makes it all the more puzzling how the issue you fixed last >> week did n

Re: [committed] doc: Convert mingw-w64.org links to https

On Fri, 22 Oct 2021, 23:28 Gerald Pfeifer, wrote: > It turns out my link checker does catch broken links under > gcc.gnu.org/install/ - fixed thusly. > > (That makes it all the more puzzling how the issue you fixed last > week did not arise, Jonathan.) > It didn't give a 404, there was a page at

Re: [PATCH][WIP] Add install-dvi Makefile targets

On Fri, Oct 22, 2021 at 8:23 AM Jeff Law wrote: > > > > On 10/18/2021 7:30 PM, Eric Gallager wrote: > > On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager wrote: > >> On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager wrote: > >>> Currently the build machinery handles install-pdf and install-html > >>> ta

[committed] doc: Convert mingw-w64.org links to https

It turns out my link checker does catch broken links under gcc.gnu.org/install/ - fixed thusly. (That makes it all the more puzzling how the issue you fixed last week did not arise, Jonathan.) Gerald gcc: * doc/install.texi (Binaries): Convert mingw-w64.org to https. (Specific)

[committed] libstdc++: Constrain std::make_any [PR102894]

std::make_any should be constrained so it can only be called if the construction of the return value would be valid. Tested x86_64-linux, committed to trunk. I plan to backport this too. libstdc++-v3/ChangeLog: PR libstdc++/102894 * include/std/any (make_any): Add SFINAE const

[committed]

Committed as r12-4633-g030875c197e339542ddfcbad90cfc01263151bec To reduce the XFAIL clutter in the *.sum files, this patch removes some pointless XFAIL in favour of pruning the output which should be ignored and using explicit checks for the currently output warnings/errors. Tobias -

[committed] wwwdocs: gcc-5/changes.html: Update link to Intel's pcommit deprecation

--- htdocs/gcc-5/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-5/changes.html b/htdocs/gcc-5/changes.html index 05e796dd..2e2e20e6 100644 --- a/htdocs/gcc-5/changes.html +++ b/htdocs/gcc-5/changes.html @@ -1084,7 +1084,7 @@ are not listed here). IA-32

[committed] Fortran: Avoid running into assert with -fcheck= + UBSAN [PR92621]

The testcase of the PR or as attached gave an ICE, but only when compiled with -fcheck=all -fsanitize=undefined. Solution: Strip the nop to avoid the assert failure. Committed as r12-4632-g24e99e6ec1cc57f3660c00ff677c7feb16aa94d2 Tobias * * * PS: Similar issues when using additional flags: I

Re: [PATCH] Port update-copyright.py to Python3

Hi! On 2021-01-04T11:15:22+0100, Martin Liška wrote: > The patch ports the script to Python3. Turns out, there is another issue, observed in combination with a few "BadYear" occurrences due to "improper" copyright lines (Bill, for your information). OK to push "Fix 'contrib/update-copyright.py'

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html PR100245 - ICE on automatic reallocation. Still ICEs TODO: Review patch. this one works and LGTM. Thanks for the patch! Harald

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi Tobias, José, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html PR100136 - ICE, regression, using flag -fcheck=pointer First testcase has an ICE with -fcheck=pointer Second testcase has always an ICE + possibly missing func. TODO: Re

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi Tobias, Am 22.10.21 um 15:06 schrieb Tobias Burnus: https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html PR100103 - Automatic reallocation fails inside select rank Still segfaults at runtime for 'that = a' where the RHS is a parameter and the LHS an allocatable assumed-rank array (

[PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

Dear Fortranners, the recently introduced shape validation for array components in DT constructors did not properly deal with invalid code created by ingenious testers. Obvious solution: replace the gcc_assert by a suitable error message. Regarding the error message: before the shape validation,

[Fortran, committed] Add testcase for PR 94289

I've committed this slightly cleaned-up version of the testcase originally submitted with the now-fixed issue PR 94289. -Sandra commit c31d2d14f798dc7ca9cc078200d37113749ec3bd Author: Sandra Loosemore Date: Fri Oct 22 11:08:19 2021 -0700 Add testcase for PR fortran/94289 2021-10

[PATCH] sra: Fix the fix for PR 102505 (PR 102886)

Hi, I was not careful with the fix for PR 102505 and did not craft the check to satisfy the verifier carefully, which lead to PR 102886. (The verifier has the test structured differently and somewhat redundantly, so I could not just copy it). This patch fixes it. I hope it is quite obvious corre

Re: [PATCH] Handle jobserver file descriptors in btest.

On Fri, Oct 22, 2021 at 1:15 AM Martin Liška wrote: > > On 10/21/21 20:15, Ian Lance Taylor wrote: > > On Thu, Oct 21, 2021 at 12:48 AM Martin Liška wrote: > >> > >> The patch is about sensitive handling of file descriptors opened > >> by make's jobserver. > > > > Thanks. I think a better approa

[PATCH] rs6000: Add optimizations for _mm_sad_epu8

Power9 ISA added `vabsdub` instruction which is realized in the `vec_absd` instrinsic. Use `vec_absd` for `_mm_sad_epu8` compatibility intrinsic, when `_ARCH_PWR9`. Also, the realization of `vec_sum2s` on little-endian includes two shifts in order to position the input and output to match the sem

Re: [PATCH] Try to resolve paths in threader without looking further back.

On 10/22/21 9:18 AM, Aldy Hernandez wrote: On Fri, Oct 22, 2021 at 4:27 PM Martin Sebor wrote: On 10/22/21 5:22 AM, Aldy Hernandez wrote: On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote: I'd like to see gimple-ssa-array-bounds invoked from the access pass too (instead of from VRP), and

Re: [PATCH 2/3][vect] Consider outside costs earlier for epilogue loops

"Andre Vieira (lists) via Gcc-patches" writes: > Hi, > > This patch changes the order in which we check outside and inside costs > for epilogue loops, this is to ensure that a predicated epilogue is more > likely to be picked over an unpredicated one, since it saves having to > enter a scalar e

Re: [PATCH][WIP] Add install-dvi Makefile targets

On 10/18/2021 7:30 PM, Eric Gallager wrote: On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager wrote: On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager wrote: Currently the build machinery handles install-pdf and install-html targets, but no install-dvi target. This patch is a step towards fixing t

Re: [PATCH] Try to resolve paths in threader without looking further back.

On Fri, Oct 22, 2021 at 4:27 PM Martin Sebor wrote: > > On 10/22/21 5:22 AM, Aldy Hernandez wrote: > > On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote: > > > >> I'd like to see gimple-ssa-array-bounds invoked from the access > >> pass too (instead of from VRP), and eventually -Wrestrict as wel

Re: [PATCH 6/6] aarch64: Pass and return Neon vector-tuple types without a parallel

Jonathan Wright writes: > Hi, > > Neon vector-tuple types can be passed in registers on function call > and return - there is no need to generate a parallel rtx. This patch > adds cases to detect vector-tuple modes and generates an appropriate > register rtx. > > This change greatly improves code

Re: [PATCH 5/6] gcc/lower_subreg.c: Prevent decomposition if modes are not tieable

Jonathan Wright writes: > Hi, > > Preventing decomposition if modes are not tieable is necessary to > stop AArch64 partial Neon structure modes being treated as packed in > registers. > > This is a necessary prerequisite for a future AArch64 PCS change to > maintain good code generation. > > Boots

Re: [PATCH 4/6] aarch64: Add machine modes for Neon vector-tuple types

Thanks a lot for doing this. Jonathan Wright writes: > @@ -763,9 +839,16 @@ aarch64_lookup_simd_builtin_type (machine_mode mode, > return aarch64_simd_builtin_std_type (mode, q); > >for (i = 0; i < nelts; i++) > -if (aarch64_simd_types[i].mode == mode > - && aarch64_simd_types[

Re: [PATCH] x86_64: Add insn patterns for V1TI mode logic operations.

On Fri, Oct 22, 2021 at 9:19 AM Roger Sayle wrote: > > > On x86_64, V1TI mode holds a 128-bit integer value in a (vector) SSE > register (where regular TI mode uses a pair of 64-bit general purpose > scalar registers). This patch improves the implementation of AND, IOR, > XOR and NOT on these val

[PATCH 4/6] aarch64: Add machine modes for Neon vector-tuple types

Hi, Until now, GCC has used large integer machine modes (OI, CI and XI) to model Neon vector-tuple types. This is suboptimal for many reasons, the most notable are:  1) Large integer modes are opaque and modifying one vector in the     tuple requires a lot of inefficient set/get gymnastics. The  

Re: [PATCH 3/6] gcc/expmed.c: Ensure vector modes are tieable before extraction

Jonathan Wright writes: > Hi, > > Extracting a bitfield from a vector can be achieved by casting the > vector to a new type whose elements are the same size as the desired > bitfield, before generating a subreg. However, this is only an > optimization if the original vector can be accessed in the

Re: [PATCH 2/6] gcc/expr.c: Remove historic workaround for broken SIMD subreg

Jonathan Wright writes: > Hi, > > A long time ago, using a parallel to take a subreg of a SIMD register > was broken. This temporary fix[1] (from 2003) spilled these registers > to memory and reloaded the appropriate part to obtain the subreg. > > The fix initially existed for the benefit of the P

Re: [PATCH 1/6] aarch64: Move Neon vector-tuple type declaration into the compiler

Jonathan Wright writes: > Hi, > > As subject, this patch declares the Neon vector-tuple types inside the > compiler instead of in the arm_neon.h header. This is a necessary first > step before adding corresponding machine modes to the AArch64 > backend. > > The vector-tuple types are implemented u

[PATCH 6/6] aarch64: Pass and return Neon vector-tuple types without a parallel

Hi, Neon vector-tuple types can be passed in registers on function call and return - there is no need to generate a parallel rtx. This patch adds cases to detect vector-tuple modes and generates an appropriate register rtx. This change greatly improves code generated when passing Neon vector- tup

[PATCH 5/6] gcc/lower_subreg.c: Prevent decomposition if modes are not tieable

Hi, Preventing decomposition if modes are not tieable is necessary to stop AArch64 partial Neon structure modes being treated as packed in registers. This is a necessary prerequisite for a future AArch64 PCS change to maintain good code generation. Bootstrapped and regression tested on: * x86_64

[PATCH 3/6] gcc/expmed.c: Ensure vector modes are tieable before extraction

Hi, Extracting a bitfield from a vector can be achieved by casting the vector to a new type whose elements are the same size as the desired bitfield, before generating a subreg. However, this is only an optimization if the original vector can be accessed in the new machine mode without first being

[PATCH 2/6] gcc/expr.c: Remove historic workaround for broken SIMD subreg

Hi, A long time ago, using a parallel to take a subreg of a SIMD register was broken. This temporary fix[1] (from 2003) spilled these registers to memory and reloaded the appropriate part to obtain the subreg. The fix initially existed for the benefit of the PowerPC E500 - a platform for which GC

[PATCH 1/6] aarch64: Move Neon vector-tuple type declaration into the compiler

Hi, As subject, this patch declares the Neon vector-tuple types inside the compiler instead of in the arm_neon.h header. This is a necessary first step before adding corresponding machine modes to the AArch64 backend. The vector-tuple types are implemented using a #pragma. This means initializati

Re: [PATCH] Try to resolve paths in threader without looking further back.

On 10/22/21 5:22 AM, Aldy Hernandez wrote: On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote: I'd like to see gimple-ssa-array-bounds invoked from the access pass too (instead of from VRP), and eventually -Wrestrict as well. You can do that right now. The pass has been converted to the new

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

Hi all, On 22.10.21 15:05, Hafiz Abid Qadeer wrote: This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not yet support the allocator-modifier as specified in OpenMP 5.1. The allocate clause is already supported in C/C++. I think the following shouldn't block the accept

Re: [PATCH] Canonicalize __atomic/sync_fetch_or/xor/and for constant mask.

On Thu, Oct 21, 2021 at 10:48 PM liuhongt wrote: > > Hi: > This patch is try to canoicalize bit_and and nop_convert order for > __atomic_fetch_or_*, __atomic_fetch_xor_*, > __atomic_xor_fetch_*,__sync_fetch_and_or_*, > __sync_fetch_and_xor_*,__sync_xor_and_fetch_*, > __atomic_fetch_and_*,__sync_f

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi José, hi Fortraners, triage of all listed patches: On 21.06.21 17:21, José Rui Faustino de Sousa wrote: https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html PR100040 - Wrong code with intent out assumed-rank allocatable PR100029 - ICE on subroutine call with allocatable polymorphi

[PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not yet support the allocator-modifier as specified in OpenMP 5.1. The allocate clause is already supported in C/C++. gcc/fortran/ChangeLog: * dump-parse-tree.c (show_omp_clauses): Handle OMP_LIST_ALLOCATE.

Re: [RFC PATCH v2 1/1] [ARM] Add support for TLS register based stack protector canary access

On Thu, 21 Oct 2021 at 18:51, Ard Biesheuvel wrote: > > Add support for accessing the stack canary value via the TLS register, > so that multiple threads running in the same address space can use > distinct canary values. This is intended for the Linux kernel running in > SMP mode, where processes

[PATCH] tree-optimization/102893 - properly DCE empty loops inside infinite loops

The following fixes the test for an exit edge I put in place for the fix for PR45178 where I somehow misunderstood how the cyclic list works. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-10-22 Richard Biener PR tree-optimization/102893 * tree-ssa-dce.c (fi

Re: [PATCH] Try to resolve paths in threader without looking further back.

On Thu, Oct 21, 2021 at 4:51 PM Martin Sebor wrote: > I'd like to see gimple-ssa-array-bounds invoked from the access > pass too (instead of from VRP), and eventually -Wrestrict as well. You can do that right now. The pass has been converted to the new API and it would just require calling it w

Re: [PATCH] Convert strlen pass from evrp to ranger.

On Fri, Oct 15, 2021 at 12:39 PM Aldy Hernandez wrote: > Also, I am PINGing patch 0002, which is the strlen pass conversion to > the ranger. As mentioned, this is just a change from an evrp client to > a ranger client. The APIs are exactly the same, and besides, the evrp > analyzer is deprecate

Re: [match.pd] PR83750 - CSE erf/erfc pair

On Fri, 22 Oct 2021 at 14:56, Richard Biener wrote: > > On Fri, 22 Oct 2021, Prathamesh Kulkarni wrote: > > > On Wed, 20 Oct 2021 at 18:21, Richard Biener wrote: > > > > > > On Wed, 20 Oct 2021, Prathamesh Kulkarni wrote: > > > > > > > On Tue, 19 Oct 2021 at 16:55, Richard Biener wrote: > > > >

[COMMITTED] Disregard incoming equivalences to a path when defining a new one.

The equivalence oracle creates a new equiv set at each def point, killing any incoming equivalences, however in the path sensitive oracle we create brand new equivalences at each PHI: BB4: BB8: x_5 = PHI Here we note that x_5 == y_8 at the end of the path. The current code is inter

Re: [PATCH 1v2/3][vect] Add main vectorized loop unrolling

Richard Biener writes: > That said, the overall flow is OK now, some details about the > max_vf check and where to compute the unrolled VF needs to be > fleshed out. And then there's the main analysis loop which, > frankly, is a mess right now, even before your patch :/ Yeah, the loop is certain

Re: [PATCH 1v2/3][vect] Add main vectorized loop unrolling

"Andre Vieira (lists)" writes: > On 15/10/2021 09:48, Richard Biener wrote: >> On Tue, 12 Oct 2021, Andre Vieira (lists) wrote: >> >>> Hi Richi, >>> >>> I think this is what you meant, I now hide all the unrolling cost >>> calculations >>> in the existing target hooks for costs. I did need to adj

[PATCH] bootstrap/102681 - properly CSE PHIs with default def args

The PR shows that we fail to CSE PHIs containing (different) default definitions due to the fact on how we now handle on-demand build of VN_INFO. The following fixes this in the same way the PHI visitation code does. On gcc.dg/ubsan/pr81981.c this causes one expected warning to be elided since th

Re: [match.pd] PR83750 - CSE erf/erfc pair

On Fri, 22 Oct 2021, Prathamesh Kulkarni wrote: > On Wed, 20 Oct 2021 at 18:21, Richard Biener wrote: > > > > On Wed, 20 Oct 2021, Prathamesh Kulkarni wrote: > > > > > On Tue, 19 Oct 2021 at 16:55, Richard Biener wrote: > > > > > > > > On Tue, 19 Oct 2021, Prathamesh Kulkarni wrote: > > > > > >

Re: [aarch64] PR102376 - Emit better diagnostic for arch extensions in target attr

On Wed, 20 Oct 2021 at 15:05, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 19 Oct 2021 at 19:58, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > Hi, > >> > The attached patch emits a more verbose diagnostic for target attribute > >> > that > >>

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi Tobias, My disappearance is partly responsible for the backlog. I told José that I would start working on it some months since but just have not had the time. I can do some of the reviews but still do not have much time to spare. Perhaps you could divide them up between us. Andrew Benson has b

Re: [PATCH] Handle jobserver file descriptors in btest.

On 10/21/21 20:15, Ian Lance Taylor wrote: On Thu, Oct 21, 2021 at 12:48 AM Martin Liška wrote: The patch is about sensitive handling of file descriptors opened by make's jobserver. Thanks. I think a better approach would be, at the start of main, fstat the descriptors up to 10 and record t

Re: [match.pd] PR83750 - CSE erf/erfc pair

On Wed, 20 Oct 2021 at 18:21, Richard Biener wrote: > > On Wed, 20 Oct 2021, Prathamesh Kulkarni wrote: > > > On Tue, 19 Oct 2021 at 16:55, Richard Biener wrote: > > > > > > On Tue, 19 Oct 2021, Prathamesh Kulkarni wrote: > > > > > > > On Tue, 19 Oct 2021 at 13:02, Richard Biener > > > > wrote:

José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi José, hi all, especially since my patch which moved the descriptor conversion from libgfortran to gfortran is in, I wonder whether there are still patches to be applied and useful testcases; I assume there are more issues in Bugzilla, especially as I filled myself some (often related to polymo

[PATCH] x86_64: Add insn patterns for V1TI mode logic operations.

On x86_64, V1TI mode holds a 128-bit integer value in a (vector) SSE register (where regular TI mode uses a pair of 64-bit general purpose scalar registers). This patch improves the implementation of AND, IOR, XOR and NOT on these values. The benefit is demonstrated by the following simple test