Re: Rb_tree constructor optimization

Hi     Any feedback regarding this patch ? Thanks, François On 14/09/2017 22:04, François Dumont wrote: I realized there was no test on the noexcept qualification of the move constructor with allocator. I added some and found out that patch was missing a noexcept qualification at _Rb_tree

Re: [patch] implement generic debug() functions for wide_int's

On 10/18/2017 11:08 AM, Aldy Hernandez wrote: It looks like the generic debug() function for wide_int's is missing. Instead, we have a wi->dump() method. I have implemented debug() for generic wide_int and for widest_int, which should cover the common cases. Anything else, can continue using

Re: [patch, c++] Add a warning flag for the enum bit-field declaration warning in bug #61414.

On 10/18/2017 01:15 PM, Sam van Kampen wrote: On Wed, Oct 18, 2017 at 09:46:08AM -0600, Martin Sebor wrote: Fair enough, I didn't know whether to change the way it currently was triggered. Do you think it should fall under -Wextra (I don't think it falls under -Wall, since it isn't "easy to

Re: [libstdc++, patch] Fix build on APFS file system

On 18/10/17 18:40 -0400, Hans-Peter Nilsson wrote: On Wed, 18 Oct 2017, FX wrote: Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about 60% from my own builds and results reported by others):

Re: [libstdc++, patch] Fix build on APFS file system

On 18/10/17 22:05 +0100, Jonathan Wakely wrote: On 18/10/17 16:51 +0200, FX wrote: Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others):

[PATCH] Use dlsym to check if libdl is needed for plugin

config/plugins.m4 has if test "$plugins" = "yes"; then AC_SEARCH_LIBS([dlopen], [dl]) fi Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym: [hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep " dl" 00038580 W dlclose U

Re: [PATCH] enhance -Warray-bounds to handle strings and excessive indices

On 10/18/2017 04:48 AM, Richard Biener wrote: On Wed, Oct 18, 2017 at 5:34 AM, Martin Sebor wrote: While testing my latest -Wrestrict changes I noticed a number of opportunities to improve the -Warray-bounds warning. Attached is a patch that implements a solution for the

Re: [libstdc++, patch] Fix build on APFS file system

On Wed, 18 Oct 2017, FX wrote: > Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on > macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about > 60% from my own builds and results reported by others): >

Re: [patch] avoid printing leading 0 in widest_int hex dumps

Aldy Hernandez writes: > On Tue, Oct 17, 2017 at 6:05 PM, Richard Sandiford > wrote: >> Andrew MacLeod writes: >>> On 10/17/2017 08:18 AM, Richard Sandiford wrote: Aldy Hernandez writes: > Hi folks!

[PATCH] v3: C/C++: more stdlib header hints (PR c/81404)

On Wed, 2017-10-18 at 20:40 +, Joseph Myers wrote: > On Wed, 18 Oct 2017, David Malcolm wrote: > > > +{"WINT_MAX", {"", NULL} }, > > +{"WINT_MIN", {"", NULL} } > > These are in / , not . Thanks; here's an updated version of the patch which fixes that. OK for trunk once the prereqs

Re: Add an alternative vector loop iv mechanism

Richard Biener writes: > On Fri, Oct 13, 2017 at 4:10 PM, Richard Sandiford > wrote: >> Normally we adjust the vector loop so that it iterates: >> >>(original number of scalar iterations - number of peels) / VF >> >> times, enforcing

Re: [patch] implement generic debug() functions for wide_int's

On 10/18/2017 06:08 PM, Aldy Hernandez wrote: > Also, do we have a blessed way of specifying overloaded functions in > ChangeLog's? I couldn't find anything in our GCC coding guidelines or > in the GNU coding guidelines. For lack of direction, I'm doing the > following: > > * wide-int.cc

Re: [libstdc++, patch] Fix build on APFS file system

> Could you test using .PHONY: install-headers instead? > That target *is* phony, so telling make that seems sensible. I’ve tried adding it to the existing .PHONY list: Index: libstdc++-v3/include/Makefile.in === ---

Re: [patch, fortran] Fix PR 82567

