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

On Thu, Jan 28, 2021 at 6:04 PM Martin Sebor via Gcc-patches wrote: > > The GCC 11 -Warray-bounds enhancement to diagnose accesses whose > leading offset is in bounds but whose trailing offset is not has > been causing some confusion. When the warning is issued for > an access to an in-bounds

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On 1/29/21 6:28 PM, Marek Polacek wrote: On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches wrote: On 1/29/21 5:52 PM, Marek Polacek wrote: On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches wrote: On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek

PING [PATCH] improve warning suppression for inlined functions (PR 98465, 98512)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html On 1/21/21 4:46 PM, Martin Sebor wrote: The initial patch I posted is missing initialization for a couple of locals.  I'd noticed it in testing but forgot to add the fix to the patch before posting it.  I have corrected

libgo patch committed: Correct reference to getsystemcgf

This libgo patch by Clément Chigot directly sets getsystemcfg as //extern in internal/cpu instead of trying to use the runtime as in Go toolchain. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian 7da2394fc591a3fb236190c8712f3960a4ee8e5f diff --git

Re: [PATCH, rs6000] Optimization for PowerPC 64bit constant generation [PR94395]

On Fri, 2021-01-29 at 11:11 +0800, HAO CHEN GUI via Gcc-patches wrote: > Hi, > Hi, just a couple cosmetic nits below. Thanks, > This patch tries to optimize PowerPC 64 bit constant generation > when > the constant can be transformed from a 32 bit or 16 bit constant by > rotating,

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/29/21 5:52 PM, Marek Polacek wrote: > > On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches > > wrote: > > > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches > > >

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On 1/29/21 5:52 PM, Marek Polacek wrote: On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches wrote: On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote: __builtin_has_attribute doesn't work in templates yet (bug 92104), so in r11-471 I added a

Re: [PATCH] c++: Fix ICE in verify_ctor_sanity [PR98295]

On 1/29/21 12:28 PM, Patrick Palka wrote: In this testcase we're crash during constexpr evaluation of the ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b (which is encoded as a VEC_INIT_EXPR). Since A's default constructor is not yet defined, b's initializer is not actually

[PATCH] libcpp: Fix up -fdirectives-only preprocessing [PR98882]

Hi! GCC 11 ICEs on all -fdirectives-only preprocessing when the files don't end with a newline. The problem is in the assertion, for empty TUs buffer->cur == buffer->rlimit and so buffer->rlimit[-1] access triggers UB in the preprocessor, for non-empty TUs it refers to the last character in the

Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches wrote: > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote: > > __builtin_has_attribute doesn't work in templates yet (bug 92104), so > > in r11-471 I added a sorry. But that only caught

[committed] [rs6000] Fix typo in gcc.target/pr91903.c dg-require stanza

[PATCH, rs6000] Fix typo in gcc.target/pr91903.c dg-require stanza Hi, I somehow messed up when I tested this change.. Committed as obvious, also had pre-approval blessing per offline discussion. Fix obvious typo in testcases dg-require stanza. 2021-01-29 Will Schmidt

Re: [PATCH] PR target/98870: Fix IEEE 128-bit fortran test

Hi! On Fri, Jan 29, 2021 at 01:44:03PM -0500, Michael Meissner wrote: > This test started failing when I changed the mapping of IEEE 128-bit long > double built-in functions on 2021-01-28. This patch fixes the test so it > uses the correct name. > gcc/testsuite/ > 2021-01-29 Michael Meissner

Re: Default to DWARF5

Hi Paul, On Fri, Jan 29, 2021 at 02:04:02PM -0600, Paul A. Clarke wrote: > On Fri, Jan 29, 2021 at 12:22:41PM +0100, Mark Wielaard wrote: > > The infinite loop is because off isn't updated to noff before calling > > continue in the while loop. Moving the last line of the loop off = > > noff; to

Re: [PATCH] Add conversions between _Float128 and Decimal.

On Fri, Jan 29, 2021 at 03:45:49PM -0600, will schmidt wrote: > On Thu, 2021-01-28 at 21:42 -0500, Michael Meissner via Gcc-patches wrote: > > [PATCH] Add conversions between _Float128 and Decimal. > > > > Hi, > Just a couple cosmetic nits in the description. The changelog seems to > match

