[PATCH] libgcc: allocate extra space for morestack expansion

2021-02-09 Thread Rain Mark via Gcc-patches
Hello. After enabling -fsplit-stack, dynamic stack expansion of the coroutine is realized, but calling functions without -fsplit-stack will directly expand the space by 1M, which is too wasteful for a system with a large number of coroutines running under the 128K stack size. We hope to give users

[PATCH 2/2] openacc: Add XFAILs [PR98979]

2021-02-09 Thread Julian Brown
This patch adds some XFAILs for PR98979 until the patch to fix them has been approved. See: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html gcc/testsuite/ PR fortran/98979 * gfortran.dg/goacc/array-with-dt-2.f90: Add expected errors. * gfortran.dg/goa

[PATCH 1/2] Revert "openacc: Allow strided arrays in update directives"

2021-02-09 Thread Julian Brown
This patch reverts the non-testsuite parts of commit 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146 which cause ICEs without the yet-to-be-approved patch here: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html gcc/fortran/ PR fortran/98979 * openmp.c (resolve_omp_cl

[PATCH 0/2] openacc: Fix/temp workaround for PR98979

2021-02-09 Thread Julian Brown
Hi, Until a patch to fix derived type mappings with array elements, etc. is approved, this small patch series (a) reverts the strided arrays in update directives patch, and (b) adds some XFAILS/skips for the failing tests flagged in PR98979. I will apply shortly as obvious. Thanks, Julian Juli

Patch for PR analyzer/98797

2021-02-09 Thread brian.sobulefsky via Gcc-patches
The attached patch has been bootstrapped and regression tested. It addresses PR analyzer/98797, which is built off the expected failures in gcc/testsuite/gcc.dg/analyzer/casts-1.c It fixes those failures and additional manifestations. That testsuite file has been updated to no longer expect fai

Re: [PATCH 3/4] c++: Delay normalizing nested requirements until satisfaction

2021-02-09 Thread Jason Merrill via Gcc-patches
On 2/9/21 6:04 PM, Jason Merrill wrote: On 2/8/21 2:03 PM, Patrick Palka wrote: This sets up the functionality for controlling the initial set of template parameters to pass to normalization when dealing with a constraint-expression that is not associated with some constrained declaration, for i

[committed] add links to manual

2021-02-09 Thread Martin Sebor via Gcc-patches
While editing changes.html I noticed a few missing links to the user manual. I've pushed the attached change to add them. Martin commit 5a57e261bcfbb7691901bdf219ba114b449b690e Author: Martin Sebor Date: Tue Feb 9 17:40:01 2021 -0700 Move -Wtsan under New Warnings. Add more links to the

[committed] GCC 11 changes

2021-02-09 Thread Martin Sebor via Gcc-patches
I pushed the attached change documenting my GCC 11 changes. I validated the file on https://validator.w3.org. Martin commit cf0d4e41a94bae204a8c5d2490063d58cdb1d4e3 Author: Martin Sebor Date: Tue Feb 9 17:12:16 2021 -0700 Update new attribute malloc and document new and enhanced warnings

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 08:55:26PM +0100, Jakub Jelinek wrote: > On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote: > > For GCC 11, I think let's fix the regression with your (Jakub) earlier > > patch, maybe only for DIEs with DW_AT_const_value. > > Thanks. > Following works too, so I'

Re: [PATCH 3/4] c++: Delay normalizing nested requirements until satisfaction

2021-02-09 Thread Jason Merrill via Gcc-patches
On 2/8/21 2:03 PM, Patrick Palka wrote: This sets up the functionality for controlling the initial set of template parameters to pass to normalization when dealing with a constraint-expression that is not associated with some constrained declaration, for instance when normalizing a nested require

[PATCH] c++: Endless loop with targ deduction in member tmpl [PR95888]

2021-02-09 Thread Marek Polacek via Gcc-patches
My r10-7007 patch tweaked tsubst not to reduce the template level of template parameters when tf_partial. That caused infinite looping in is_specialization_of: we ended up with a class template specialization whose TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) == t, so the second for loop in is_specializa