Hi Jerry and Steve, Well I know 42 is the answer to the ultimate question of the universe so this must be OK. I just don't know what the question is. OK and thanks, Jerry +#define CONSTR_LEN_MAX 42 Actually, I was wondering about the choice myself. With most common hardware having fairly

[PATCH] PR libgcc/59714 complex division is surprising on aarch64

From: Vladimir Mezentsev FMA (floating-point multiply-add) instructions are supported on aarch64. These instructions can produce different result if two operations executed separately. -ffp-contract=off doesn't allow the FMA instructions. Tested on two platforms:

Re: [libstdc++, patch] Fix build on APFS file system

On 18/10/17 16:51 +0200, FX wrote: Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Re: [libstdc++, patch] Fix build on APFS file system

> From supplied info not follow that problem is on gcc build side. > I can suspect that APFS has problem with direntry intensive > modification, for example. As part of Homebrew, we have built 4000+ open source codes on this new filesystem, with parallel compilation. Some of them pretty

Re: [libstdc++, patch] Fix build on APFS file system

On Wed, 18 Oct 2017 16:51:37 +0200 FX wrote: > Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on > macOS 10.13 often fail > (failure rate for “make -j2” to “make -j8” is about 60% from my own builds > and results reported > by others):

Re: [PATCH] v2: C/C++: more stdlib header hints (PR c/81404)

On Wed, 18 Oct 2017, David Malcolm wrote: > +{"WINT_MAX", {"", NULL} }, > +{"WINT_MIN", {"", NULL} } These are in / , not . -- Joseph S. Myers jos...@codesourcery.com

Re: [PING] [C++ Patch] PR 82307

The bug happens only for enum types with a fixed underlying type. The existing code tries to create another type based on it's precision by calling c_common_type_for_size(). For the precision value of an unsigned long long type, the call to c_common_type_for_size() returns an unsigned long

[PATCH] v2: C/C++: more stdlib header hints (PR c/81404)

On Tue, 2017-10-17 at 20:05 +, Joseph Myers wrote: > On Tue, 17 Oct 2017, David Malcolm wrote: > > > It also adds generalizes some of the code for this (and for the > > "std::" > > namespace hints in the C++ frontend), moving it to a new > > c-family/known-headers.cc and .h, and introducing a

[PATCH, i386]: Fix PR82580, Optimize double-word comparisons

Hello! Attached patch emulates double-word comparisons with a double-word subtraction. Note that only comparisons that test Carry, Sign and Overflow flags are valid, so we have to avoid comparisons that test Zero flag. 2017-10-18 Uros Bizjak PR target/82580 *

Re: [PING] [C++ Patch] PR 82307

On 10/18/2017 12:17 PM, Mukesh Kapoor wrote: On 10/9/2017 12:20 PM, Mukesh Kapoor wrote: Hi, This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307. For an unscoped enum with a fixed underlying type, the function type_promotes_to() does not always return the same type as the

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On 10/18/2017 06:48 AM, Segher Boessenkool wrote: A volatile asm statement can not be moved (relative to other volatile asm, etc.), but IRA could do it nevertheless. This patch fixes it. Testing on powerpc64-linux {-m32,-m64}; okay if it succeeds? Also for backports? Although I am not an

Re: [patch] implement generic debug() functions for wide_int's

On Oct 18, 2017, at 10:08 AM, Aldy Hernandez wrote: > > It looks like the generic debug() function for wide_int's is missing. > OK for trunk? Ok.

Re: [patch, c++] Add a warning flag for the enum bit-field declaration warning in bug #61414.

On Wed, Oct 18, 2017 at 09:46:08AM -0600, Martin Sebor wrote: > > Fair enough, I didn't know whether to change the way it currently was > > triggered. Do you think it should fall under -Wextra (I don't think it > > falls under -Wall, since it isn't "easy to avoid or modify to prevent > > the

Re: [PATCH] Simplify floating point comparisons

On Wed, 18 Oct 2017, Richard Biener wrote: > When overflow/underflow can be disregarded is there any reason remaining to > make this guarded by flag_unsafe_math_optimizations? Are there any cases > where rounding issues can flip the comparison result? Yes. E.g. (in round-to-nearest) 3.0f *

