[PUSHED] Fix i686 bootstrap by temporarily disabling exporting of global ranges.

The patch converting evrp to the get_range_query(fun) API broke i686 bootstrap (commit 57bf37515). The problem seems to be in a subsequent pass that has more up-to-date global ranges. I won't be able to look at this until next week, so I am reverting the problematic bit of the patch-- the

Re: [PATCH 1/5] Common API for accessing global and on-demand ranges.

On 5/25/2021 10:16 AM, Aldy Hernandez via Gcc-patches wrote: The interface is now an inline function for get_range_query() and an external function for get_global_range_query), as discussed. There are no magic cfun uses behind the scenes. The annoying downcast is gone. Passes can now

Re: [PATCH] Move global range code to value-query.cc.

On 5/27/2021 2:39 AM, Aldy Hernandez via Gcc-patches wrote: As discussed... This patch moves all the global range code from gimple-range.cc into value-query.cc. It also moves get_range_info and get_ptr_nonnull from tree-ssanames.c into their only uses, and removes external access to them.

Re: [PATCH 1/2] Implement generic expression evaluator for range_query.

On 5/27/2021 2:55 AM, Aldy Hernandez via Gcc-patches wrote: Right now, range_of_expr only works with constants, SSA names, and pointers. Anything else gets returned as VARYING. This patch adds the capability to deal with arbitrary expressions, inasmuch as these tree codes are implemented in

Re: [PATCH] sim: leverage gnulib

On 5/28/2021 8:55 PM, Mike Frysinger via Gcc-patches wrote: We use getline, so leverage gnulib to provide fallback implementation. ChangeLog: * configure.ac: Add gnulib to configdirs for sim. * configure: Regenerate. OK jeff

[PATCH] sim: leverage gnulib

We use getline, so leverage gnulib to provide fallback implementation. ChangeLog: * configure.ac: Add gnulib to configdirs for sim. * configure: Regenerate. --- configure| 3 +++ configure.ac | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configure b/configure index

[Patch, fortran] PR fortran/100120/100816/100818/100819/100821 problems raised by aggregate data types

Hi all! Proposed patch to: Bug 100120 - associated intrinsic failure Bug 100816 - Wrong span on widechar Bug 100818 - A temporary is passed to associated Bug 100819 - Wrong code generation with unlimited polymorphic objects and character type Bug 100821 - Deferred character with wrong length

[DWARF] Also generate DW_OP_GNU_variable_value at file scope

But only for the reference variant (dw_val_class_die_ref). This is needed for variable-sized types declared at library level in Ada. Tested on x86-64/Linux, both GCC and GDB, OK for the mainline? 2021-05-28 Eric Botcazou * dwarf2out.c (loc_list_from_tree_1) : Also generate

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

Hello, On Fri, 28 May 2021, Bernd Edlinger wrote: > >> I was wondering, why gimple-match.c and generic-match.c > >> are not built early but always last, which slows down parallel > >> makes significantly. > >> > >> The reason seems to be that generated_files does not > >> mention gimple-match.c

[PATCH][RFC] tree-optimization/100801 - perform final value replacement from VRP

This makes sure to perform final value replacement of constants when we also are sure to propagate those, like in VRP. This avoids spurious diagnostics when doing so only from within SCCP which can leave unreachable loops in the IL triggering bogus diagnostics. The choice is VRP because it

Re: Fallout: save/restore target options in handle_optimize_attribute

Hi! On Fri, May 28, 2021 at 11:48:06AM +0200, Martin Liška wrote: > There's a fallout after my revision > ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e. I would like to analyze > all case and discuss possible solution. To be honest it's a can of worms > and reverting the commit > is an option on the

Re: [PATCH] PING implement pre-c++20 contracts

Hello again :) Wanted to shoot a quick status update. Some github issues have been created for points of feedback, and we've been working on addressing them. A few changes have been pushed to the contracts-jac-alt branch, while there's also an active more in depth rewrite branch. Some specific

[PATCH] tree-optimization/100778 - avoid cross-BB vectorization of trapping op

This avoids vectorizing a possibly trapping operation when lanes are handled in different BBs. I spotted this when working on the originally reported issue in PR100778. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-05-28 Richard Biener PR tree-optimization/100778

Re: Fallout: save/restore target options in handle_optimize_attribute

On Fri, May 28, 2021 at 11:48 AM Martin Liška wrote: > > Hi. > > There's a fallout after my revision ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e. > I would like to analyze > all case and discuss possible solution. To be honest it's a can of worms and > reverting the commit > is an option on the

[PATCH] diagnostics: Fix sporadic test failure

Hi, it turns out to be reproducible this way: COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*" Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ... FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c

[PATCH] ipa/100791 - copy fntype when processing __builtin_va_arg_pack

This missing copying exposed a type mismatch in the IL. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-05-28 Richard Biener * tree-inline.c (copy_bb): When processing __builtin_va_arg_pack copy fntype from original call. * gcc.dg/pr100791.c: New

[PATCH] c/100803 - diagnose invalid GIMPLE condition