Re: [PATCH] Add conversions between _Float128 and Decimal.

On Thu, 2021-01-28 at 21:42 -0500, Michael Meissner via Gcc-patches wrote: > [PATCH] Add conversions between _Float128 and Decimal. > Hi, Just a couple cosmetic nits in the description. The changelog seems to match that patch contents OK. > This patch implements conversions between

Re: [PATCH] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote: > __builtin_has_attribute doesn't work in templates yet (bug 92104), so > in r11-471 I added a sorry. But that only caught type-dependent > expressions and we also want to sorry on value-dependent expressions. > This

[committed] [PR97701] Modify test for trunk

commit 0202fa3d6359911a9e6d605d33d0ac669e21eaf3 Author: Vladimir N. Makarov Date: Fri Jan 29 16:04:03 2021 -0500 [PR97701] Modify test for trunk Original test was for gcc-10. The modified one for trunk. gcc/testsuite/ChangeLog: PR target/97701

[PATCH] c++: Improve sorry for __builtin_has_attribute [PR98355]

__builtin_has_attribute doesn't work in templates yet (bug 92104), so in r11-471 I added a sorry. But that only caught type-dependent expressions and we also want to sorry on value-dependent expressions. This patch uses v_d_e_p rather than uses_template_parms because u_t_p sets p_t_d and then

[PATCH] i386, df: Fix up gcc.c-torture/compile/20051216-1.c -O1 -march=cascadelake

On Fri, Jan 29, 2021 at 11:18:54AM -0800, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, > > a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c is the first bad commit > commit a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c > Author: Richard Biener > Date: Fri Jan 29 16:02:36 2021 +0100 > >

[committed] analyzer: consolidate conditionals in paths

This patch adds a simplification to analyzer paths for repeated CFG edges generated from compound conditionals. For example, it simplifies: |5 | if (a && b && c) | | ^~~~ | | | || | | | |(4) ...to here | | | |

Re: Default to DWARF5

On Fri, Jan 29, 2021 at 12:22:41PM +0100, Mark Wielaard wrote: > On Thu, Jan 28, 2021 at 08:25:20PM -0600, Paul A. Clarke wrote: > > The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a > > failure in the test suite for the IBM Advance Toolchain. The test in > > question uses

Re: [PATCH 2/2] RISC-V: Add riscv{32, 64}be with big endian as default

Kito Cheng writes: >> diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h >> index 973efdaed7b..7e65e499031 100644 >> --- a/gcc/config/riscv/elf.h >> +++ b/gcc/config/riscv/elf.h >> @@ -18,7 +18,7 @@ along with GCC; see the file COPYING3. If not see >>

[committed] [PR97701] LRA: Don't narrow class only for REG or MEM.

The following patch solves    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701 The patch was successfully bootstrapped and tested on x86-64, arm64, ppc64be. This patch variant is only for trunk.  GCC-10 branch will have a bit different patch. commit

Re: [PATCH 1/2] RISC-V: Support -mlittle-endian and -mbig-endian

Kito Cheng writes: > Could you document -mbig-endian and -mlittle-endian in gcc/doc/invoke.texi? Sure, I'll add that. // Marcus

Re: [PATCH 0/2] RISC-V big endian support

Hi Kito, Kito Cheng writes: > You can add a check in configure.ac and config.in to detect whether > binutils is supported or not. > here is example, search HAVE_AS_MISA_SPEC in this patch: > https://github.com/gcc-mirror/gcc/commit/4b81528241ca682025d92558ff6aeec91dafdca8 Ok, but I

[r11-6981 Regression] FAIL: gcc.c-torture/compile/20051216-1.c -O1 (test for excess errors) on Linux/x86_64

On Linux/x86_64, a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c is the first bad commit commit a7f52181a6a16bb6d216ff41d9c6a9da95c19b5c Author: Richard Biener Date: Fri Jan 29 16:02:36 2021 +0100 rtl-optimization/98863 - tame i386 specific RPAD pass caused FAIL:

libgo: update to Go1.16rc1 release

This patch updates libgo to the Go1.16rc1 release (the first 1.16 release candidate). Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to mainline. The diffs are too large to attach, so I've trimmed out some uninteresting changes to generated files. They are of course available