Re: [PATCH, i386] Avoid 512-bit mode MOV for prefer-avx256 option in Intel AVX512 configuration

Hello Sergey, On 06 Oct 14:20, Shalnov, Sergey wrote: > Jakub, > I completely agree with you. I fixed the patch. > Currently, TARGET_PREFER256 will work on architectures with 512VL. It will > not work otherwise. > > I will try to find better solution for this. I think I need to look into >

[patch] implement generic debug() functions for wide_int's

It looks like the generic debug() function for wide_int's is missing. Instead, we have a wi->dump() method. I have implemented debug() for generic wide_int and for widest_int, which should cover the common cases. Anything else, can continue using the ->dump() method templated methods. Also, do

[PATCH] Fix nrv-1.c false failure on aarch64.

Hello, Test case "guality.exp=nrv-1.c" fails on aarch64. Optimizations reorder the instructions and cause the value of a variable to be checked before its first assignment. The following patch is moving the break point to the end of the function. Therefore, it ensures that the break point is

patch to fix PR82556

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82556 The patch was bootstrapped and tested on x86-64. Committed to trunk as rev. 253862. Committed to gcc-7-branch as rev. 253863. Index: ChangeLog ===

Re: [PING] [C++ Patch] PR 82307

On 10/9/2017 12:20 PM, Mukesh Kapoor wrote: Hi, This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307. For an unscoped enum with a fixed underlying type, the function type_promotes_to() does not always return the same type as the underlying type. The fix is to use the underlying

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On Wed, Oct 18, 2017 at 05:17:19PM +0200, Michael Matz wrote: > On Wed, 18 Oct 2017, Segher Boessenkool wrote: > > > Certainly. And to work around the bug, it should work to mention some > > hard register as asm input. Ideally something that is live anyway; > > perhaps the stack pointer :-)

Re: [patch, c++] Add a warning flag for the enum bit-field declaration warning in bug #61414.

Fair enough, I didn't know whether to change the way it currently was triggered. Do you think it should fall under -Wextra (I don't think it falls under -Wall, since it isn't "easy to avoid or modify to prevent the warning" because it may be valid and wanted behavior), or should it be enabled by

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

Hi, On Wed, 18 Oct 2017, Segher Boessenkool wrote: > Certainly. And to work around the bug, it should work to mention some > hard register as asm input. Ideally something that is live anyway; > perhaps the stack pointer :-) Like so: > > __asm volatile ("mrs %0,PRIMASK" : "=r" (status) ::

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

> > Those instructions seems similarly expensive in Intel implementation. > > http://users.atw.hu/instlatx64/GenuineIntel0050654_SkylakeXeon9_InstLatX64.txt > > lists latencies ranging from 18 to 32 cycles. > > > > Of course it may also be the case that the utility is measuring gathers > >

[libstdc++, patch] Fix build on APFS file system

Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 This is reproducible with several

[PATCH][GRAPHITE] Limit AST code generation, PR82591

The following limits ISL operations done during optimized AST generation as the PR shows it can take quite a bit of time. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-10-18 Richard Biener PR tree-optimization/82591 *

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On Wed, Oct 18, 2017 at 01:50:31PM +, Bernd Edlinger wrote: > Yes, the volatile is still necessary. Certainly. And to work around the bug, it should work to mention some hard register as asm input. Ideally something that is live anyway; perhaps the stack pointer :-) Like so: __asm

Re: [PATCH][compare-elim] Merge zero-comparisons with normal ops

> Are we in agreement that I should revert the patch? I think that you can leave it for now in order to have some feedback (see for example PR rtl-optimization/82597) but ideally it should be rewritten so as to reuse the existing infrastructure of the pass. -- Eric Botcazou

Re: [PATCH PR/82546] tree node size

> I'd think so. LANG_TYPE is treated specially in several > places and Ada debug types are pretty sensitive so this would > require caution but I don't see/know-of obvious reasons why this > couldn't be done. LANG_TYPE is only used in Ada to trigger the specific treatment in

Re: [patch, c++] Add a warning flag for the enum bit-field declaration warning in bug #61414.