Re: [Patch] Fortran: intrinsic.texi add missing arg to FINDLOC (was: FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html)

2021-02-09 Thread Tobias Burnus
Hi Thomas, On 09.02.21 22:54, Thomas Koenig via Fortran wrote: Just one nit: MASK does not have to be an array, it can also be a scalar. It just has to be conformable. Well spotted. However, that also applies to {MAX,MIN}{LOC,VAL}. Hence, I updated those as well. I will commit the patch tom

Re: [PATCH] c++: Fix ICE from op_unqualified_lookup [PR97582]

2021-02-09 Thread Patrick Palka via Gcc-patches
On Tue, 2 Feb 2021, Jason Merrill wrote: > On 2/2/21 12:19 AM, Patrick Palka wrote: > > In this testcase, we're crashing because the lookup of operator+ from > > within the generic lambda via lookup_name finds multiple bindings > > (namely C1::operator+ and C2::operator+) and returns a TREE_LIST >

Re: [Patch] Fortran: intrinsic.texi add missing arg to FINDLOC (was: FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html)

2021-02-09 Thread Thomas Koenig via Gcc-patches
Hi Tobias, I intent commit it as obvious, unless there are comments. Just one nit: MASK does not have to be an array, it can also be a scalar. It just has to be conformable. OK with that change. Best regards Thomas

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

2021-02-09 Thread Martin Sebor via Gcc-patches
On 2/8/21 4:26 PM, Jeff Law wrote: On 2/8/21 4:07 PM, Martin Sebor wrote: On 2/8/21 12:09 PM, Jeff Law wrote: On 2/3/21 3:45 PM, Martin Sebor wrote: On 2/3/21 2:57 PM, Jeff Law wrote: On 1/28/21 4:03 PM, Martin Sebor wrote: The GCC 11 -Warray-bounds enhancement to diagnose accesses who

[Patch] Fortran: intrinsic.texi add missing arg to FINDLOC (was: FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html)

2021-02-09 Thread Tobias Burnus
Hi Kay, hi all, On 09.02.21 21:41, Kay Diederichs wrote: the above link does not document the optional MASK argument. Could somebody fix this, please? Thanks for the comment. Findloc's mask argument is documented in the text ("If @var{MASK} is present, only the elements for which @var{MASK}

Re: [PATCH] c++: Consider addresses of heap artificial vars always non-NULL [PR98988]

2021-02-09 Thread Jason Merrill via Gcc-patches
On 2/9/21 3:11 PM, Jakub Jelinek wrote: On Tue, Feb 09, 2021 at 03:00:20PM -0500, Jason Merrill wrote: With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to b

[PATCH] Fix version namespace build

2021-02-09 Thread François Dumont via Gcc-patches
    libstdc++: Fix versioned namespace build     libstdc++-v3/ChangeLog:     * libsupc++/eh_ptr.cc (exception_ptr(__safe_bool)): Define if     _GLIBCXX_EH_PTR_COMPAT is defined.     (exception_ptr::_M_safe_bool_dummy()): Likewise.     (exception_ptr::operator!()):

[committed 2/2] analyzer: support "_IO_"-prefixed variants of FILE * fns [PR98575]

2021-02-09 Thread David Malcolm via Gcc-patches
PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28. The issue is that a getchar call gets inlined into a call to _IO_getc, and "_IO_getc" is not in the set of FILE * functions the analyzer "knows about". This exposes a

[committed 1/2] analyzer: treat pointers written to *UNKNOWN as escaping [PR98575]

2021-02-09 Thread David Malcolm via Gcc-patches
PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28. The issue is that a getchar call gets inlined into a call to _IO_getc, and "_IO_getc" is not in the set of FILE * functions the analyzer "knows about". This leads to a

Re: [PATCH] c++: Consider addresses of heap artificial vars always non-NULL [PR98988]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 03:00:20PM -0500, Jason Merrill wrote: > > With -fno-delete-null-pointer-checks which is e.g. implied by > > -fsanitize=undefined or default on some embedded targets, the middle-end > > folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one > > of them

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