[PATCH] PR target/98870: Fix IEEE 128-bit fortran test

PR target/98870: Fix IEEE 128-bit fortran test This test started failing when I changed the mapping of IEEE 128-bit long double built-in functions on 2021-01-28. This patch fixes the test so it uses the correct name. I have tested this patch and the test now passes. Can I check it into the

Re: [PATCH] aarch64: Remove testing of saturation cumulative QC bit

On Tue, 19 Jan 2021 at 18:31, Kyrylo Tkachov via Gcc-patches wrote: > > Hi all, > > Since we don't guarantee the ordering of the QC flag in FPSR in the > saturation intrinsics, we shouldn't be testing for it. > I want to relax the flags for some of the builtins to enable more > optimisation but

Re: [PATCH] arm: Auto-vectorization for MVE: vorn

On Fri, 29 Jan 2021 at 16:03, Kyrylo Tkachov wrote: > > > > > -Original Message- > > From: Gcc-patches On Behalf Of > > Christophe Lyon via Gcc-patches > > Sent: 29 January 2021 14:55 > > To: gcc-patches@gcc.gnu.org > > Subject: [PATCH] arm: Auto-vectorization for MVE: vorn > > > > This

Re: [Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Hi Tobias, Yes, I am aware of the memory leaks. Valgrind, in spite of the dwarf problem, reports definite loss of 3 blocks of 24bytes. This leak from constructors goes back a very long way (PR38319). I have periodically had a stab at fixing it but, thus far, have not successfully eliminated it

[PATCH] c++: Fix ICE in verify_ctor_sanity [PR98295]

In this testcase we're crash during constexpr evaluation of the ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b (which is encoded as a VEC_INIT_EXPR). Since A's default constructor is not yet defined, b's initializer is not actually constant, but because A is an empty type,

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

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563894.html On 1/19/21 5:56 PM, Martin Sebor wrote: Similar to the problem reported for -Wstringop-overflow in pr98266 and already fixed, -Warray-bounds is also susceptible to false positives in assignments and copies involving

Re: c++: cross-module __cxa_atexit use [PR 98531]

As Rainer pointed out, there were some regressions in the library tests. That's because we didn't build the correct ehspec for __cxa_atexit. This adds that, but also, I realize we can use the 'hidden' flag on pushdecl to make this lazy-builtin not visible to user name lookup without them

PING [PATCH] correct fix to avoid false positives for vectorized stores (PR 96963, 94655)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564059.html On 1/21/21 4:38 PM, Martin Sebor wrote: The hack I put in compute_objsize() last January for pr93200 isn't quite correct.  It happened to suppress the false positive there but, due to what looks like a thinko on my part,

c++: Fix unordered entity array [PR 98843]

A couple of module invariants are that the modules are always allocated in ascending order and appended to the module array. The entity array is likewise ordered, with each module having spans in that array in ascending order. Prior to header-units, this was provided by the way import

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

On Fri, Jan 29, 2021 at 05:27:13PM +0100, Richard Biener wrote: > > > + df_process_deferred_rescans (); > > > > rather than here? > > The pass these days does two separate optimizations, and only one of those > > creates the use uninitialized pseudo and at the end initialize it. > > The other

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

On Fri, 29 Jan 2021, Jakub Jelinek wrote: > On Fri, Jan 29, 2021 at 04:43:49PM +0100, Richard Biener wrote: > > 2021-01-29 Richard Biener > > > > PR rtl-optimization/98863 > > * config/i386/i386-features.c (remove_partial_avx_dependency): > > Do not perform DF analysis. > >

Re: [PATCH] tree-optimization/98866 - Compile time hog in VRP

On Fri, Jan 29, 2021 at 4:30 PM Andrew MacLeod via Gcc-patches wrote: > > Ranger spends a lot of time tracking pointer type ssa_names which are > initialized to non-null, ie (a_2 = ). This turns out to be a waste > of effort. > > Pointers can effectively have one of 3 values we care about:

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

On Fri, Jan 29, 2021 at 04:43:49PM +0100, Richard Biener wrote: > 2021-01-29 Richard Biener > > PR rtl-optimization/98863 > * config/i386/i386-features.c (remove_partial_avx_dependency): > Do not perform DF analysis. > (pass_data_remove_partial_avx_dependency): Remove >

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

On Fri, 29 Jan 2021, Jan Hubicka wrote: > > On Fri, 29 Jan 2021, Jan Hubicka wrote: > > > > > > This removes adding very expensive DF problems which we do not > > > > use and which somehow cause 5GB of memory to leak. > > Reading through the logs, isn't the leak just caused by tings going to >

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

> On Fri, 29 Jan 2021, Jan Hubicka wrote: > > > > This removes adding very expensive DF problems which we do not > > > use and which somehow cause 5GB of memory to leak. Reading through the logs, isn't the leak just caused by tings going to memory pool that we do not trim during late

Re: [PATCH] diagnostics: Support for -finput-charset [PR93067]

On Tue, Jan 26, 2021 at 04:02:52PM -0500, David Malcolm wrote: > On Fri, 2020-12-18 at 18:03 -0500, Lewis Hyatt wrote: > > Hello- > > > > The attached patch addresses PR93067: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0 > > > > This is similar to the patch I posted last year on the

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

On Fri, 29 Jan 2021, Jan Hubicka wrote: > > This removes adding very expensive DF problems which we do not > > use and which somehow cause 5GB of memory to leak. > > Impressive :) > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > > > 2021-01-29 Richard Biener > > > >