On Mon, Oct 16, 2017 at 11:31:10PM +, Joseph Myers wrote: > On Mon, 16 Oct 2017, Sam van Kampen via gcc-patches wrote: > > > +Wbitfield-enum-conversion > > +C++ Var(warn_bitfield_enum_conversion) Init(1) Warning > > +Warn about struct bit-fields being too small to hold enumerated types. > >

Re: [patch] Fix PR debug/82509

> Hmm. It makes tracking DIE builds difficult now that not all allocations go > through new_die anymore. I wouldn't have created such a precedent though, IOW there is nothing new. > Can you instead split out a new_die_raw > function with just the allocation and the die_tag initialization? Or

Re: [patch, c++] Add a warning flag for the enum bit-field declaration warning in bug #61414.

On Mon, Oct 16, 2017 at 08:56:05PM -0600, Martin Sebor wrote: > On 10/16/2017 06:37 AM, Sam van Kampen via gcc-patches wrote: > > ..I just realised that the clang flag is -Wbitfield-enum-conversion, not > > -Wenum-bitfield-conversion. Please apply the patch below instead, which > > has replaced

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On 10/18/17 15:46, Segher Boessenkool wrote: > On Wed, Oct 18, 2017 at 06:30:23AM -0500, Segher Boessenkool wrote: >> On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote: >>> A memory clobber would also make rtx_moveable_p return false, >>> thru the following case: >>> >>> case

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On Wed, Oct 18, 2017 at 06:30:23AM -0500, Segher Boessenkool wrote: > On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote: > > A memory clobber would also make rtx_moveable_p return false, > > thru the following case: > > > > case MEM: > > if (type == OP_IN && MEM_READONLY_P

[PATCH][GRAPHITE] More TLC

And using range-info to constain parameters. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-10-18 Richard Biener * graphite-isl-ast-to-gimple.c (translate_isl_ast_to_gimple::set_rename): Simplify.

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On 10/18/17 13:30, Segher Boessenkool wrote: > On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote: >> A memory clobber would also make rtx_moveable_p return false, >> thru the following case: >> >> case MEM: >>if (type == OP_IN && MEM_READONLY_P (x)) >> return

Re: [PATCH][RFC] Instrument function exit with __builtin_unreachable in C++.

On 10/18/2017 02:52 PM, Marek Polacek wrote: > On Wed, Oct 18, 2017 at 02:46:23PM +0200, Martin Liška wrote: >> On 10/12/2017 10:48 AM, Jakub Jelinek wrote: >>> On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote: --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -1175,7

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

On Wed, 18 Oct 2017, Jan Hubicka wrote: > > > According to Agner's tables, gathers range from 12 ops (vgatherdpd) > > > to 66 ops (vpgatherdd). I assume that CPU needs to do following: > > > > > > 1) transfer the offsets sse->ALU unit for address generation (3 cycles > > >each, 2 ops) > > >

Re: [PATCH][RFC] Instrument function exit with __builtin_unreachable in C++.

On Wed, Oct 18, 2017 at 02:46:23PM +0200, Martin Liška wrote: > On 10/12/2017 10:48 AM, Jakub Jelinek wrote: > > On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote: > >> --- a/gcc/cp/constexpr.c > >> +++ b/gcc/cp/constexpr.c > >> @@ -1175,7 +1175,12 @@ cxx_eval_builtin_function_call

[PATCH] Fix all tests that fail with -sanitize=return.

Hello. This is first patch that addresses test-suite fallout. All these tests fail in runtime. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >From f945460bccf6d54e790bf7c4cacac7cb5b915a28 Mon Sep 17 00:00:00 2001 From: marxin

Re: [PATCH][RFC] Instrument function exit with __builtin_unreachable in C++.

On 10/12/2017 10:48 AM, Jakub Jelinek wrote: > On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote: >> --- a/gcc/cp/constexpr.c >> +++ b/gcc/cp/constexpr.c >> @@ -1175,7 +1175,12 @@ cxx_eval_builtin_function_call (const constexpr_ctx >> *ctx, tree t, tree fun, >> { >>

Re: [patch] avoid printing leading 0 in widest_int hex dumps

On Tue, Oct 17, 2017 at 6:05 PM, Richard Sandiford wrote: > Andrew MacLeod writes: >> On 10/17/2017 08:18 AM, Richard Sandiford wrote: >>> Aldy Hernandez writes: Hi folks! Calling print_hex() on a widest_int

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

> > According to Agner's tables, gathers range from 12 ops (vgatherdpd) > > to 66 ops (vpgatherdd). I assume that CPU needs to do following: > > > > 1) transfer the offsets sse->ALU unit for address generation (3 cycles > >each, 2 ops) > > 2) do the address calcualtion (2 ops, probably 4 ops

Re: [PATCH] Fix failing test-case

> Hi. > > This fixes the test-case. Reason is that switch statement is not yet expanded > as decision tree, > which also contains a BB with count == 2000. > > Ready for trunk? OK, thanks Honza > Thanks, > Martin > > > > > >From 9845016dbcb4cd3160d49280c8d74b4851477496 Mon Sep 17 00:00:00

[PATCH] Fix failing test-case

Hi. This fixes the test-case. Reason is that switch statement is not yet expanded as decision tree, which also contains a BB with count == 2000. Ready for trunk? Thanks, Martin >From 9845016dbcb4cd3160d49280c8d74b4851477496 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed,

Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598, take 2)

Jakub Jelinek writes: > 2017-10-18 Jakub Jelinek > > PR lto/82598 > * simple-object.c (handle_lto_debug_sections): Copy over also > .note.GNU-stack section with unchanged name. > * simple-object-elf.c (SHF_EXECINSTR): Define. >

Re: [openacc, testsuite, committed] Enable libgomp.oacc-*/declare-*.{c,f90} for non-nvidia devices

On 10/17/2017 06:33 PM, Mike Stump wrote: On Oct 17, 2017, at 8:34 AM, Tom de Vries wrote: OK, if full testing is ok? I believe this was fully intentional and the presence/absence of explicit dg-do run can then be used to decide if it should loop through options or

Re: [patch, fortran] Fix PR 82567

Le 18/10/2017 à 04:05, Steve Kargl a écrit : On Tue, Oct 17, 2017 at 06:14:16PM -0700, Jerry DeLisle wrote: On 10/17/2017 03:36 PM, Thomas Koenig wrote: Hello world, this patch fixes a regression with long compile times, which came about due to our handling of array constructors at compile

Re: [PATCH] Canonicalize constant multiplies in division

On Tue, Oct 17, 2017 at 6:32 PM, Wilco Dijkstra wrote: > This patch implements some of the optimizations discussed in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026. > > Canonicalize x / (C1 * y) into (x * C2) / y. > > This moves constant multiplies out of the RHS of

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote: > A memory clobber would also make rtx_moveable_p return false, > thru the following case: > > case MEM: > if (type == OP_IN && MEM_READONLY_P (x)) > return rtx_moveable_p ( (x, 0), OP_IN); > return false; >

Re: [PATCH] Canonicalize negates in division

On Tue, Oct 17, 2017 at 6:30 PM, Wilco Dijkstra wrote: > This patch implements some of the optimizations discussed in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026. > > Canonicalize x / (- y) into (-x) / y. > > This moves negates out of the RHS of a division in

Re: [PATCH PR82574]Check that datref must be executed exactly once per iteration against outermost loop in nest

On Tue, Oct 17, 2017 at 4:50 PM, Bin Cheng wrote: > Hi, > The patch fixes ICE reported in PR82574. In order to distribute builtin > partition, we need > to check that data reference must be executed exactly once per iteration. In > distribution > for loop nest, this has to

Re: [PATCH GCC][7/7]Merge adjacent memset builtin partitions

On Tue, Oct 17, 2017 at 4:28 PM, Bin.Cheng wrote: > On Mon, Oct 16, 2017 at 5:27 PM, Bin.Cheng wrote: >> On Mon, Oct 16, 2017 at 5:00 PM, Bin.Cheng wrote: >>> On Mon, Oct 16, 2017 at 2:56 PM, Bin.Cheng

Re: Add an alternative vector loop iv mechanism

On Fri, Oct 13, 2017 at 4:10 PM, Richard Sandiford wrote: > Normally we adjust the vector loop so that it iterates: > >(original number of scalar iterations - number of peels) / VF > > times, enforcing this using an IV that starts at zero and increments > by one

Re: [patch] Fix PR debug/82509

On Thu, Oct 12, 2017 at 10:51 PM, Eric Botcazou wrote: > Hi, > > this PR reports a couple of problems with the support of the DW_AT_endianity > attribute associated with the scalar_storage_order source attribute: it does > not persist through typedefs and it can contaminate

[PATCH][OBVIOUS] Fix -Wimplicit-fallthrough in combine.c

Hi. I'm going to install the patch that suppresses -O0 warning: ../../gcc/combine.c: In function ‘rtx_code simplify_compare_const(rtx_code, machine_mode, rtx, rtx_def**)’: ../../gcc/combine.c:11789:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (const_op > 0)

Re: [PATCH] ira: volatile asm's are not moveable (PR82602)

Hi Segher, the patch looks ok for me. Just for my understanding: A memory clobber would also make rtx_moveable_p return false, thru the following case: case MEM: if (type == OP_IN && MEM_READONLY_P (x)) return rtx_moveable_p ( (x, 0), OP_IN); return false; ... case

[C++ Patch] PR 80991 ("ICE with __is_trivially_constructible in template")

Hi, a rather straightforward issue that we didn't notice so far only because in all our uses of __is_trivially_constructible either neither type is dependent or both are (eg, in library uses). The below handles in the obvious way a possible TREE_LIST - built node by node by

Re: [PATCH] Simplify floating point comparisons

On Tue, Oct 17, 2017 at 6:28 PM, Wilco Dijkstra wrote: > This patch implements some of the optimizations discussed in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026. > > Simplify (C / x > 0.0) into x > 0.0. > > If C is negative the comparison is reversed. > >

[PATCH] ira: volatile asm's are not moveable (PR82602)

A volatile asm statement can not be moved (relative to other volatile asm, etc.), but IRA could do it nevertheless. This patch fixes it. Testing on powerpc64-linux {-m32,-m64}; okay if it succeeds? Also for backports? Segher 2017-10-18 Segher Boessenkool

Re: [PATCH] enhance -Warray-bounds to handle strings and excessive indices

On Wed, Oct 18, 2017 at 5:34 AM, Martin Sebor wrote: > While testing my latest -Wrestrict changes I noticed a number of > opportunities to improve the -Warray-bounds warning. Attached > is a patch that implements a solution for the following subset > of these: > > PR

Re: [RFC] Sanitizers difference in between GCC and LLVM

On 10/18/2017 11:16 AM, Jakub Jelinek wrote: > On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote: >> Hi. >> >> I would like to use this thread to slightly describe differences in GCC and >> LLVM. >> I compared options support by both and: >> >> UBSAN: >> >> 1) >> gcc: error:

Re: [PATCH] Simplify floating point comparisons

On 17 October 2017 at 21:58, Wilco Dijkstra wrote: > This patch implements some of the optimizations discussed in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026. > > Simplify (C / x > 0.0) into x > 0.0. > > If C is negative the comparison is reversed. > > Simplify (x

Re: [PATCH PR/82546] tree node size

> On Oct 17, 2017, at 16:10 , Nathan Sidwell wrote: > > On 10/17/2017 05:26 AM, Richard Biener wrote: > >> Sorry for not looking at the patch before replying. The patch looks ok >> but shouldn't LANG_TYPE be also handled by the FE? LANG_TYPE itself >> is an odd beast if I may

Re: [PATCH, testsuite] Add dg-require-stack-size

On 10/17/2017 06:14 PM, Mike Stump wrote: On Oct 16, 2017, at 3:16 AM, Tom de Vries wrote: I noticed gcc.dg/tree-ssa/ldist-27.c failing for nvptx due to a too large stack size. OK for trunk? Hum. There is an existing mechanism (find-grep STACK_SIZE) in the tree

Re: [PATCH 2/2] S/390: Do not end groups after fallthru edge

> Preserving the sched state across basic blocks for your case works only if > the BBs are traversed > with the fall through edges coming first. Is that the case? We probably > should have a description > for s390_last_sched_state stating this. Committed as attached with an additional comment

Re: [RFC] Sanitizers difference in between GCC and LLVM

On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote: > Hi. > > I would like to use this thread to slightly describe differences in GCC and > LLVM. > I compared options support by both and: > > UBSAN: > > 1) > gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’ >

[RFC] Sanitizers difference in between GCC and LLVM

Hi. I would like to use this thread to slightly describe differences in GCC and LLVM. I compared options support by both and: UBSAN: 1) gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’ gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-assign’ gcc:

Re: [Patch, fortran] PR82550 - program using submodules fails to link

Dear Jerry, Thanks. I Committed as revision 253848 a still simpler patch that achieves the same end. Please see the attached and the ChangeLogs below. Regards Paul 2017-10-18 Paul Thomas PR fortran/82550 * trans_decl.c (gfc_get_symbol_decl): Procedure symbols

Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598, take 2)

On Wed, Oct 18, 2017 at 10:17:49AM +0200, Richard Biener wrote: > Works for me but as said, why's the linker even caring about > .note.GNU-stack in objects that do not contain executable code? The linker simply collects the notes from all *.o files. One case is when none of the objects have the

[Committed] S/390: Fix vec-cmp-2 testcase

The functions all call foo and therefore need a stack frame what makes them subject to shrink wrapping. Also all the additional instructions in the function body makes it fragile wrt instruction scheduling. Just set a global variable instead to circumvent this. Committed to mainline.

Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598)

On Wed, Oct 18, 2017 at 10:15:21AM +0200, Richard Biener wrote: > On Wed, 18 Oct 2017, Jakub Jelinek wrote: > > When creating lto debugobj, we copy over just the debug sections, > > and from the lack of .note.GNU-stack section then on various targets > > the linker implies RWE PT_GNU_STACK segment

Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598, take 2)