2021-02-09 Thread Jason Merrill via Gcc-patches
On 2/9/21 6:18 AM, Anthony Sharp wrote: The parens are to help the editor line up the last line properly.  If the subexpression fits on one line, the parens aren't needed. A okay. No; "compile" means translate from C++ to assembly, "assemble" means that, plus call the assem

Re: [PATCH] c++: Consider addresses of heap artificial vars always non-NULL [PR98988]

2021-02-09 Thread Jason Merrill via Gcc-patches
On 2/9/21 3:25 AM, Jakub Jelinek wrote: Hi! With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Hmm, are

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 02:40:12PM -0500, Jason Merrill wrote: > For GCC 11, I think let's fix the regression with your (Jakub) earlier > patch, maybe only for DIEs with DW_AT_const_value. Thanks. Following works too, so I'll test it tonight. 2021-02-09 Jakub Jelinek PR debug/98755

Re: [PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

2021-02-09 Thread Jason Merrill via Gcc-patches
On 9/1/20 2:46 PM, Jason Merrill wrote: On 8/25/20 5:19 AM, Mark Wielaard wrote: On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote: This looks incorrect to me, that is a workaround for a real GCC bug. Shouldn't we instead do something like (untested) following patch? I mean, for DWARF < 5

Fix PR rtl-optimization/96015

2021-02-09 Thread Eric Botcazou
This is the miscompilation of Python on HP-PA/Linux present on the mainline and 10 branch, caused by the presence of a call to __builtin_unreachable () in the middle of a heavily branchy code, which confuses the reorg pass. Bootstrapped/regtested on SPARC/Solaris, applied on mainline and 10 bran

[OG10] [committed] Backport patches for non-rectangular loop collapse

2021-02-09 Thread Kwok Cheung Yeung
Hello I have backported the following patches for supporting non-rectangular loop collapse from mainline to the devel/omp/gcc-10 branch: 7bfdb5a1c694cb9006e0478941e4443b230f5b98 openmp: Fix ICE on non-rectangular loop with known 0 iterations 88528328ea560230f728af97110e89396c8267d2 openmp: Im

[PATCH] c++: abbreviated function template return type rewriting [PR98990]

2021-02-09 Thread Patrick Palka via Gcc-patches
When an abbreviated function template has a complex placeholder return type such auto& or auto**, the level adjustment performed by splice_late_return_type directly replaces the 'auto' inside the original return type with the level-adjusted 'auto', but that breaks TYPE_CANONICAL caching. Instead,

Re: [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

2021-02-09 Thread Martin Sebor via Gcc-patches
On 2/8/21 4:11 PM, Jeff Law wrote: On 2/8/21 3:44 PM, Martin Sebor wrote: On 2/8/21 3:26 PM, Jeff Law wrote: On 2/8/21 2:56 PM, Martin Sebor wrote: On 2/8/21 12:59 PM, Jeff Law wrote: On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote: Similar to the problem reported for -Wstringop

Re: [PATCH v2] arm: Low overhead loop handle long range branches [PR98931]

2021-02-09 Thread Richard Earnshaw (lists) via Gcc-patches
On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote: > Jakub Jelinek writes: > >> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches >> wrote: "TARGET_32BIT && TARGET_HAVE_LOB" - "le\t%|lr, %l0") + "* + if (get_attr_length (insn) == 4) +

Re: [PATCH] ICF: fix memory leak

2021-02-09 Thread Richard Biener via Gcc-patches
On Tue, Feb 9, 2021 at 6:17 PM Martin Liška wrote: > > The following fixes a memory leak. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? OK. > Thanks, > Martin > > gcc/ChangeLog: > > PR ipa/99003 > * ipa-icf.c (sem_item::add_

Re: [PATCH] if-to-switch: fix a memory leak

2021-02-09 Thread Richard Biener via Gcc-patches
On Tue, Feb 9, 2021 at 6:16 PM Martin Liška wrote: > > The following fixes a memory leak. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? OK. Richard. > Thanks, > Martin > > gcc/ChangeLog: > > PR tree-optimization/99002 > * g

Re: PR 96391? Can we fix it for gcc11?

2021-02-09 Thread Richard Biener
On Tue, 9 Feb 2021, Qing Zhao wrote: > Richard, > > Thank you for the reply. > > Yes, I understand that without a working testing case to repeat the error, > it’s very hard to debug and fix the issue. > > However, providing a testing case for this bug is really challenging from our > side du

RE: [PATCH] testsuite: aarch64: Add tests for vpaddq intrinsics

2021-02-09 Thread Kyrylo Tkachov via Gcc-patches
> -Original Message- > From: Jonathan Wright > Sent: 09 February 2021 17:08 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] testsuite: aarch64: Add tests for vpaddq intrinsics > > Hi, > > As subject, this patch adds tests for vpaddq_* Neon intrinsics. Since thes

[PATCH] testsuite: aarch64: Add tests for vpaddq intrinsics

2021-02-09 Thread Jonathan Wright via Gcc-patches
Hi, As subject, this patch adds tests for vpaddq_* Neon intrinsics. Since these intrinsics are only supported for AArch64, these tests are restricted to only run on AArch64 targets. (There are currently no tests covering these intrinsics.) Ok for master? Thanks, Jonathan --- gcc/testsuite/Cha

[committed] libstdc++: Clear up directories created by tests

2021-02-09 Thread Jonathan Wakely via Gcc-patches
libstdc++-v3/ChangeLog: * testsuite/27_io/filesystem/operations/remove_all.cc: Remove test directory after making it writable again. * testsuite/experimental/filesystem/operations/remove_all.cc: Likewise. Tested x86_64-linux. Committed to trunk. commit bfdb7b8c6f5

[aarch64][vect] Support V8QI->V8HI WIDEN_ patterns

2021-02-09 Thread Joel Hutton via Gcc-patches
Hi Richards, This patch adds support for the V8QI->V8HI case from widening vect patterns as discussed to target PR98772. Bootstrapped and regression tested on aarch64. [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns In the case where 8 out of every 16 elements are widened using a widening

Re: [PATCH v2] arm: Low overhead loop handle long range branches [PR98931]

2021-02-09 Thread Andrea Corallo via Gcc-patches
Jakub Jelinek writes: > On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches wrote: >> >"TARGET_32BIT && TARGET_HAVE_LOB" >> > - "le\t%|lr, %l0") >> > + "* >> > + if (get_attr_length (insn) == 4) >> > +return \"le\\t%|lr, %l0\"; >> > + else >> > +return \"subs\\

[PATCH] ICF: fix memory leak

2021-02-09 Thread Martin Liška
The following fixes a memory leak. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: PR ipa/99003 * ipa-icf.c (sem_item::add_reference): Fix memory leak when a reference exists. --- gcc/ipa-icf.c

[PATCH] if-to-switch: fix a memory leak

2021-02-09 Thread Martin Liška
The following fixes a memory leak. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: PR tree-optimization/99002 * gimple-if-to-switch.cc (find_conditions): Fix memory leak in the function. --- gc

c++: Fix indirect partitions [PR 98944]

2021-02-09 Thread Nathan Sidwell
The most recent reimplementation of module loading initialization changed the behaviour of setting an import's location, and broke some partition handling. PR c++/98944 gcc/cp/ * module.cc (module_state::is_rooted): Rename to ... (module_state::has_location):

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Julian Brown
On Tue, 9 Feb 2021 16:37:31 +0100 Thomas Schwinge wrote: > Hi! > > On 2021-02-09T13:05:22+, Julian Brown > wrote: > > On Tue, 9 Feb 2021 13:45:36 +0100 > > Tobias Burnus wrote: > > > >> On 09.02.21 12:58, Thomas Schwinge wrote: > >> >> Granted. The array(:)%re access might update too m

Re: PR 96391? Can we fix it for gcc11?

2021-02-09 Thread Qing Zhao via Gcc-patches
Richard, Thank you for the reply. Yes, I understand that without a working testing case to repeat the error, it’s very hard to debug and fix the issue. However, providing a testing case for this bug is really challenging from our side due to multiple reasons… I will discuss with our building

RE: use -mfpu=neon for arm/simd/vmmla_1.c

2021-02-09 Thread Kyrylo Tkachov via Gcc-patches
> -Original Message- > From: Gcc-patches On Behalf Of > Alexandre Oliva > Sent: 05 January 2021 07:49 > To: gcc-patches@gcc.gnu.org > Subject: use -mfpu=neon for arm/simd/vmmla_1.c > > > On some of our arm targets, we get various -mfpu flags implicitly or > explicitly passed to the co

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

2021-02-09 Thread Martin Sebor via Gcc-patches
On 2/9/21 12:41 AM, Richard Biener wrote: On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches wrote: On 2/8/21 12:09 PM, Jeff Law wrote: On 2/3/21 3:45 PM, Martin Sebor wrote: On 2/3/21 2:57 PM, Jeff Law wrote: On 1/28/21 4:03 PM, Martin Sebor wrote: The GCC 11 -Warray-bounds e

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Thomas Schwinge
Hi! On 2021-02-09T13:05:22+, Julian Brown wrote: > On Tue, 9 Feb 2021 13:45:36 +0100 > Tobias Burnus wrote: > >> On 09.02.21 12:58, Thomas Schwinge wrote: >> >> Granted. The array(:)%re access might update too much, but that's >> >> not different to array with strides or with contiguous arra

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread H.J. Lu via Gcc-patches
On Tue, Feb 9, 2021 at 6:33 AM Jakub Jelinek wrote: > > On Tue, Feb 09, 2021 at 06:25:10AM -0800, H.J. Lu via Gcc-patches wrote: > > My patch does nothing for GCC 10. > > > > > files from GCC 11 > > > and -fcf-protection=none (aka the long-year default)? > > > > > > > Yes, if __builtin_setjmp and

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 06:25:10AM -0800, H.J. Lu via Gcc-patches wrote: > My patch does nothing for GCC 10. > > > files from GCC 11 > > and -fcf-protection=none (aka the long-year default)? > > > > Yes, if __builtin_setjmp and __builtin_longjmp aren't used. > No, if they are. Therefore ABI chan

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread H.J. Lu via Gcc-patches
On Tue, Feb 9, 2021 at 6:19 AM Richard Biener wrote: > > On Tue, Feb 9, 2021 at 2:11 PM H.J. Lu wrote: > > > > On Tue, Feb 9, 2021 at 12:59 AM Richard Biener > > wrote: > > > > > > On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches > > > wrote: > > > > > > > > When the SHSTK feature is not

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread Richard Biener via Gcc-patches
On Tue, Feb 9, 2021 at 2:11 PM H.J. Lu wrote: > > On Tue, Feb 9, 2021 at 12:59 AM Richard Biener > wrote: > > > > On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches > > wrote: > > > > > > When the SHSTK feature is not available or not enabled, RDSSP is a NOP, > > > always save and restore sh

Re: [PATCH] arm: Low overhead loop handle long range branches [PR98931]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches wrote: > >"TARGET_32BIT && TARGET_HAVE_LOB" > > - "le\t%|lr, %l0") > > + "* > > + if (get_attr_length (insn) == 4) > > +return \"le\\t%|lr, %l0\"; > > + else > > +return \"subs\\t%|lr, #1\;bne\\t%l0\"; > > + "

