Re: std:vec for classes with constructor?

On 8/6/20 6:30 PM, Jonathan Wakely wrote: On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote:

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Thu, 6 Aug 2020, Maciej W. Rozycki via Gcc-patches wrote: > Given that for the `riscv64-linux-gnu' target and the ilp32d multilib > glibc currently fails to link against libgcc.a built at -O0 I first ran > reference testing with target libraries built at -O2, but comparing that > to

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi! On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: > Jeff might be, but with the intended purpose (ROP mitigation AFAIU) > it would be nice for other target maintainers to chime in (Segher for > power maybe) for the question below... It would be nice if this described anywhere

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote: > On 8/5/20 7:29 PM, Marek Polacek wrote: > > On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote: > > > On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: > > > > On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump

Re: RFC: Monitoring old PRs, new dg directives

On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote: > >> XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error) >> PASS: g++.dg/foo.C -std=c++17 (test for excess errors) >> Which one of these would you not like to see? > > Neither of these is solving the issue. How do I find the ICES that

Re: [PATCH][testsuite] Add gcc.dg/ia64-sync-5.c

On Aug 6, 2020, at 5:23 AM, Tom de Vries wrote: > > There currently is no sync_char_short-enabled run test that tests > __sync_val_compare_and_swap. > > OK for trunk? Ok.

mmix: fix gcc.dg/loop-9.c by more accurate move insns

Committed. It looks like gcc.dg/loop-9.c kind-of works as sentinel for sane move-instruction generation for a port. Looking at the FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided" FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new temporary register" it

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: > OK, so -fzero-call-used-regs is a ROP mitigation technique. To me > it sounded more like a mitigation against information leaks which > then would be highly incomplete w/o spill slot clearing. Like > we had that discussion on

Re: [RS6000] PR96493, powerpc local call linkage failure

Hi! On Thu, Aug 06, 2020 at 10:58:18PM +0930, Alan Modra wrote: > This corrects current_file_function_operand, an operand predicate used > to determine whether a symbol_ref is safe to use with the local_call > patterns. Calls between pcrel and non-pcrel code need to go via > linker stubs. In

Re: [PATCH/RFC] options: Make --help= to emit values post-overrided

Hi! On Thu, Aug 06, 2020 at 08:37:23PM +0800, Kewen.Lin wrote: > When I was working to update patch as Richard's review comments > here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， > I noticed that the options "-Q --help=params" don't show the final values > after target

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, > On Aug 5, 2020, at 4:35 PM, Qing Zhao via Gcc-patches > wrote: > > >> >> + continue; >> + if (fixed_regs[regno]) >> + continue; >> + if (is_live_reg_at_exit (regno)) >> + continue; >> >> How can a call-used reg be live at exit? > >

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 14:14 +0100, Jonathan Wakely wrote: On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads that have high risk of buffer overflows. They were replaced by

[committed] libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog: PR libstdc++/96484 * src/c++17/fs_ops.cc (fs::read_symlink): Return an error immediately for non-symlinks. * src/filesystem/ops.cc (fs::read_symlink): Likewise. Tested x86_64-linux. Committed to trunk. Backports to follow. commit

[PATCH] c++: Improve RANGE_EXPR optimization in cxx_eval_vec_init

This patch eliminates an exponential dependence in cxx_eval_vec_init on the array dimension of a VEC_INIT_EXPR when the RANGE_EXPR optimization applies. This is achieved by using a single constructor_elt (with index RANGE_EXPR 0...max-1) per dimension instead of two constructor_elts (with index 0

Re: std:vec for classes with constructor?

On 06/08/20 19:58 +0200, Aldy Hernandez wrote: On 8/6/20 6:30 PM, Jonathan Wakely wrote: On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On

Re: [PATCH] Implement P0966 std::string::reserve should not shrink

On 30/07/20 16:39 +0100, Jonathan Wakely wrote: On 30/07/20 15:29 +0100, Jonathan Wakely wrote: On 12/05/19 21:22 +, Andrew Luo wrote: It's been a while, but thought I'd check in again now that GCC 9 has been branched, and master is now on GCC 10. I've merged my changes with the latest

Re: [PATCH] Power10: Add BRH, BRW, BRD support.

On Tue, Aug 04, 2020 at 10:40:15PM -0400, Michael Meissner wrote: > The power10 processor adds 3 new instructions (BRH, BRW, BRD) that byte swaps > half-words, words, and double-words within a GPR register. The brh insn reverses the bytes in each of four 16-bit words in a GPR, but this patch only

[committed] libstdc++: Do not set eofbit eagerly in operator>>(istream&, char(&)[N])

Similar to the bugs I fixed recently in istream::ignore, we incorrectly set eofbit too often in operator>>(istream&, string&) and operator>>(istream&. char(&)[N]). We should only set eofbit if we reach EOF but would have kept going otherwise. If we've already extracted the maximum number of

[PATCH] c++: constraints and address of template-id

When resolving the address of a template-id, we need to drop functions whose associated constraints are not satisfied, as per [over.over]. We do so in resolve_address_of_overloaded_function, but not in resolve_overloaded_unification or resolve_nondeduced_context, which seems like an oversight.

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 10:00 AM, Jonathan Wakely wrote: On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry.  I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights is the fact that the warning infrastructure we have in place

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:37 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > From The SECURE project and GCC in GCC Cauldron 2018: Speaker: Graham Markall The SECURE project is a 15 month program funded by Innovate UK, to take well

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry. I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights is the fact that the warning infrastructure we have in place is far from optimal for C++ in general (with

Re: std:vec for classes with constructor?

On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote: Andrew MacLeod via Gcc-patches writes: On

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 12:45 -0600, Martin Sebor via Libstdc++ wrote: On 8/6/20 10:00 AM, Jonathan Wakely wrote: On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry.  I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights

Re: std::vector code cleanup fixes optimizations

On 06/08/20 21:30 +0200, François Dumont via Libstdc++ wrote: I wonder if following the application of this patch we shouldn't bump versioned namespace through _GLIBCXX_BEGIN_NAMESPACE_VERSION ? Definitely not. Unless it is still considered as experimental. Yes, it is. And it doesn't

Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point

On Mon, 2020-08-03 at 10:07 +0200, Andrea Corallo wrote: > David Malcolm writes: > > > On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote: > > > > [...] > > > >> I haven't thought this through in detail, and I'm not sure exactly > >> how > >> it would work for arbitrary

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020, Christophe Lyon wrote: Was I on the right track configuring with --target=arm-none-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon-fp16 then compiling without any special option? Maybe you also need --with-float=hard, I don't remember if it's implied by the 'hf'

Re: [PATCH] Rewrite get_size_range for irange API.

On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote: [Martin, does this sound reasonable to you?] It mostly makes sense to me except one part: The following patch converts get_size_range to the irange API, thus removing the use of VR_ANTI_RANGE. This was a bit tricky because of the

Re: std::vector code cleanup fixes optimizations

I wonder if following the application of this patch we shouldn't bump versioned namespace through _GLIBCXX_BEGIN_NAMESPACE_VERSION ? Unless it is still considered as experimental. François On 31/07/20 11:03 pm, François Dumont wrote: On 17/07/20 12:36 pm, Jonathan Wakely wrote: On 16/12/19

[PATCH] bb-reorder: Remove a misfiring micro-optimization (PR96475)

When the compgotos pass copies the tail of blocks ending in an indirect jump, there is a micro-optimization to not copy the last one, since the original block will then just be deleted. This does not work properly if cleanup_cfg does not merge all pairs of blocks we expect it to. 2020-08-07

Re: [RS6000] PR96493, powerpc local call linkage failure

On Thu, Aug 06, 2020 at 05:34:03PM -0500, Segher Boessenkool wrote: > > +/* { dg-do run } */ > > +/* { dg-options "-mdejagnu-cpu=powerpc64 -O2" } */ > > That is not a -mcpu= value you should ever use. Please just pick a real > existing CPU, maybe p7 or p8 since this requires ELFv2 anyway? Or,

Re: [PATCH/RFC] options: Make --help= to emit values post-overrided

Hi Segher! Thanks for the comments! on 2020/8/7 上午6:04, Segher Boessenkool wrote: > Hi! > > On Thu, Aug 06, 2020 at 08:37:23PM +0800, Kewen.Lin wrote: >> When I was working to update patch as Richard's review comments >> here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， >>

Re: std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

On Thu, Aug 6, 2020 at 3:07 AM Andrew MacLeod wrote: > > On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: > > On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor > > wrote: > >> On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote: > >> [...] > >> > >>> * ipa-cp changes from vec

Re: [PATCH v5] vect/rs6000: Support vector with length cost modeling

on 2020/8/5 下午10:06, Segher Boessenkool wrote: > On Wed, Aug 05, 2020 at 08:27:57AM +0100, Richard Sandiford wrote: >> OK for the vectoriser parts with those changes, thanks. > > The rs6000 part is still fine as well. Thanks! > > Committed via r11-2586. Thanks all! BR, Kewen

Re: [PATCH][Hashtable 5/6] Remove H1/H2 template parameters

On 17/07/20 1:35 pm, Jonathan Wakely wrote: On 19/12/19 20:22 +0100, François Dumont wrote: Because of this change printers.py has to be updated too. François On 11/17/19 10:15 PM, François Dumont wrote: H1 used to be a reference to the user Hash, now _Hashtable and unordered types agree

Re: [PATCH] testsuite: Update some vect cases for partial vectors

Hi Richard, Thanks for the review! on 2020/8/6 下午1:52, Richard Sandiford wrote: > "Kewen.Lin" writes: >> diff --git a/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c >> b/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c >> index 5200ed1cd94..da6fb12eb0d 100644 >> ---

Re: [PATCH] libgccjit: Improve doc and comments regarding type casts

Andrea Corallo writes: > Hi Alex, > > Looking at the code I believe all these casts are meant to be supported > (read your intuition was correct). > > Also IMO source of confusion is that the doc is mentioning 'int' and > 'float' but I believe would be better to have like 'integral' and >

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 08:56 -0600, Martin Sebor via Libstdc++ wrote: For this specific use case, I saw __istream_extract defined as an ordinary (non-template) function in a .tcc file in the patch so I thought it was out of line. If it's inline It's overloaded. One is a function template defined inline,

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 8:45 AM, Jonathan Wakely via Libstdc++ wrote: On 06/08/20 15:01 +0100, Jonathan Wakely wrote: On 06/08/20 15:26 +0200, Jakub Jelinek via Libstdc++ wrote: On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote:  template    __attribute__((__nonnull__(2),

Re: [PATCH] rs6000: Don't ICE when spilling an MMA accumulator

On 8/5/20 6:06 PM, Segher Boessenkool wrote: > You can just say > >&& reload_completed >&& !(fpr_reg_operand (operands[0], PXImode) && operands[1] == const0_rtx) > > afaics? Agreed. I made that change and retested which was clean. > Okay (for trunk, and later 10) with or without such

[PATCH] Remove std::map use from graphite

This replaces the use of std::map with hash_map for mapping ISL ids to SSA names. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-08-06 Richard Biener * graphite-isl-ast-to-gimple.c (ivs_params): Use hash_map instead of std::map. (ivs_params_clear):

RE: [PATCH] arm: Clear canary value after stack_protect_test [PR96191]

Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: 05 August 2020 15:33 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov > Subject: [PATCH] arm: Clear canary value after stack_protect_test [PR96191] > >

RE: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee saved registers with CMSE

Hi Andre, > -Original Message- > From: Andre Vieira (lists) > Sent: 06 July 2020 15:31 > To: gcc-patches@gcc.gnu.org; Christophe Lyon > Cc: Kyrylo Tkachov > Subject: Re: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee > saved registers with CMSE > > > On 30/06/2020 14:50,

Re: std:vec for classes with constructor?

On 06/08/20 06:16 +0100, Richard Sandiford wrote: Andrew MacLeod via Gcc-patches writes: On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor wrote: On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote: [...] * ipa-cp changes

[PATCH] tree-optimization/96491 - avoid store commoning across abnormal edges

This avoids store commoning across abnormal edges since that easily can disrupt abnormal coalescing because it might create overlapping lifetime of variables. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-08-06 Richard Biener PR tree-optimization/96491 *

Re: std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

On 06/08/20 08:57 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 3:07 AM Andrew MacLeod wrote: On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: > On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor wrote: >> On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote: >> [...]

Re: std:vec for classes with constructor?

On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: > > On 06/08/20 06:16 +0100, Richard Sandiford wrote: > >Andrew MacLeod via Gcc-patches writes: > >> On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: > >>> On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor > >>> wrote: >

Re: std:vec for classes with constructor?

On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote: >Andrew MacLeod via Gcc-patches writes: >> On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: >>> On August 5, 2020 5:09:19 PM

Re: std:vec for classes with constructor? (Was: Re: [patch] multi-range implementation for value_range (irange))

On 8/6/20 8:57 AM, Richard Biener wrote: On Thu, Aug 6, 2020 at 3:07 AM Andrew MacLeod wrote: On 8/5/20 12:54 PM, Richard Biener via Gcc-patches wrote: On August 5, 2020 5:09:19 PM GMT+02:00, Martin Jambor wrote: On Fri, Jul 31 2020, Aldy Hernandez via Gcc-patches wrote: [...] *

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020, Richard Biener wrote: On Thu, Aug 6, 2020 at 10:17 AM Christophe Lyon wrote: Hi, On Wed, 5 Aug 2020 at 16:24, Richard Biener via Gcc-patches wrote: On Wed, Aug 5, 2020 at 3:33 PM Marc Glisse wrote: New version that passed bootstrap+regtest during the night. When

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote: > > On Thu, 6 Aug 2020, Christophe Lyon wrote: > > >>> 2020-08-05 Marc Glisse > >>> > >>> PR tree-optimization/95906 > >>> PR target/70314 > >>> * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e), > >>> (v ?

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020, Christophe Lyon wrote: On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote: On Thu, 6 Aug 2020, Christophe Lyon wrote: 2020-08-05 Marc Glisse PR tree-optimization/95906 PR target/70314 * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),

Re: VEC_COND_EXPR optimizations v2

On Thu, Aug 6, 2020 at 10:17 AM Christophe Lyon wrote: > > Hi, > > > On Wed, 5 Aug 2020 at 16:24, Richard Biener via Gcc-patches > wrote: > > > > On Wed, Aug 5, 2020 at 3:33 PM Marc Glisse wrote: > > > > > > New version that passed bootstrap+regtest during the night. > > > > > > When vector

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 12:12 +0200, Jakub Jelinek wrote: On Wed, Aug 05, 2020 at 04:31:08PM -0600, Martin Sebor via Gcc-patches wrote: I've always found the second argument to __builtin_object_size confusing for types above 1. I don't see anything wrong in the diff but I believe the most useful results

RE: [PATCH 3/5][Arm] New pattern for CSINC instructions

Hi Omar, From: Omar Tahir Sent: 04 August 2020 17:13 To: Kyrylo Tkachov ; ni...@redhat.com; Ramana Radhakrishnan ; Richard Earnshaw ; gcc-patches@gcc.gnu.org Subject: [PATCH 3/5][Arm] New pattern for CSINC instructions This patch adds a new pattern, *thumb2_csinc, for generating CSINC

Re: [PATCH] testsuite: Update some vect cases for partial vectors

"Kewen.Lin" writes: >>> +# Return true if loops using partial vectors are supported. >>> + >>> +proc check_effective_target_vect_partial_vectors { } { >>> +return [expr { [check_effective_target_vect_partial_vectors_usage_1] >>> + ||

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 08:27:05AM -0400, Marek Polacek via Gcc-patches wrote: > // PR c++/88003 > // { dg-do compile { target c++14 } } > // { dg-prune-output ".*internal compiler error.*" } > // { dg-xfail-if "" { *-*-* } } Would that XPASS if the ICE is fixed though? Jakub

[PATCH] AArch64: Add if condition in aarch64_function_value [PR96479]

Hi, The test case vector-subscript-2.c in the gcc testsuit will report an ICE in the expand pass since '-mgeneral-regs-only' is incompatible with the use of V4SI mode. I propose to report the diagnostic information instead of ICE, and the problem has been discussed on PR 96479. I attached the

[RS6000] PR96493, powerpc local call linkage failure

This corrects current_file_function_operand, an operand predicate used to determine whether a symbol_ref is safe to use with the local_call patterns. Calls between pcrel and non-pcrel code need to go via linker stubs. In the case of non-pcrel code to pcrel the stub saves r2 but there needs to be

RE: [PATCH 3/5][Arm] New pattern for CSINC instructions

> Hi Omar, > > diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md > index 0b00aef7ef7..79cf684e5cb 100644 > --- a/gcc/config/arm/thumb2.md > +++ b/gcc/config/arm/thumb2.md > @@ -743,6 +743,9 @@ > if (GET_CODE (operands[4]) == LT && operands[3] == const0_rtx) >return

[PATCH][testsuite] Add gcc.dg/ia64-sync-5.c

Hi, There currently is no sync_char_short-enabled run test that tests __sync_val_compare_and_swap. Fix this by copying ia64-sync-3.c and modifying it for char/short. Tested on x86_64. OK for trunk? Thanks, - Tom [testsuite] Add gcc.dg/ia64-sync-5.c 2020-08-06 Kwok Cheung Yeung

Re: RFC: Monitoring old PRs, new dg directives

On Wed, Aug 05, 2020 at 01:01:32PM -0700, Mike Stump wrote: > On Aug 4, 2020, at 5:54 PM, Marek Polacek wrote: > >> As you find it difficult to express a test using the existing mechanisms, > >> let's talk about those and see if anyone has a good idea on how to express > >> it. I think ICEs

Re: [PATCH] x86_64: Integer min/max improvements.

On Thu, Aug 06, 2020 at 09:40:49AM +0100, Roger Sayle wrote: This test fails on i686-linux (or x86_64-linux when testing with -m32). make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=minmax-9.c' Running /usr/src/gcc/gcc/testsuite/gcc.target/i386/i386.exp ... FAIL:

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 02:30:11PM +0200, Jakub Jelinek wrote: > On Thu, Aug 06, 2020 at 08:27:05AM -0400, Marek Polacek via Gcc-patches wrote: > > // PR c++/88003 > > // { dg-do compile { target c++14 } } > > // { dg-prune-output ".*internal compiler error.*" } > > // { dg-xfail-if "" { *-*-* } }

[PATCH/RFC] options: Make --help= to emit values post-overrided

Hi, When I was working to update patch as Richard's review comments here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， I noticed that the options "-Q --help=params" don't show the final values after target option overriding, instead it emits the default values in params.opt

[PATCH] reassoc: Improve maybe_optimize_range_tests [PR96480]

Hi! On the following testcase, if the IL before reassoc would be: ... [local count: 354334800]: if (x_3(D) == 2) goto ; [34.00%] else goto ; [66.00%] [local count: 233860967]: if (x_3(D) == 3) goto ; [34.00%] else goto ; [66.00%] [local count: 79512730]:

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote: > template > __attribute__((__nonnull__(2), __access__(__write_only__, 2))) > inline basic_istream<_CharT, _Traits>& > operator>>(basic_istream<_CharT, _Traits>& __in, _CharT* __s) > { > size_t __n =

Re: [PATCH] reassoc: Improve maybe_optimize_range_tests [PR96480]

On Thu, 6 Aug 2020, Jakub Jelinek wrote: > Hi! > > On the following testcase, if the IL before reassoc would be: > ... >[local count: 354334800]: > if (x_3(D) == 2) > goto ; [34.00%] > else > goto ; [66.00%] > >[local count: 233860967]: > if (x_3(D) == 3) > goto ;

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020 at 13:42, Marc Glisse wrote: > > On Thu, 6 Aug 2020, Christophe Lyon wrote: > > > On Thu, 6 Aug 2020 at 11:06, Marc Glisse wrote: > >> > >> On Thu, 6 Aug 2020, Christophe Lyon wrote: > >> > > 2020-08-05 Marc Glisse > > > > PR tree-optimization/95906 >

[COMMITTED] bpf: more flexible support for kernel helpers

This patch changes the existing support for BPF kernel helpers to be more flexible, in two main ways. First, there is no longer a hardcoded list of kernel helpers defined in the compiler internals. This is replaced by a new target-specific attribute `kernel_helper' that the user can use to

