Re: [C++ Patch] Improve compute_array_index_type locations

Hi, On 29/11/18 17:13, Jason Merrill wrote: + error_at (cp_expr_loc_or_loc (osize, loc), +    error_at (cp_expr_loc_or_loc (osize, input_location), Let's compute the location we want to use once at the top of the function.  And maybe rename the 'loc' parameter to name_loc. Makes

[PATCH][OBVIOUS] Fix thinko in transition to memop_ret type (PR middle-end/88246).

Hi. One obvious thinko I did when I convert the endp into a new enum. The patch survives tests and bootstrap on x86_64-linux-gnu and fixes the ICE in s390x bootstrap. I'm going to install it. Martin gcc/ChangeLog: 2018-11-29 Martin Liska PR middle-end/88246 * builtins.c

Re: C++ PATCH for c++/88184, ICE when treating name as template-name

On Wed, Nov 28, 2018 at 10:34:11PM -0500, Jason Merrill wrote: > On 11/28/18 10:48 AM, Marek Polacek wrote: > > Since P0846R0 was implemented, a name will be treated as a template-name > > when > > it is an unqualified-id followed by a < and name lookup finds either one or > > more functions or

[PATCH] v2: C++: show namespaces for enum values (PR c++/88121)

On Wed, 2018-11-21 at 13:41 -0500, Jason Merrill wrote: > On 11/21/18 8:35 AM, David Malcolm wrote: > > Consider this test case: > > > > namespace json > > { > >enum { JSON_OBJECT }; > > } > > > > void test () > > { > >JSON_OBJECT; > > } > > > > which erroneously accesses an enum value in

Re: [PATCH, rs6000] Fix PR87496: ICE in aggregate_value_p at gcc/function.c:2046

On 11/29/18 11:26 AM, Segher Boessenkool wrote: > On Wed, Nov 28, 2018 at 03:27:19PM -0600, Peter Bergner wrote: >> PR87496 shows a bug where we ICE if we attempt to use -mabi=ieeelongdouble >> and -mno-popcntd. The IEEE128 support requires full ISA 2.06 (aka POWER7) >> support, so we really

Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

On Thu, Nov 29, 2018 at 05:20:03PM +0100, Jakub Jelinek wrote: > On Thu, Nov 29, 2018 at 05:10:33PM +0100, Uros Bizjak wrote: > > Maybe a combine splitter can be used here? Please see documentation > > from paragraph 17.16 onward: > > > > --quote-- > > The insn combiner phase also splits

Re: [RS6000] PowerPC64 soft-float

Hi! On Sun, Nov 25, 2018 at 10:50:27PM +1030, Alan Modra wrote: > This patch aims to prevent long sequences loading soft-float > constants. For 32-bit, it makes sense to load values inline to a gpr > with lis, addi, but not so much for 64-bit where a 5 insn sequence > might be needed for each

Re: [PATCH 1/5][libbacktrace] Factor out backtrace_vector_free

On Thu, Nov 29, 2018 at 4:33 AM, Tom de Vries wrote: > On 29-11-18 00:26, Ian Lance Taylor wrote: >> On Wed, Nov 28, 2018 at 3:15 PM, Tom de Vries wrote: >>> >>> this patch factors out new function backtrace_vector_free. >>> >>> Bootstrapped and reg-tested on x86_64. >>> >>> OK for trunk? >> >>

Re: C++ PATCH for c++/88184, ICE when treating name as template-name

On 11/29/18 1:28 PM, Marek Polacek wrote: On Wed, Nov 28, 2018 at 10:34:11PM -0500, Jason Merrill wrote: On 11/28/18 10:48 AM, Marek Polacek wrote: Since P0846R0 was implemented, a name will be treated as a template-name when it is an unqualified-id followed by a < and name lookup finds either

Re: [PATCH] v2: C++: show namespaces for enum values (PR c++/88121)

On 11/29/18 2:29 PM, David Malcolm wrote: On Wed, 2018-11-21 at 13:41 -0500, Jason Merrill wrote: On 11/21/18 8:35 AM, David Malcolm wrote: Consider this test case: namespace json { enum { JSON_OBJECT }; } void test () { JSON_OBJECT; } which erroneously accesses an enum value in

[PATCH, i386]: Fix two small MMX glitches

2018-11-29 Uros Bizjak * config/i386/i386.c (inline_memory_move_cost): Check "in" for 2 in MMX_CLASS_P case. * config/i386/mmx.md (*mov_internal): Correct TARGET_INTER_UNIT_MOVES_FROM_VEC and TARGET_INTER_UNIT_MOVES_TO_VEC alternatives in preferred_for_speed attribute

[PATCH] Fix PR64242

Fix PR64242 - the middle end expansion for long jmp updates the hard frame pointer before it reads the new stack pointer. This results in a corrupted stack pointer if the jmp buffer is a local. The obvious fix is to insert a temporary. AArch64 bootstrap & regress pass. OK to commit? ChangeLog:

Re: [PATCH 4/4][libbacktrace] Add tests for unused formats

On Fri, Nov 23, 2018 at 12:56 PM, Tom de Vries wrote: > > When building libbacktrace, we typically use elf.c, and don't build pecoff.c, > xcoff.c or unknown.c > > Add testcases that use unused format to ensure that we also build and > test those on a typical development setup. > > Bootstrapped

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Nick, On 11/29/2018 03:01 PM, Nick Clifton wrote: > static struct demangle_component * > d_function_type (struct d_info *di) > { > - struct demangle_component *ret; > + static unsigned long recursion_level = 0; Did you consider making this be a part of struct d_info instead? IIRC, d_info

Re: [PATCH 1/2] asm qualifiers (PR55681)

On Fri, Nov 30, 2018 at 12:11:30AM +, Joseph Myers wrote: > On Thu, 29 Nov 2018, Segher Boessenkool wrote: > > > So "asm const restrict" is allowed, but "asm const const restrict" isn't. > > No, asm const restrict isn't allowed. volatile is allowed; const and > restrict are allowed with

Re: [PATCH 1/4][libbacktrace] Test check_PROGRAMS without mmap

On Fri, Nov 23, 2018 at 12:47 PM, Tom de Vries wrote: > [ was: [PATCH 1/2][libbacktrace] Handle realloc returning NULL if size == 0 ] > > On Thu, Nov 22, 2018 at 01:35:43PM +0100, Tom de Vries wrote: >> Hi, >> >> Build and tested on x86_64, with mmap.c replaced by alloc.c to ensure that >>

[PATCH, libstdc++, C++20] Implement P0457R2 String Prefix and Suffix Checking.

Greetings, This patch implements starts_with and ends_with for basic_string and basic_string_view for C++20. This builds and tests cleanly on x86_64-linux. Ed 2018-11-30 Edward Smith-Rowland <3dw...@verizon.net> Implement P0457R2 String Prefix and Suffix Checking. *

Re: [PATCH 1/2] asm qualifiers (PR55681)

On Thu, 29 Nov 2018, Segher Boessenkool wrote: > So "asm const restrict" is allowed, but "asm const const restrict" isn't. No, asm const restrict isn't allowed. volatile is allowed; const and restrict are allowed with warnings because that replicates what the old bison parser allowed; but at

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 11/29/18 4:43 PM, Martin Sebor wrote: >> The fallout on existing tests is minimal.  What's more concerning is >> that it doesn't actually pass the new test from Martin's original >> submission.  We get bogus warnings. >> >> At least part of the problem is weakness in maybe_diag_stxncpy_trunc.

Re: [PATCH] x86: Add -march=cascadelake

Hi Distinguish based on stepping number is not recommended for some reasons: 1) Intel doesn't officially disclose stepping information in SDM. 2) Stepping can be changing in the future. We still prefer the conventional distinguish approach based on feature bits. I have refined the patch as

Re: RFA: a x86 test modification

On Thu, Nov 29, 2018 at 8:03 AM Uros Bizjak wrote: > > On Thu, Nov 29, 2018 at 12:43 AM Jeff Law wrote: > > > > On 11/28/18 2:47 PM, Vladimir Makarov wrote: > > > The patch I committed today recently for > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88207 > > > > > > creates a new

[PATCH] Optimize integral lt + blend into just blend (PR target/54700)

Hi! The following patch optimizes - pxor%xmm3, %xmm3 - pcmpgtb %xmm0, %xmm3 - movdqa %xmm3, %xmm0 pblendvb%xmm0, %xmm1, %xmm2 movdqa %xmm2, %xmm0 ret - vpxor %xmm3, %xmm3, %xmm3 - vpcmpgtq%ymm0, %ymm3, %ymm0 -

Re: [patch,openacc] C, C++ OpenACC wait diagnostic change

On Thu, 29 Nov 2018, Julian Brown wrote: > > But for C, it does not appear that c_parser_expr_list has a code path > > that can return a zero-length list at all. So, we can elide the > > diagnostic with no change to compiler behaviour. This patch does that, > > and also changes the C++

PING [PATCH] x86: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

On Wed, Oct 31, 2018 at 12:42 PM H.J. Lu wrote: > > On Thu, Sep 27, 2018 at 7:58 AM Richard Biener > wrote: > > > > On Thu, Sep 27, 2018 at 3:16 PM H.J. Lu wrote: > > > > > > On Thu, Sep 27, 2018 at 6:08 AM, Szabolcs Nagy > > > wrote: > > > > On 26/09/18 19:10, H.J. Lu wrote: > > > >> > > >

Re: [PATCH, rs6000] Fix PR87496: ICE in aggregate_value_p at gcc/function.c:2046

On 11/29/18 1:31 PM, Peter Bergner wrote: > On 11/29/18 11:26 AM, Segher Boessenkool wrote: >> On Wed, Nov 28, 2018 at 03:27:19PM -0600, Peter Bergner wrote: >>> PR87496 shows a bug where we ICE if we attempt to use -mabi=ieeelongdouble >>> and -mno-popcntd. The IEEE128 support requires full ISA

[PATCH, libstdc++] Uniform container erasure for c++20 returning number of erasures.

This version of erase_if/erase returning number erased actually build and tests cleanly on x86_64-linux. Is this what you has in mind for this?  I basically return the number of erased items for all the things Ed

Re: [patch,openacc] C, C++ OpenACC wait diagnostic change

On Fri, 28 Sep 2018 14:17:42 +0100 Julian Brown wrote: > On Wed, 26 Sep 2018 14:08:37 -0700 > Cesar Philippidis wrote: > > > On 09/26/2018 12:50 PM, Joseph Myers wrote: > > > On Wed, 26 Sep 2018, Cesar Philippidis wrote: > > > > > >> Attached is an old patch which updated the C and C++

Re: [PATCH] Optimize integer vector comparison followed by movmsk (PR target/88152, take 2)

On Thu, Nov 29, 2018 at 10:42 PM Jakub Jelinek wrote: > > On Thu, Nov 29, 2018 at 05:26:41PM +0100, Uros Bizjak wrote: > > On Thu, Nov 29, 2018 at 3:36 PM Jakub Jelinek wrote: > > > Like blend, movmsk also only cares about the most significant bit, > > > so prior < 0 comparisons or (happens also

Re: [PATCH] Optimize integral lt + blend into just blend (PR target/54700)

On Thu, Nov 29, 2018 at 10:40 PM Jakub Jelinek wrote: > > On Thu, Nov 29, 2018 at 05:41:59PM +0100, Uros Bizjak wrote: > > On Thu, Nov 29, 2018 at 5:28 PM Jakub Jelinek wrote: > > > > > > On Thu, Nov 29, 2018 at 05:21:53PM +0100, Uros Bizjak wrote: > > > > > > *

Re: [PATCH] Improve combiner's find_split_point (PR target/54589)

Hi Jakub, On Thu, Nov 29, 2018 at 10:49:21PM +0100, Jakub Jelinek wrote: > The following patch attempts to improve find_split_point inside of > complex MEM addresses, if the target supports REG + REG + const > addressing, but doesn't support more_complex_rtx + REG + const, > try to split it at

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 11/29/18 1:34 PM, Martin Sebor wrote: > On 11/16/2018 02:07 AM, Richard Biener wrote: >> On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote: >>> >>> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html >>> >>> Please let me know if there is something I need to change here >>> to make

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

On Thu, 29 Nov 2018, Julian Brown wrote: > On Thu, 20 Sep 2018 10:08:51 -0700 > Cesar Philippidis wrote: > > > Apparently, Tom ran into an ICE when we were adding support for new > > clauses back in the gomp-4_0-branch days. This patch shouldn't be > > necessary because all of the clauses are

Re: [patch,openacc] use existing local variable in cp_parser_oacc_enter_exit_data

On Thu, 29 Nov 2018, Julian Brown wrote: > So, OK, or shall we just drop this? (Joseph?) I've no comment on this patch; it seems to be in Thomas's area. -- Joseph S. Myers jos...@codesourcery.com

[PATCH] Improve combiner's find_split_point (PR target/54589)

Hi! The following patch attempts to improve find_split_point inside of complex MEM addresses, if the target supports REG + REG + const addressing, but doesn't support more_complex_rtx + REG + const, try to split it at more_complex_rtx rather than more_complex_rtx + REG. On the original testcase

Re: [PATCH 1/2] asm qualifiers (PR55681)

On Thu, 29 Nov 2018, Segher Boessenkool wrote: > > What's the basis for allowing duplicates for C but not for C++? > > It is the status quo. It would make sense to allow duplicates for C++ as > well, sure. If that is preferred I can make a patch for it? Duplicate qualifiers are allowed *in

Re: [PATCH 1/2] asm qualifiers (PR55681)

I'd expect testcases to be added for the new syntax variants (duplicate qualifiers / goto and new orderings thereof). There's a description of the syntax in extend.texi: @example asm @r{[}volatile@r{]} ( @var{AssemblerTemplate} : @var{OutputOperands} @r{[} :

[SPARC] Fix PR target/87807

to -fpcc-struct-return. (sparc_struct_value_rtx): Return NULL_RTX instead of 0. (sparc_function_value_1): Rework handling of vector types. Change size from HOST_WIDE_INT to int. 2018-11-29 Eric Botcazou * gcc.target/sparc/20181129-1.c: New test

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 11/29/18 4:07 PM, Jeff Law wrote: On 11/29/18 1:34 PM, Martin Sebor wrote: On 11/16/2018 02:07 AM, Richard Biener wrote: On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html Please let me know if there is something I need to

Re: [patch,openacc] use existing local variable in cp_parser_oacc_enter_exit_data

On Wed, 26 Sep 2018 11:21:33 -0700 Cesar Philippidis wrote: > This is an old gomp4 patch that updates the location of the clause for > acc enter/exit data. Apparently, it didn't impact any test cases. Is > this OK for trunk or should we drop it from OG8? > > I bootstrapped and regtested it for

[C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)

Hi! On the following testcase, build_conditional_expr_1 tries hard to make sure that if both arguments are xvalue_p (or one is and the other throw) the result is still xvalue_p. But, later on we call unary_complex_lvalue, which does rationalize_conditional_expr which changes it from cond ? x : y

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Pedro Alves writes: > Hi Nick, > > On 11/29/2018 03:01 PM, Nick Clifton wrote: >> static struct demangle_component * >> d_function_type (struct d_info *di) >> { >> - struct demangle_component *ret; >> + static unsigned long recursion_level = 0; > > Did you consider making this be a part of

Re: [PATCH 1/2] asm qualifiers (PR55681)

On Thu, Nov 29, 2018 at 09:13:13PM +, Joseph Myers wrote: > I'd expect testcases to be added for the new syntax variants (duplicate > qualifiers / goto and new orderings thereof). Okay. > There's a description of the syntax in extend.texi: > > @example > asm @r{[}volatile@r{]} (

Re: [PING^3] Re: [PATCH 1/3] Support instrumenting returns of instrumented functions

> > I don't think it is because the instrumentation only adds calls, and > calls don't get annotated in DWARF. The only issue I could think of > if is something patches in push instructions through the nops, > but there is really nothing the compiler could do about that. > > I tested gdb and it

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

On Thu, 20 Sep 2018 10:08:51 -0700 Cesar Philippidis wrote: > Apparently, Tom ran into an ICE when we were adding support for new > clauses back in the gomp-4_0-branch days. This patch shouldn't be > necessary because all of the clauses are fully implemented now, but > it may prevent similar

[PATCH] Optimize integer vector comparison followed by movmsk (PR target/88152, take 2)

On Thu, Nov 29, 2018 at 05:26:41PM +0100, Uros Bizjak wrote: > On Thu, Nov 29, 2018 at 3:36 PM Jakub Jelinek wrote: > > Like blend, movmsk also only cares about the most significant bit, > > so prior < 0 comparisons or (happens also on the testcase below in some > > cases) arithmetic shift right

Re: [PATCH] Optimize integral lt + blend into just blend (PR target/54700)

On Thu, Nov 29, 2018 at 05:41:59PM +0100, Uros Bizjak wrote: > On Thu, Nov 29, 2018 at 5:28 PM Jakub Jelinek wrote: > > > > On Thu, Nov 29, 2018 at 05:21:53PM +0100, Uros Bizjak wrote: > > > > > * g++.target/i386/avx2-check.h: New file. > > > > > * g++.target/i386/m128-check.h:

Re: [PATCH 1/2] asm qualifiers (PR55681)

On Thu, Nov 29, 2018 at 11:14:45PM +, Joseph Myers wrote: > On Thu, 29 Nov 2018, Segher Boessenkool wrote: > > > > What's the basis for allowing duplicates for C but not for C++? > > > > It is the status quo. It would make sense to allow duplicates for C++ as > > well, sure. If that is

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

PING! (for the GCC-7 branch, I'll commit it after the 7.4 release) On Thu, Nov 22, 2018 at 11:17 AM Janne Blomqvist wrote: > From backtrace.h for backtrace_create_state: > >Calling this function allocates resources that can not be freed. >There is no backtrace_free_state function. The

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On Thu, Nov 29, 2018 at 9:34 PM Martin Sebor wrote: > > On 11/16/2018 02:07 AM, Richard Biener wrote: > > On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote: > >> > >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html > >> > >> Please let me know if there is something I need to

Re: [RS6000] num_insns_constant ICE

On Thu, Nov 29, 2018 at 01:52:34PM -0600, Segher Boessenkool wrote: > On Sun, Nov 25, 2018 at 10:49:12PM +1030, Alan Modra wrote: > > + while (nregs-- > 0) > > +{ > > + int ins = num_insns_constant_gpr (value); > > You probably should mask "value" here so that it is only one GPR. >

Re: [RS6000] PowerPC64 soft-float

On Thu, Nov 29, 2018 at 12:15:06PM -0600, Segher Boessenkool wrote: > On Sun, Nov 25, 2018 at 10:50:27PM +1030, Alan Modra wrote: > > This patch aims to prevent long sequences loading soft-float > > constants. For 32-bit, it makes sense to load values inline to a gpr > > with lis, addi, but not

Re: [PATCH v3] Make function clone name numbering independent.

On Wed, Nov 28, 2018 at 10:09 PM Michael Ploujnikov wrote: > > Continuing from https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00228.html > > It took longer than expected, but I've finally rebased this on top of > the new clone_function_name* API and included the requested > optimizations. > >

Re: [PATCH] asm non-code template parts (alternative to asm inline)

On Thu, Nov 29, 2018 at 5:44 PM Alexander Monakov wrote: > > > On Mon, 15 Oct 2018, Richard Biener wrote: > > > I think it's sound but also note that I think it is logically independent > > > of > > > asm inline (). While it may work for the inlining issue for some kernel > > > examples to asm

Re: [PATCH] Adapt a couple of scalar comparison match.pd optimizations for vector comparisons against uniform vectors (PR target/88152)

On Thu, Nov 29, 2018 at 10:22:15AM +0100, Richard Biener wrote: > OK. I didn't spent a lot of time trying to see if we can merge the > scalar and vector variants but I trust you did ;) Yeah, sadly it is too different, even if we were to introduce a predicate whether a tree is either INTEGER_CST,

Re: [PATCH] Optimize integral lt + blend into just blend (PR target/54700)

On Thu, Nov 29, 2018 at 9:00 AM Jakub Jelinek wrote: > > Hi! > > The following patch optimizes > - pxor%xmm3, %xmm3 > - pcmpgtb %xmm0, %xmm3 > - movdqa %xmm3, %xmm0 > pblendvb%xmm0, %xmm1, %xmm2 > movdqa %xmm2, %xmm0 > ret > > - vpxor

Re: [PATCH] Adapt a couple of scalar comparison match.pd optimizations for vector comparisons against uniform vectors (PR target/88152, take 2)

On Thu, 29 Nov 2018, Jakub Jelinek wrote: > On Thu, Nov 29, 2018 at 10:31:06AM +0100, Jakub Jelinek wrote: > > On Thu, Nov 29, 2018 at 10:22:15AM +0100, Richard Biener wrote: > > > OK. I didn't spent a lot of time trying to see if we can merge the > > > scalar and vector variants but I trust you

Re: [PATCH] Adapt a couple of scalar comparison match.pd optimizations for vector comparisons against uniform vectors (PR target/88152)

On Thu, 29 Nov 2018, Jakub Jelinek wrote: > Hi! > > The following patch adapts a couple of scalar comparison against INTEGER_CST > optimizations to vector comparison against uniform_vector_p VECTOR_CST. > > The PR was specifically asking for the a > INT_MAX, a >= INT_MAX etc. > to (signed) a <

[PATCH, ARM] Error out when -mfpu set and targeting Thumb-1

Hi, FP instructions are only enabled for TARGET_32BIT and TARGET_HARD_FLOAT but GCC only gives an error when TARGET_HARD_FLOAT is true and -mfpu is not set. Among other things, it makes some of the cmse tests (eg. gcc.target/arm/cmse/baseline/softfp.c) fail when targeting -march=armv8-m.base

Re: [PATCH 1/2, d] Fix hashing of complex reals

On Wed, 28 Nov 2018 at 22:44, Johannes Pfau wrote: > > Hashing of complex types where the floating point type used > for the real and imaginary parts has padding (such as X86 80 bit reals) > has padding, is currently broken in druntime. > > Fixed by backporting

Re: [PATCH] PR880088 Enable -Wtrampolines for no-exec-stack targets with -Wall.

Hi Segher, On Wed, 2018-11-28 at 15:00 -0600, Segher Boessenkool wrote: > On Tue, Nov 27, 2018 at 08:54:07PM +0100, Mark Wielaard wrote: > > On Tue, 2018-11-27 at 12:37 -0600, Segher Boessenkool wrote: > > > > Define a new target macro TARGET_HAS_DEFAULT_NOEXEC_STACK for > > > > those > > > >

[PATCH] Adapt a couple of scalar comparison match.pd optimizations for vector comparisons against uniform vectors (PR target/88152, take 2)

On Thu, Nov 29, 2018 at 10:31:06AM +0100, Jakub Jelinek wrote: > On Thu, Nov 29, 2018 at 10:22:15AM +0100, Richard Biener wrote: > > OK. I didn't spent a lot of time trying to see if we can merge the > > scalar and vector variants but I trust you did ;) > > Yeah, sadly it is too different, even

Re: [PATCH v4] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations

Hi, Please check line 4102 in match.pd. Notice that (if (flag_unsafe_math_optimizations) And my code is inside that if :-) Giuliano. On Thu, Nov 29, 2018 at 2:37 AM Jeff Law wrote: > > On 11/27/18 12:38 PM, Giuliano Augusto Faulin Belinassi wrote: > > Only do this optimization if

The GCC 7 branch is now frozen

The GCC 7 branch is now frozen for creation of a release candidate for GCC 7.4 and the final release. All changes from now on require release manager approval. I'll do a full status update after the RC has been created. Thanks for your support. Richard.

Re: [PATCH][Arm] Fix FPU configurations for Cortex-R7 and Cortex-R8

On 28/11/18 10:57, Richard Earnshaw (lists) wrote: > On 28/11/2018 10:43, Andre Vieira (lists) wrote: >> On 27/11/18 14:18, Richard Earnshaw (lists) wrote: >>> On 27/11/2018 14:10, Andre Vieira (lists) wrote: Both Cortex-R7 and Cortex-R8 support FP16 conversion instructions and both

Re: Add a loop versioning pass

Hi, On Wed, Nov 28 2018, Richard Sandiford wrote: >>> The pass gives a 7.6% improvement on Cortex-A72 for 554.roms_r at -O3 >>> and a 2.4% improvement for 465.tonto. I haven't found any SPEC tests >>> that regress. >>> >>> Sizewise, there's a 10% increase in .text for both 554.roms_r and >>>

Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

Hi Iain, > On Tue, 27 Nov 2018 at 20:32, Rainer Orth > wrote: >> >> Hi Mike, >> >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth >> > wrote: >> >> >> >> Some assemblers, including the Solaris one, don't support UTF-8 >> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase as >>

Re: [PATCH] Fix vec_{add,sub} rs6000_gimple_fold_builtin folding (PR target/88234)

Hi Jakub, On Thu, Nov 29, 2018 at 03:00:22PM +0100, Jakub Jelinek wrote: > vec_add/sub of with vector unsigned args is lowered to a builtin which > has vector signed args and therefore if not -fwrapv it is undefined if > signed integer overflow occurs in those vectors. > > The following patch

Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

Hi All, We are able to fix the subjected issue with the peephole patterns (target specific) in the md file (attached the patch pr54589.patch). While testing the fix ,we end up with some of the C constructs like Testcase 1: #include struct param { int a, b, c, d; __m128i array[256]; }; void

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On Thu, Nov 29, 2018 at 08:47:15AM -0500, Ed Smith-Rowland wrote: > --- include/std/deque (revision 266567) > +++ include/std/deque (working copy) > @@ -58,6 +58,7 @@ > #pragma GCC system_header > > #include > +#include // For remove and remove_if Isn't that too expensive, especially in

Re: [PATCH v3] Make function clone name numbering independent.

On 2018-11-28 5:49 p.m., Segher Boessenkool wrote: > Hi! > > On Wed, Nov 28, 2018 at 04:09:14PM -0500, Michael Ploujnikov wrote: >> I've also included a small change to rs6000 which I'm pretty sure is >> safe, but I have no way of testing. > > Do you have an account on the GCC Compile Farm? >

[PATCH] Optimize integer vector comparison followed by movmsk (PR target/88152)

Hi! Like blend, movmsk also only cares about the most significant bit, so prior < 0 comparisons or (happens also on the testcase below in some cases) arithmetic shift right (by any value) isn't needed before the movmsk. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Re: [PATCH, ARM] Error out when -mfpu set and targeting Thumb-1

On 29/11/2018 10:51, Thomas Preudhomme wrote: > Hi, > > FP instructions are only enabled for TARGET_32BIT and TARGET_HARD_FLOAT > but GCC only gives an error when TARGET_HARD_FLOAT is true and -mfpu is > not set. Among other things, it makes some of the cmse tests (eg. >

Re: The GCC 7 branch is now frozen

> Thanks for your support. You're campaigning for something? ;-) -- Eric Botcazou

Re: [PATCH 1/2] asm qualifiers (PR55681)

+cc: C and C++ maintainers. Sorry I forgot before :-/ On Tue, Oct 30, 2018 at 05:30:33PM +, Segher Boessenkool wrote: > PR55681 observes that currently only one qualifier is allowed for > inline asm, so that e.g. "volatile asm" is allowed, "const asm" is also > okay (with a warning), but

[ping x3] Re: [PATCH 0/2] asm qualifiers (PR55681) and asm inline

Ping x3. On Sat, Nov 17, 2018 at 08:52:58AM -0600, Segher Boessenkool wrote: > Ping x2. > > On Sat, Nov 10, 2018 at 06:33:37PM -0600, Segher Boessenkool wrote: > > Ping. > > > > On Tue, Oct 30, 2018 at 05:30:32PM +, Segher Boessenkool wrote: > > > Hi! > > > > > > This is the same "asm

[PATCH] S/390: Add support for section anchors

Bootstrapped and regtested on s390x-redhat-linux and x86_64-redhat-linux. gcc/ChangeLog: 2018-09-12 Ilya Leoshkevich * common/config/s390/s390-common.c (s390_option_init_struct): Use section anchors by default. * config/s390/s390.c (s390_check_symref_alignment):

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time

On Wed, Nov 28, 2018 at 3:09 PM Jonathan Wakely wrote: > > On 28/11/18 14:46 +0100, Richard Biener wrote: > >On Wed, Nov 28, 2018 at 1:30 PM Jonathan Wakely wrote: > >> > >> On 28/11/18 11:11 +, Jonathan Wakely wrote: > >> >On 28/11/18 11:46 +0100, Richard Biener wrote: > >> >>On Wed, Nov

Re: [PATCH 1/5][libbacktrace] Factor out backtrace_vector_free

On 29-11-18 00:26, Ian Lance Taylor wrote: > On Wed, Nov 28, 2018 at 3:15 PM, Tom de Vries wrote: >> >> this patch factors out new function backtrace_vector_free. >> >> Bootstrapped and reg-tested on x86_64. >> >> OK for trunk? > > We should only add new files if we really absolutely must, as

[PATCH] PR libstdc++/88119 use alignof in std::alignment_of, not __alignof__

Now that __alignof__ and alignof sometimes disagree it matters which one we use. The standard says that std::alignment_of::value equals alignof(T), so we need to use that. Change the only uses of alignment_of to use __alignof__ to avoid a change in alignment. PR libstdc++/88119

[PATCH] Fix PR88243

The following adjusts the pattern def-seq generation to give all stmts in the def-seq vect_internal_def type and not retain the vect_nested_cycle_def or similar def type from the main stmt. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. >From

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On 11/28/18 7:25 PM, Jonathan Wakely wrote: On 28/11/18 12:12 -0500, Ed Smith-Rowland wrote: Index: testsuite/21_strings/basic_string/erasure.cc === --- testsuite/21_strings/basic_string/erasure.cc (nonexistent) +++

[PATCH] Fix vec_{add,sub} rs6000_gimple_fold_builtin folding (PR target/88234)

Hi! vec_add/sub of with vector unsigned args is lowered to a builtin which has vector signed args and therefore if not -fwrapv it is undefined if signed integer overflow occurs in those vectors. The following patch fixes it to make sure that those builtins are folded to PLUS/MINUS_EXPR done on

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On 29/11/18 08:47 -0500, Ed Smith-Rowland wrote: Fixed with 266616. Thanks! Index: include/std/deque === --- include/std/deque (revision 266567) +++ include/std/deque (working copy) @@ -58,6 +58,7 @@ #pragma GCC

RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Ian, Libiberty's demangler seems to be a favourite target of people looking to file new CVEs by fuzzing strings and I have finally gotten tired of reviewing them all. So I would like to propose a patch to add support for placing a recursion limit on the demangling functions. The

Re: [PATCH] Come up with --param asan-stack-small-redzone (PR sanitizer/81715).

On 11/28/18 12:41 PM, Jakub Jelinek wrote: > On Wed, Sep 26, 2018 at 11:33:25AM +0200, Martin Liška wrote: >> 2018-09-26 Martin Liska >> >> PR sanitizer/81715 >> * asan.c (asan_shadow_cst): Remove. >> (asan_emit_redzone_payload): New. >> (asan_emit_stack_protection): Make it

Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

On Thu, Nov 29, 2018 at 08:13:48PM +0530, Umesh Kalappa wrote: > We are able to fix the subjected issue with the peephole patterns > (target specific) in the md file (attached the patch pr54589.patch). > While testing the fix ,we end up with some of the C constructs like The right thing for

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On 11/29/18 9:09 AM, Jonathan Wakely wrote: On 29/11/18 08:47 -0500, Ed Smith-Rowland wrote: Fixed with 266616. Thanks! Index: include/std/deque === --- include/std/deque    (revision 266567) +++ include/std/deque    (working

Re: [C++ Patch] Improve compute_array_index_type locations

Hi, On 29/11/18 03:01, Jason Merrill wrote: On 11/6/18 4:01 AM, Paolo Carlini wrote: when I improved create_array_type_for_decl I didn't notice that it calls compute_array_index_type as helper, which simply needs to have the location information propagated. Tested x86_64-linux. This looks

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time

On 28/11/2018 12:35, Jonathan Wakely wrote: On 28/11/18 10:54 +0100, Christophe Lyon wrote: On Wed, 28 Nov 2018 at 00:25, Jonathan Wakely wrote: This resolves a longstanding issue where the lock policy for shared_ptr reference counting depends on compilation options when the header is

Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

Hi! Note, in other cases combine is sucessful. E.g. consider: struct S { int a, b, c, d; }; struct T { struct S e[16]; struct S f[1024]; } t; int foo (unsigned long x) { return t.f[x + 5].a; } int bar (struct T *x, unsigned long y) { return x->f[y + 5].b; } On x86_64-linux with -O2, we

Re: [PATCH] Come up with --param asan-stack-small-redzone (PR sanitizer/81715).

On Thu, Nov 29, 2018 at 04:03:42PM +0100, Martin Liška wrote: > > Two problems, it uses unconditionally unaligned stores, without > > checking if the target supports them at all (in this case it does). > > And, it doesn't check if it wouldn't be more efficient to use > > 32-bit stores. > > Ok,

Re: [PATCH v4] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations

On 11/29/18 3:34 AM, Giuliano Augusto Faulin Belinassi wrote: > Hi, > > Please check line 4102 in match.pd. Notice that > > (if (flag_unsafe_math_optimizations) > > And my code is inside that if :-) Ugh. I went backwards looking for something like that and missed it :-) I may have not

Re: [PATCH v4] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations

On 11/27/18 12:38 PM, Giuliano Augusto Faulin Belinassi wrote: > Only do this optimization if funsafe-math and -fno-math-errno are > enabled, as pointed in the previous iteration. > > Also added one more test case to ensure that fno-math-errno is > required for the optimization. > > Special

Re: [PATCH, rs6000] Fix PR87496: ICE in aggregate_value_p at gcc/function.c:2046

On Wed, Nov 28, 2018 at 03:27:19PM -0600, Peter Bergner wrote: > PR87496 shows a bug where we ICE if we attempt to use -mabi=ieeelongdouble > and -mno-popcntd. The IEEE128 support requires full ISA 2.06 (aka POWER7) > support, so we really should throw an error when using those options >

Re: [C++ Patch] Improve compute_array_index_type locations

On 11/29/18 2:09 PM, Paolo Carlini wrote: Hi, On 29/11/18 17:13, Jason Merrill wrote: + error_at (cp_expr_loc_or_loc (osize, loc), +    error_at (cp_expr_loc_or_loc (osize, input_location), Let's compute the location we want to use once at the top of the function.  And maybe

Re: [RS6000] num_insns_constant ICE

Hi! On Sun, Nov 25, 2018 at 10:49:12PM +1030, Alan Modra wrote: > This patch came about from investigating an ICE that appeared when I > was retesting an old half-baked patch of mine to rs6000_rtx_costs. > If a const_double is fed to rs6000_is_valid_and_mask and from there to >

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 11/16/2018 02:07 AM, Richard Biener wrote: On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html Please let me know if there is something I need to change here to make the fix acceptable or if I should stop trying. I have one

Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

On Thu, Nov 29, 2018 at 4:09 PM Jakub Jelinek wrote: > > On Thu, Nov 29, 2018 at 08:13:48PM +0530, Umesh Kalappa wrote: > > We are able to fix the subjected issue with the peephole patterns > > (target specific) in the md file (attached the patch pr54589.patch). > > While testing the fix ,we

Re: [C++ Patch] Improve compute_array_index_type locations

On 11/29/18 10:22 AM, Paolo Carlini wrote: Hi, On 29/11/18 03:01, Jason Merrill wrote: On 11/6/18 4:01 AM, Paolo Carlini wrote: when I improved create_array_type_for_decl I didn't notice that it calls compute_array_index_type as helper, which simply needs to have the location information

Re: [PATCH][Version 3]Come up with -flive-patching master option.

the patch has been committed today as: https://gcc.gnu.org/viewcvs/gcc?view=revision=266627 I will try to update the gcc9 change page soon. thanks. Qing > On Nov 28, 2018, at 2:24 PM, Qing Zhao wrote: > >> >> On Nov 28, 2018, at 9:52

  1   2   >