Re: [PATCH] arm: Low overhead loop handle long range branches [PR98931]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 02:38:44PM +0100, Andrea Corallo via Gcc-patches wrote: > >From c8216ed1313d670e79b28141dadd644e698c83cf Mon Sep 17 00:00:00 2001 > From: Andrea Corallo > Date: Wed, 3 Feb 2021 15:21:54 +0100 > Subject: [PATCH] arm: Low overhead loop handle long range branches [PR98931] >

[PATCH] arm: Low overhead loop handle long range branches [PR98931]

2021-02-09 Thread Andrea Corallo via Gcc-patches
Hi all, this is to fix PR98931 where the LE (loop end, Armv8.1-M low overhead loops) instruction cannot cover sufficently long branches. In this case we emit as an alternative: subslr, #1 bne label arm-none-eabi regtested, arm-none-linux-gnueabihf boostrapped. Okay for

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread H.J. Lu via Gcc-patches
On Tue, Feb 9, 2021 at 12:59 AM Richard Biener wrote: > > On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches > wrote: > > > > When the SHSTK feature is not available or not enabled, RDSSP is a NOP, > > always save and restore shadow stack pointer to support compiling source > > codes, contain

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Julian Brown
On Tue, 9 Feb 2021 13:45:36 +0100 Tobias Burnus wrote: > On 09.02.21 12:58, Thomas Schwinge wrote: > >> Granted. The array(:)%re access might update too much, but that's > >> not different to array with strides or with contiguous arrays > >> sections which contain component reference (and more th

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Tobias Burnus
On 09.02.21 12:58, Thomas Schwinge wrote: Granted. The array(:)%re access might update too much, but that's not different to array with strides or with contiguous arrays sections which contain component reference (and more than one component). (Is that indeed allowed to "update too much"?) Yes