Re: [PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

> This removes adding very expensive DF problems which we do not > use and which somehow cause 5GB of memory to leak. Impressive :) > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > 2021-01-29 Richard Biener > > PR rtl-optimization/98863 > *

[PATCH] rtl-optimization/98863 - tame i386 specific RPAD pass

This removes adding very expensive DF problems which we do not use and which somehow cause 5GB of memory to leak. Bootstrap & regtest running on x86_64-unknown-linux-gnu. 2021-01-29 Richard Biener PR rtl-optimization/98863 * config/i386/i386-features.c

Re: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp tests [PR98738]

On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote: > The detach support clearly needs more work, but is this particular patch > okay for trunk? Sorry for the delay. I'm afraid it is far from being ready. > @@ -2402,17 +2437,41 @@ ialias (omp_in_final) > void >

RE: [PATCH] arm: Auto-vectorization for MVE: vorn

> -Original Message- > From: Gcc-patches On Behalf Of > Christophe Lyon via Gcc-patches > Sent: 29 January 2021 14:55 > To: gcc-patches@gcc.gnu.org > Subject: [PATCH] arm: Auto-vectorization for MVE: vorn > > This patch enables MVE vornq instructions for auto-vectorization. MVE >

Re: [Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Hi Paul, On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote: Regtests on FC33/x86_64 OK for master (and maybe for 10-branch?) The patch by itself looks good to me, but gfortran-trunk assumed_rank_20.f90 -fsanitize=address,undefined -g shows three times the warning: Direct leak of 12

[PATCH] arm: Auto-vectorization for MVE: vorn

This patch enables MVE vornq instructions for auto-vectorization. MVE vornq insns in mve.md are modified to use ior instead of unspec expression to support ior3. The ior3 expander is added to vec-common.md 2021-01-29 Christophe Lyon gcc/ * config/arm/iterators.md (supf):

[PATCH] tree-optimization/98866 - Compile time hog in VRP

Ranger spends a lot of time tracking pointer type ssa_names which are initialized to non-null, ie (a_2 = ). This turns out to be a waste of effort. Pointers can effectively  have one of 3 values we care about: VARYING, [0,0], or [1, +INF].   If an ssa_name is globally [0,0] or [1, +INF], the

[Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Fixing the different variants of this PR was somewhat like drawing teeth. Fixing the scalar problem with derived type and class formal arguments was straightforward. However, the need to strip NOPS for scalar unlimited polymorphic arguments was less than obvious. Even less obvious was the problem

RE: [PATCH] aarch64: Use RTL builtins for [su]mull_n intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 29 January 2021 13:49 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mull_n intrinsics > > Hi, > > As subject, this patch rewrites [su]mull_n Neon intrinsics to use RTL

[PATCH] aarch64: Use RTL builtins for [su]mull_n intrinsics

Hi, As subject, this patch rewrites [su]mull_n Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu - no issues. Ok for master? Thanks, Jonathan gcc/ChangeLog:

[PATCH] aarch64: Reimplement vabal* intrinsics using builtins

Hi all, This patch reimplements the vabal intrinsics with builtins. The RTL pattern is cleaned up to emit the right .8b suffixes for the inputs (though .16b is also accepted) and iterate over the right modes. The pattern's only other use is through the sadv16qi expander, which is adjusted.

[PATCH] aarch64: Re-implement vabal_high* intrinsics using builtins

Hi all, This patch reimplements the vabal_high* intrinsics using RTL builtins. It's straightforward, defining new unspecs and a new pattern. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. Pushing to master. Thanks, Kyrill gcc/ChangeLog: *

[PATCH] aarch64: Reimplement vabdl_high* intrinsics using builtins

Hi all, This patch reimplements the vabdl_high intrinsics using builtins. It slightly cleans up the RTL pattern (the mode iterators) but nothing interesting apart from that. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. Pushing to trunk. Thanks, Kyrill

[PATCH] aarch64: Reimplement vaddlv* intrinsics using builtins

Hi all, This patch reimplements the vaddlv* intrinsics using builtins. The vaddlv_s32 and vaddlv_u32 intrinsics actually perform a pairwise SADDLP/UADDLP instead of a SADDLV/UADDLV but because they only use two elements it has the same semantics. Bootstrapped and tested on

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

PING^4 On 1/22/21 2:33 PM, Martin Liška wrote: PING^3 On 1/14/21 10:03 AM, Martin Liška wrote: PING^2 On 1/6/21 3:21 PM, Martin Liška wrote: PING On 12/4/20 2:30 PM, Martin Liška wrote: On 12/4/20 10:03 AM, Richard Biener wrote: Otherwise 0001- looks good to me. Pushed that to master.

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

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 counters which I intentionally dropped. We could bring back

RE: [PATCH] aarch64: Use RTL builtins for [su]mlsl_lane[q] intrinsics

> -Original Message- > From: Jonathan Wright > Sent: 29 January 2021 12:56 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH] aarch64: Use RTL builtins for [su]mlsl_lane[q] intrinsics > > Hi, > > As subject, this patch rewrites [su]mlsl_lane[q] Neon intrinsics to

[PATCH] change unit of --param max-gcse-memory to kB

This changes it from bytes to kB since its value is limited to 2147483648. Bootstrap running on x86_64-unknown-linux-gnu, will push to trunk (but only there). 2021-01-29 Richard Biener * doc/invoke.texi (--param max-gcse-memory): Document unit of size. * gcse.c

[PATCH] aarch64: Use RTL builtins for [su]mlsl_lane[q] intrinsics

Hi, As subject, this patch rewrites [su]mlsl_lane[q] Neon intrinsics to use RTL builtins rather than inline assembly code, allowing for better scheduling and optimization. Regression tested and bootstrapped on aarch64-none-linux-gnu and aarch64_be-none-elf - no issues. Ok for master? Thanks,

[PATCH] rtl-optimization/98863 - fix PRE/CPROP memory usage check

This fixes overflow of the memory usage estimate in turn failing to disable itself on WRF with LTO, causing a few GBs worth of memory peak. Bootstrap and regtest running on x86_64-unknown-linux-gnu, will apply as obvious if that succeeds. Thanks, Richard. 2021-01-29 Richard Biener

Re: Default to DWARF5

Hi Paul, On Thu, Jan 28, 2021 at 08:25:20PM -0600, Paul A. Clarke wrote: > The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a > failure in the test suite for the IBM Advance Toolchain. The test in > question uses "perf probe" to set a tracepoint at "main" in a newly built >

Re: [Patch, fortran] PR93924/5 - [OOP] ICE with procedure pointer

On 27.01.21 12:52, Paul Richard Thomas via Fortran wrote: It would be nice to have the patch for PR98573 (posted 23rd Jan) OK'd before the end of the week. I've just sent some comments (albeit: Thomas has okayed it). This patch fixes PRs 93924/5. It is another 'obvious' patch, whose

Re: [Patch, fortran] PR98573 - Dynamic type lost on assignment

On 23.01.21 10:04, Paul Richard Thomas via Fortran wrote: This is a relatively obvious patch. The chunk in trans-array.c is not part of the fix for the PR but does suppress some of the bad dtype's that arise from allocation of class objects. Do you have a testcase for it? Either behavioral

RE: [PATCH] arm: Fix up -mcpu=iwmmxt ICEs [PR98849]

> -Original Message- > From: Jakub Jelinek > Sent: 29 January 2021 09:29 > To: Richard Earnshaw ; Ramana > Radhakrishnan ; Kyrylo Tkachov > > Cc: gcc-patches@gcc.gnu.org; Christophe Lyon > Subject: [PATCH] arm: Fix up -mcpu=iwmmxt ICEs [PR98849] > > Hi! > > The >

Re: [PATCH] rtl-optimization/98144 - tame REE memory usage

On Fri, Jan 29, 2021 at 10:51:59AM +0100, Richard Biener wrote: > This changes the REE dataflow to change the explicit all-ones > starting solution to be implicit via a visited flag, removing > the need to initially start with fully populated bitmaps for > all basic-blocks. That reduces peak

Re: [PATCH PR97627]Avoid computing niters info for fake edges

On Fri, Jan 29, 2021 at 10:41 AM Bin.Cheng wrote: > > On Fri, Jan 29, 2021 at 3:55 PM Richard Biener > wrote: > > > > On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote: > > > > > > On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches > > > wrote: > > > > > > > > On Thu, Jan 28, 2021

[PATCH] rtl-optimization/98144 - tame REE memory usage

This changes the REE dataflow to change the explicit all-ones starting solution to be implicit via a visited flag, removing the need to initially start with fully populated bitmaps for all basic-blocks. That reduces peak memory use when compiling the RTL checking enabled insn-extract.c testcase

Re: [PATCH PR97627]Avoid computing niters info for fake edges

On Fri, Jan 29, 2021 at 3:55 PM Richard Biener wrote: > > On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote: > > > > On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches > > wrote: > > > > > > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches > > > wrote: > > > > > > > > Hi, >

[PATCH] arm: Fix up -mcpu=iwmmxt ICEs [PR98849]

Hi! The https://gcc.gnu.org/r11-6707-g7432f255b70811dafaf325d94036ac580891de69 https://gcc.gnu.org/r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7 changes moved the vashl/vashr/vlshr expanders from neon.md to vec-common.md and changed their condition from TARGET_NEON to ARM_HAVE__ARITH, so

Re: [PATCH] expand: Fix up find_bb_boundaries [PR98331]

On Fri, 29 Jan 2021, Jakub Jelinek wrote: > Hi! > > When expansion emits some control flow insns etc. inside of a former GIMPLE > basic block, find_bb_boundaries needs to split it into multiple basic > blocks. > The code needs to ignore debug insns in decisions how many splits to do or > where

[PATCH] expand: Fix up find_bb_boundaries [PR98331]

Hi! When expansion emits some control flow insns etc. inside of a former GIMPLE basic block, find_bb_boundaries needs to split it into multiple basic blocks. The code needs to ignore debug insns in decisions how many splits to do or where in between some non-debug insns the split should be done,

Re: [PATCH 2/2] RISC-V: Add riscv{32, 64}be with big endian as default

> diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h > index 973efdaed7b..7e65e499031 100644 > --- a/gcc/config/riscv/elf.h > +++ b/gcc/config/riscv/elf.h > @@ -18,7 +18,7 @@ along with GCC; see the file COPYING3. If not see > . */ > > #define LINK_SPEC

Re: [PATCH 1/2] RISC-V: Support -mlittle-endian and -mbig-endian

Could you document -mbig-endian and -mlittle-endian in gcc/doc/invoke.texi? On Tue, Jan 26, 2021 at 2:16 AM Marcus Comstedt wrote: > > gcc/ > * config/riscv/elf.h (LINK_SPEC): Pass linker endianness flag. > * config/riscv/freebsd.h (LINK_SPEC): Likewise. > *

Re: [PATCH 0/2] RISC-V big endian support

Hi Marcus: > * Implicitly pass default endianness as -mbig-endian / -mlittle-endian > to gas, since older binutils targeting little endian will not understand > -mlittle-endian. Instead assume gas has the same default as gcc. > If -mbig-endian or -mlittle-endian is explicitly given, it is