[PATCH] cmpelim: recognize extra clobbers in insns

I'm working on the AVR cc0 -> CCmode conversion (bug#92729). One problem is that the cmpelim pass is currently very strict in requiring insns of the form (parallel [(set (reg:SI) (op:SI ... ...)) (clobber (reg:CC REG_CC))]) when in fact AVR's insns often have the form (parallel [(set

[PATCH] add move CTOR to auto_vec, use auto_vec for get_loop_exit_edges

This adds a move CTOR to auto_vec and makes use of a auto_vec return value for get_loop_exit_edges denoting that lifetime management of the vector is handed to the caller. The move CTOR prompted the hash_table change because it appearantly makes the copy CTOR implicitely deleted (good) and

[PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, , and replace `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables for

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads that have high risk of buffer overflows. They were replaced by equivalents that only accept a reference to an array, and

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 14:14 +0100, Jonathan Wakely via Libstdc++ wrote: On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads that have high risk of buffer overflows. They were

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Wed, 5 Aug 2020, Qing Zhao wrote: > Hi, Richard, > > Thanks a lot for your careful review and detailed comments. > > > > On Aug 4, 2020, at 2:35 AM, Richard Biener wrote: > > > > I have a few comments below - I'm not sure I'm qualified to fully > > review the rest though. > > Could you

RE: [PATCH] x86_64: Integer min/max improvements.

Hi Uros, Many thanks for the review and feedback. Here's the final version as committed, with both the test cases requested by Richard Biener and your suggestion/request to use ix86_expand_clear. Tested again on x86_64-pc-linux-gnu. Thank you again for the fantastic ix86_expand_clear pointer,

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: > > For x86, for example, even though the GPR registers are 64-bit, we only > > need to zero the lower 32-bit. etc. > > That's an optimization, yes. But, does the code need to care? If one compiles: void foo () { register

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020, Christophe Lyon wrote: 2020-08-05 Marc Glisse PR tree-optimization/95906 PR target/70314 * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e), (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations. (op (c ? a : b)):

RE: [PATCH 2/5][Arm] New pattern for CSINV instructions

Hi Omar, > -Original Message- > From: Omar Tahir > Sent: 05 August 2020 12:42 > To: Kyrylo Tkachov ; ni...@redhat.com; > Ramana Radhakrishnan ; Richard > Earnshaw ; gcc-patches@gcc.gnu.org > Subject: RE: [PATCH 2/5][Arm] New pattern for CSINV instructions > > Hi Kyrill, > > > -/* Only

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Aug 6, 2020 at 10:42 AM Jakub Jelinek wrote: > > On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: > > > For x86, for example, even though the GPR registers are 64-bit, we only > > > need to zero the lower 32-bit. etc. > > > > That's an optimization, yes. > > But, does the

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Wed, 5 Aug 2020, Qing Zhao wrote: > >> > >> From The SECURE project and GCC in GCC Cauldron 2018: > >> > >> Speaker: Graham Markall > >> > >> The SECURE project is a 15 month program funded by Innovate UK, to > >> take well known security techniques from academia and make them > >>

Re: [PATCH][Hashtable 5/6] Remove H1/H2 template parameters

On 06/08/20 08:35 +0200, François Dumont wrote: On 17/07/20 1:35 pm, Jonathan Wakely wrote: I really like the general idea of getting rid of some of the complexity and not supporting infinite customization. But we can do that without changing mangled names of the _Hashtable specialiations.

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On Wed, Aug 05, 2020 at 04:31:08PM -0600, Martin Sebor via Gcc-patches wrote: > I've always found the second argument to __builtin_object_size > confusing for types above 1. I don't see anything wrong in > the diff but I believe the most useful results are with type 1 > for string functions and

[PATCH] tree-optimization/96483 - fix ICE in PRE with POLY_INT_CST

This adds a missing case for PRE expression re-materialization. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-08-06 Richard Biener PR tree-optimization/96483 * tree-ssa-pre.c (create_component_ref_by_pieces_1): Handle POLY_INT_CST. ---

Re: VEC_COND_EXPR optimizations v2

Hi, On Wed, 5 Aug 2020 at 16:24, Richard Biener via Gcc-patches wrote: > > On Wed, Aug 5, 2020 at 3:33 PM Marc Glisse wrote: > > > > New version that passed bootstrap+regtest during the night. > > > > When vector comparisons were forced to use vec_cond_expr, we lost a number > > of > >

Re: [PATCH] c++: dependent constraint on placeholder return type [PR96443]

On Wed, 5 Aug 2020, Jason Merrill wrote: > On 8/4/20 8:00 PM, Patrick Palka wrote: > > On Tue, 4 Aug 2020, Patrick Palka wrote: > > > > > In the testcase below, we never substitute function-template arguments > > > into f15's placeholder-return-type constraint, which leads to us > > >

Re: RFC: Monitoring old PRs, new dg directives

On 8/5/20 7:29 PM, Marek Polacek wrote: On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote: On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote: I think the read of the room is that people think it would be generally

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 15:26 +0200, Jakub Jelinek via Libstdc++ wrote: On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote: template __attribute__((__nonnull__(2), __access__(__write_only__, 2))) inline basic_istream<_CharT, _Traits>& operator>>(basic_istream<_CharT, _Traits>&

Re: [PATCH] add move CTOR to auto_vec, use auto_vec for get_loop_exit_edges

On Thu, 6 Aug 2020, Richard Biener wrote: > This adds a move CTOR to auto_vec and makes use of a > auto_vec return value for get_loop_exit_edges denoting > that lifetime management of the vector is handed to the caller. > > The move CTOR prompted the hash_table change because it appearantly >

RE: [PATCH] x86_64: Integer min/max improvements.

Sorry for the inconvenience. I've just added the obligatory /* { dg-do compile { target { ! ia32 } } } */ to this new gcc.target/i386 test to resolve this failure. Please let me know if there's a better fix. 2020-08-06 Roger Sayle gcc/testsuite/ChangeLog *

Backporting streaming and enum changes

Hello, as discussed some time ago, I would like to discuss possibility to backport the straming and enum improvements. The motivation is that this brings quite noticeable improvements to builds of very large projects where we currently have nonlinearity problem with anonymous namespaces (which is

Re: Backporting streaming and enum changes

On Thu, 6 Aug 2020, Jan Hubicka wrote: > Hello, > as discussed some time ago, I would like to discuss possibility to > backport the straming and enum improvements. The motivation is that > this brings quite noticeable improvements to builds of very large > projects where we currently have

Re: std:vec for classes with constructor?

On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote: >Andrew MacLeod via Gcc-patches writes: >> On 8/5/20 12:54 PM, Richard Biener via Gcc-patches

Re: std:vec for classes with constructor?

On Thu, Aug 6, 2020 at 4:17 PM Aldy Hernandez wrote: > > > > On 8/6/20 12:48 PM, Jonathan Wakely wrote: > > On 06/08/20 12:31 +0200, Richard Biener wrote: > >> On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely > >> wrote: > >>> > >>> On 06/08/20 06:16 +0100, Richard Sandiford wrote: > >>> >Andrew

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 15:01 +0100, Jonathan Wakely wrote: On 06/08/20 15:26 +0200, Jakub Jelinek via Libstdc++ wrote: On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote: template __attribute__((__nonnull__(2), __access__(__write_only__, 2))) inline basic_istream<_CharT, _Traits>&

[PATCH] Rewrite get_size_range for irange API.

[Martin, does this sound reasonable to you?] The following patch converts get_size_range to the irange API, thus removing the use of VR_ANTI_RANGE. This was a bit tricky because of the gymnastics we do in get_size_range to ignore negatives and all that. I didn't convert the function for

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 7:30 AM, Jonathan Wakely via Libstdc++ wrote: On 06/08/20 14:14 +0100, Jonathan Wakely via Libstdc++ wrote: On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:31 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your careful review and detailed comments. >> >> >>> On Aug 4, 2020, at 2:35 AM, Richard Biener >> > wrote: >>> >>> I have a

Re: std:vec for classes with constructor?

On 8/6/20 4:35 PM, Richard Biener wrote: On Thu, Aug 6, 2020 at 4:17 PM Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford

  1   2   >