[committed] libstdc++: Make coroutine_handle<_Promise>::from_address() noexcept [PR 99021]

2021-02-09 Thread Jonathan Wakely via Gcc-patches
The coroutine_handle::from_address(void*) version is already noexcept, and they do the same thing. Make them consistent. libstdc++-v3/ChangeLog: PR libstdc++/99021 * include/std/coroutine (coroutine_handle::from_address): Add noexcept. Tested x86_64-linux. Committed to tr

Re: [PATCH] ix86: Support V{2,4}DImode arithmetic right shifts for SSE2+ [PR98856]

2021-02-09 Thread Richard Biener
On Tue, 9 Feb 2021, Jakub Jelinek wrote: > On Tue, Feb 09, 2021 at 12:52:55PM +0100, Richard Biener wrote: > > Yeah, it does look useful in the end. Note that you might want > > to adjust ix86_add_stmt_cost (or ix86_shift_rotate_cost, that is) > > to reflect the complex expansion. > > Yeah, the

[PATCH] Fix O(region-size) unwind in VN

2021-02-09 Thread Richard Biener
This fixes the currently O(region-size) unwinding of avail info to be O(unwind-size) by tracking a linked-list stack of pushed avails. This reduces the compile-time spent in complete unrolling for WRF and removes do_unwind from the radar of perf for the testcase. Bootstrapped and tested on x86_64