On Wed, 18 Oct 2017, Jakub Jelinek wrote: > On Wed, Oct 18, 2017 at 09:24:04AM +0200, Jakub Jelinek wrote: > > When creating lto debugobj, we copy over just the debug sections, > > and from the lack of .note.GNU-stack section then on various targets > > the linker implies RWE PT_GNU_STACK segment

Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598)

On Wed, 18 Oct 2017, Jakub Jelinek wrote: > Hi! > > When creating lto debugobj, we copy over just the debug sections, > and from the lack of .note.GNU-stack section then on various targets > the linker implies RWE PT_GNU_STACK segment header. Uh. But those objects don't even have a .text

[PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598, take 2)

On Wed, Oct 18, 2017 at 09:24:04AM +0200, Jakub Jelinek wrote: > When creating lto debugobj, we copy over just the debug sections, > and from the lack of .note.GNU-stack section then on various targets > the linker implies RWE PT_GNU_STACK segment header. > > Fixed by copying over also the

Re: [PATCH] Update -ffunction/data-sections documentation

On 17/10/17 21:39, Sandra Loosemore wrote: I think the patch is OK with those nits fixed. Thanks, for the review. Committed as: https://gcc.gnu.org/viewcvs/gcc?view=revision=253842 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

On Tue, 17 Oct 2017, Jan Hubicka wrote: > > On Tue, 17 Oct 2017, Jan Hubicka wrote: > > > > > Hi, > > > gether/scatter loads tends to be expensive (at least for x86) while we > > > now account them > > > as vector loads/stores which are cheap. This patch adds vectorizer cost > > > entry for

Re: [PATCH v3 1/14] D: The front-end (DMD) language implementation and license.

On 6 October 2017 at 14:51, Ian Lance Taylor wrote: > On Fri, Oct 6, 2017 at 1:34 AM, Iain Buclaw wrote: >> >> Out of curiosity, I did have a look at some of the tops of gofrontend >> sources this morning. They are all copyright the Go Authors, and are

[PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598)

Hi! When creating lto debugobj, we copy over just the debug sections, and from the lack of .note.GNU-stack section then on various targets the linker implies RWE PT_GNU_STACK segment header. Fixed by copying over also the .note.GNU-stack section if present. It is not 100% perfect solution if