another easy fix for GIMPLE FE parser robustness. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-05-28 Richard Biener PR c/100803 gcc/c/ * gimple-parser.c (c_parser_gimple_paren_condition): Diagnose invalid if conditions. gcc/testsuite/ *

[PATCH] C-SKY: Define HAVE_sync_compare_and_swap*.

From: Cooper Qu Tested and pushed. The SYNC operations are implemented as library functions, not NSN patterns. As a result, the HAVE defines for the patterns are not defined. We need to define them to generate the corresponding __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* and __GCC_ATOMIC_*_LOCK_FREE

Fallout: save/restore target options in handle_optimize_attribute

Hi. There's a fallout after my revision ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e. I would like to analyze all case and discuss possible solution. To be honest it's a can of worms and reverting the commit is an option on the table. So the cases: 1) PR100759 - ppc64le $ cat pr.C #pragma GCC

[committed] openmp: Fix up handling of reduction clause on constructs combined with target [PR99928]

Hi! The reduction clause should be copied as map (tofrom: ) to combined target if present, but as we need different handling of array sections between map and reduction, doing that during gimplification would be harder. So, this patch adds them during splitting, and similarly to firstprivate

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

On Fri, May 28, 2021 at 09:33:14AM +0200, Bernd Edlinger wrote: > > This should help for what I was complaining about in > > https://gcc.gnu.org/pipermail/gcc/2021-May/235963.html . I build with > > -j24 and it was stalling on compiling gimple-match.c for me. > > Looks like insn-attrtab.c is

[PATCH] For obj-c stage-final re-use the checksum from the previous stage

Hi Richard, I've replicated your PR to make the objective-c checksum compare equal commit fb2647aaf55b453b37badfd40c14c59486a74584 Author: Richard Biener Date: Tue May 3 08:14:27 2016 + Make-lang.in (cc1-checksum.c): For stage-final re-use the checksum from the previous stage.

Re: [PATCH] Add gnu::diagnose_as attribute

On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote: > On 5/27/21 6:07 PM, Matthias Kretz wrote: > > On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote: > >> On 5/27/21 2:54 PM, Matthias Kretz wrote: > >>> namespace Vir { > >>> inline namespace foo { > >>> struct A {}; > >>>

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

On 5/28/21 9:26 AM, Andrew Pinski wrote: > On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger > wrote: >> >> Hi, >> >> I was wondering, why gimple-match.c and generic-match.c >> are not built early but always last, which slows down parallel >> makes significantly. >> >> The reason seems to be that

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger wrote: > > Hi, > > I was wondering, why gimple-match.c and generic-match.c > are not built early but always last, which slows down parallel > makes significantly. > > The reason seems to be that generated_files does not > mention gimple-match.c and

Re: [PATCHv2] Add a couple of A?CST1:CST2 match and simplify optimizations

On Fri, May 28, 2021 at 7:21 AM Jeff Law via Gcc-patches wrote: > > > > On 5/26/2021 11:29 AM, Andrew MacLeod via Gcc-patches wrote: > > On 5/26/21 7:07 AM, Andrew Pinski wrote: > >> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski wrote: > >>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger > >>>

Re: [PATCH RFA] tree-iterator: C++11 range-for and tree_stmt_iterator

On Wed, May 26, 2021 at 3:56 PM Jason Merrill wrote: > > Ping. The non-C++ parts are OK. Richard. > On 5/17/21 1:58 PM, Jason Merrill wrote: > > On 5/17/21 3:56 AM, Richard Biener wrote: > >> On Fri, May 14, 2021 at 2:23 AM Martin Sebor via Gcc-patches > >> wrote: > >>> > >>> On 5/13/21 1:26

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

On 5/28/21 8:41 AM, Richard Biener wrote: > On Fri, 28 May 2021, Bernd Edlinger wrote: > >> >> >> On 5/28/21 6:42 AM, Bernd Edlinger wrote: >>> Hi, >>> >>> I was wondering, why gimple-match.c and generic-match.c >>> are not built early but always last, which slows down parallel >>> makes

Re: [PATCH] Generate gimple-match.c and generic-match.c earlier

On Fri, 28 May 2021, Bernd Edlinger wrote: > > > On 5/28/21 6:42 AM, Bernd Edlinger wrote: > > Hi, > > > > I was wondering, why gimple-match.c and generic-match.c > > are not built early but always last, which slows down parallel > > makes significantly. > > > > The reason seems to be that

Re: [PATCH v2] forwprop: Support vec perm fed by CTOR and CTOR/CST [PR99398]

on 2021/5/27 下午8:55, Richard Sandiford wrote: > Sorry for the slow reponse. > > "Kewen.Lin" writes: >> diff --git a/gcc/vec-perm-indices.c b/gcc/vec-perm-indices.c >> index ede590dc5c9..57dd11d723c 100644 >> --- a/gcc/vec-perm-indices.c >> +++ b/gcc/vec-perm-indices.c >> @@ -101,6 +101,70 @@