Re: [PATCH] ix86: Support V{2,4}DImode arithmetic right shifts for SSE2+ [PR98856]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 12:52:55PM +0100, Richard Biener wrote: > Yeah, it does look useful in the end. Note that you might want > to adjust ix86_add_stmt_cost (or ix86_shift_rotate_cost, that is) > to reflect the complex expansion. Yeah, the patch does that, see the i386.c hunks. I guess for V2

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Thomas Schwinge
Hi Tobias! On 2021-02-09T12:41:48+0100, Tobias Burnus wrote: > Updated patch. Changes: Testcases split + updated/extended. > OK for mainline? I don't have any further comments on the patch itself. > On 09.02.21 10:45, Thomas Schwinge wrote: >> Thanks for filing/locating these discussion items f

Re: [PATCH] ix86: Support V{2,4}DImode arithmetic right shifts for SSE2+ [PR98856]

2021-02-09 Thread Richard Biener
On Tue, 9 Feb 2021, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, we don't support arithmetic right V2DImode or > V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have > {,v}psraq instructions until AVX512VL, but we actually can emulate it quite > easily. > One case is

[Patch] Fortran: Fix coarray handling for gfc_dep_resolver [PR99010] (was: Re: [Patch] Fortran: Fix Array dependency with local coarrays [PR98913]

2021-02-09 Thread Tobias Burnus
Hi all, hi Thomas, On 02.02.21 18:15, Tobias Burnus wrote: I think I will do a combination: If 'identical' is true, I think I cannot remove it. If it is false, it can be identical or nonoverlapping – which makes sense. Well, it turned out that coarray scalars did not work; for them, the array

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Tobias Burnus
Hi Thomas, hi all Updated patch. Changes: Testcases split + updated/extended. OK for mainline? Regarding the comments: On 09.02.21 10:45, Thomas Schwinge wrote: Thanks for filing/locating these discussion items for OpenACC/OpenMP upstream. May also put these references into the testcases, so

New template for 'gcc' made available

2021-02-09 Thread Translation Project Robot
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: https://translationproject.org/POT-files/gcc

Re: [PATCH] string: Add a workaround for -Wstringop-overread false positives [PR98465]

2021-02-09 Thread Jonathan Wakely via Gcc-patches
On 09/02/21 09:57 +0100, Jakub Jelinek wrote: Hi! In the PR there are several possibilities how to improve _M_disjunct at least in certain cases so that the compiler can figure out at least in some cases where __s is provably disjunct from _M_data() ... _M_data() + this->size() but it is probabl

Re: [PATCH] c++: Private parent access check for using decls [PR19377]

2021-02-09 Thread Anthony Sharp via Gcc-patches
> > The parens are to help the editor line up the last line properly. If > the subexpression fits on one line, the parens aren't needed. A okay. No; "compile" means translate from C++ to assembly, "assemble" means > that, plus call the assembler to produce an object file. Though since > co

Re: [PATCH] Add unordered containers heterogeneous lookup

2021-02-09 Thread Jonathan Wakely via Gcc-patches
On 04/02/21 21:20 +0100, François Dumont wrote:     Considering that most of the code is already new code it doesn't look like a major tradeoff duplicate some more code.     So here is a new proposal with only new code. However I left the new few XXX_tr methods accessible even in C++11 because

Re: [PATCH][Bug libstdc++/70303] Value-initialized debug iterators

2021-02-09 Thread Jonathan Wakely via Gcc-patches
On 08/02/21 22:27 +0100, François Dumont wrote: On 01/02/21 8:09 pm, Jonathan Wakely wrote: On 01/02/21 19:30 +0100, François Dumont via Libstdc++ wrote: On 01/02/21 6:43 pm, Jonathan Wakely wrote: On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote: After the debug issue has been fix

[PATCH] ix86: Support V{2, 4}DImode arithmetic right shifts for SSE2+ [PR98856]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
Hi! As mentioned in the PR, we don't support arithmetic right V2DImode or V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have {,v}psraq instructions until AVX512VL, but we actually can emulate it quite easily. One case is arithmetic >> 63, we can just emit {,v}pxor; {,v}pcmpgt

New Ukrainian PO file for 'cpplib' (version 11.1-b20210207)

2021-02-09 Thread Translation Project Robot
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Ukrainian team of translators. The file is available at: https://translationproject.org/latest/cpplib/uk.po (This file, 'cpplib-11.1-b2021

Contents of PO file 'cpplib-11.1-b20210207.uk.po'

2021-02-09 Thread Translation Project Robot
cpplib-11.1-b20210207.uk.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

[PATCH] reduce sparseset memory requirement

2021-02-09 Thread Richard Biener
Currently we use HOST_WIDEST_FAST_INT for the sparseset element type which maps to a 64bit type on 64bit hosts. That's excessive for the only current sparseset users which are LRA and IRA and which store register numbers in it which are unsigned int. The following changes the sparseset element ty

New template for 'cpplib' made available

2021-02-09 Thread Translation Project Robot
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as: https://translationproject.org/POT-files/

Re: [PATCH] calls: Fix a memory leak in maybe_warn_rdwr_sizes [PR99004]

2021-02-09 Thread Richard Biener
On Tue, 9 Feb 2021, Jakub Jelinek wrote: > Hi! > > The print_generic_expr_to_str function ends with > return xstrdup (...); and therefore expects the caller to free > the argument. > > The following patch does that after it has been copied. > Instead of doing const_cast to cast away const char *

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

2021-02-09 Thread Thomas Schwinge
Hi Tobias! On 2021-02-08T18:50:25+0100, Tobias Burnus wrote: > Found when looking at Julian's 3/4 OpenACC patch, which has not > yet been committed (and needs still to be revised a bit.) > > The fix (a) avoids an ICE when Julian's patch has been applied. > The patch (b) just makes one error messa

[PATCH] tree-optimization/99017 - be more forgiving in BB vect costing

2021-02-09 Thread Richard Biener
This works around a SLP graph partitioning or cost collecting issue by being more forgiving in vect_bb_vectorization_profitable_p. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-02-09 Richard Biener PR tree-optimization/99017 * tree-vect-slp.c (vect_bb_vecto

Re: [PATCH] don't enable DWARF5 by default on Windows (PR98860)

2021-02-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Feb 09, 2021 at 07:47:00AM +0100, Richard Biener via Gcc-patches wrote: > On February 8, 2021 10:44:26 PM GMT+01:00, Mikael Pettersson via Gcc-patches > wrote: > >PR98860 is a gcc-11 regression where bootstrap fails on Windows since > >the switch to enable DWARF5 by default. The symptoms

Re: [PATCH] x86: Always save and restore shadow stack pointer

2021-02-09 Thread Richard Biener via Gcc-patches
On Mon, Feb 8, 2021 at 3:07 PM H.J. Lu via Gcc-patches wrote: > > When the SHSTK feature is not available or not enabled, RDSSP is a NOP, > always save and restore shadow stack pointer to support compiling source > codes, containing __builtin_setjmp and __builtin_longjmp, with different > -fcf-pro

Re: [RFC] ldist: Recognize rawmemchr loop patterns

2021-02-09 Thread Richard Biener via Gcc-patches
On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via Gcc-patches wrote: > > This patch adds support for recognizing loops which mimic the behaviour > of function rawmemchr, and replaces those with an internal function call > in case a target provides them. In contrast to the original ra

[PATCH] string: Add a workaround for -Wstringop-overread false positives [PR98465]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
Hi! In the PR there are several possibilities how to improve _M_disjunct at least in certain cases so that the compiler can figure out at least in some cases where __s is provably disjunct from _M_data() ... _M_data() + this->size() but it is probably GCC 12 material. The false positive warning i

Re: [PATCH] gcov: use mmap pools for KVP.

2021-02-09 Thread Martin Liška
PING^2 @Honza: ? On 1/29/21 2:33 PM, Martin Liška wrote: PING^1 On 1/25/21 1:51 PM, Martin Liška wrote: On 1/22/21 3:33 PM, Jan Hubicka wrote: It is definitly doable (gcov machinery is quite flexible WRT having more types of counters). Yes, that would introduce back the dropped TOPN counte

[PATCH] calls: Fix a memory leak in maybe_warn_rdwr_sizes [PR99004]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
Hi! The print_generic_expr_to_str function ends with return xstrdup (...); and therefore expects the caller to free the argument. The following patch does that after it has been copied. Instead of doing const_cast to cast away const char * to char *, because the code uses s0 and s1 in so few plac

[PATCH] c++: Consider addresses of heap artificial vars always non-NULL [PR98988]

2021-02-09 Thread Jakub Jelinek via Gcc-patches
Hi! With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Still, I think malloc/operator new (at least the no

Re: PR 96391? Can we fix it for gcc11?

2021-02-09 Thread Richard Biener
On Mon, 8 Feb 2021, Qing Zhao wrote: > Hi, > > The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 > > > Bug 96391 - [10/11 Regression] internal compiler error: in > linemap_compare_locations, at libcpp/line-map.c:1359 > > has been