Re: [PATCH] streambuf_iterator: avoid debug-dependent behaviour

Gentle reminder, ok to commit ? * include/bits/streambuf_iterator.h (istreambuf_iterator<>(const istreambuf_iterator&)): Remove useless noexcept qualificatio::operator*()): Do not capture iterator state in Debug assertion. (istreambuf_iterator<>::operator++()): Likewise.

[committed][PATCH] Stack clash protection 08/08 - V4

Andreas K. indicated privately he had no concerns WRT the s390 stack clash patches which are a combination of his work and mine. I believe the only changes since V4 was the addition of scheduling barriers, REG_STACK_CHECK notes and changes related to the params changing from byte counts to log2

Re: [PATCH] C++: tweak wording of explicitly-deleted methods

On 09/20/2017 01:54 PM, David Malcolm wrote: When we complain about uses of explicitly-deleted methods, it seems odd to me to refer to "declared here": /usr/include/c++/7/bits/stl_pair.h:292:17: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp,

[C++ PATCH] class member ordering

This patch makes the class member ordering well defined, in the face of decls with identical locations. We spuriously generate duplicate TYPE_DECLS, which we shouldn't do. But we can also reach this via (at least) template parameter pack expansions. Fixed by using DECL_UID as a more

Re: Statement Frontier Notes, Location Views, and Inlined Entry Point Markers

On Sep 7, 2017, Joseph Myers wrote: > On Fri, 25 Aug 2017, Alexandre Oliva wrote: >> for gcc/ChangeLog >> >> * common.opt (Wa, Wl, Wp, g, gz=): Add >> RejectNegative. >> (gno-column-info): Remove. >> (gcolumn-info): Drop RejectNegative. >> (gno-): New prefix. [...] >

Re: [PATCH] [i386, libgcc] PR 82196 -mcall-ms2sysv-xlogues emits wrong AVX/SSE MOV

On 09/19/2017 01:58 AM, Jakub Jelinek wrote: > What can be done in libgcc is detect in configure whether the assembler > supports AVX, and if not, provide some alternative (e.g. because the insns > are always the same, you could just code them as .byte or something similar). > > Say like: > ---

Re: [Patch, fortran] Bug fixes, including regressions, for the associate construct

On 09/20/2017 09:45 AM, Paul Richard Thomas wrote: > In the last update to the Parameterized Derived Types implementation, > I fixed PR60483 as a side effect. I then checked all the ASSOCIATE > bugs and noted that I was responsible for a number of regressions due > to a patch that I applied last

Re: [PATCH][aarch64] Fix error calls in aarch64 code so they can be tranlated

On Tue, 2017-09-19 at 10:49 -0600, Martin Sebor wrote: > On 09/19/2017 09:54 AM, Steve Ellcey wrote: > > On Tue, 2017-09-19 at 09:50 +0200, Frédéric Marchal wrote: > > >  > > > > > > > >    error (is_pragma > > > >   ? G_("missing name in %<#pragma target\(\"%s=\")%>") > > > >   :

libgo patch committed: Fix build with --enable-static=no

This patch to libgo fixes the build when configuring with --enable-static=no. It also ensures that a couple of .gox files that are only used for testing are built. Since they are only used for testing, nothing depends on them, so adding them to noinst_DATA makes sure they are built for the

[committed] fix test suite fallout from attribute ifunc type safety enhancement (PR 81854)

The type safety enhancement committed in r252976 exposed a type mismatch in the test for ifunc support in target-supports.exp that caused it to fail. That had the effect of disabling all the gcc.dg/attr-ifunc-*.c tests. Correcting the type error in target-supports.exp then exposed similar

[OpenACC] Add support for floating point type in GOMP_MAP_FIRSTPRIVATE_INT

Floating point values are frequently used in HPC applications accelerated by OpenACC. This patch teaches lower_omp_target how to transfer 32 and 64-bit floating point values to the offloaded functions using GOMP_MAP_FIRSTPRIVATE_INT by reinterpreting those values as integers. When I originally

Re: [committed][PATCH] Stack clash protection patch 02b/08 - V4

On 09/20/2017 03:02 PM, Joseph Myers wrote: > This breaks the build for powerpcspe. > > powerpcspe: > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/powerpcspe/powerpcspe.c:29691:10: > error: 'flag_stack_check_protection' was not declared in this scope >|| flag_stack_check_protection) >

Re: [committed][PATCH] Stack clash protection patch 02b/08 - V4

On 09/20/2017 03:02 PM, Joseph Myers wrote: > This breaks the build for powerpcspe. > > powerpcspe: > /scratch/jmyers/glibc-bot/src/gcc/gcc/config/powerpcspe/powerpcspe.c:29691:10: > error: 'flag_stack_check_protection' was not declared in this scope >|| flag_stack_check_protection) >

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

On 20/09/17 18:59 +0100, Jonathan Wakely wrote: On 20/09/17 17:52 +0100, Jonathan Wakely wrote: On 20/09/17 16:36 +0100, Jonathan Wakely wrote: On 04/09/17 16:48 +0100, Jonathan Wakely wrote: On 30/07/17 15:01 +0200, Daniel Krügler wrote: 2017-07-28 22:40 GMT+02:00 Daniel Krügler

[committed][PATCH] Fix minor stack-clash failures on x86

Jakub (and likely HJ) ran into a case where the stack clash code was looking at the INTVAL of an object that wasn't actually a CONST_INT. I won't start my rant about why this shouldn't be possible. Anyway, this patch fixes that and turns several == CONST_INT tests to use CONST_INT_P. This

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 20 Sep 2017, Martin Sebor wrote: > The warning is because in the declaration: > > extern __typeof (__libc_memmove) > memmove __attribute__ ((alias ("__libc_memmove"))); > > __typeof (__libc_memmove) is the same as the type of memmove > as it should be but the type of the alias

Re: [PATCH] detect incompatible aliases (PR c/81854)

On 09/20/2017 12:01 PM, Joseph Myers wrote: On Wed, 20 Sep 2017, Martin Sebor wrote: I'm not intimately familiar with the Glibc ifunc infrastructure to suggest a good solution here, so assuming this works my only idea is to suppress the warning for these builds. Joseph, do you have a better

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

On Sun, Sep 10, 2017 at 2:11 PM, Ian Lance Taylor wrote: > On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov > wrote: >> >> Hello Ian, >> thanks for review. >> I've updated the patch, can you please take a look. > > Apologies again for the length of

Re: [committed][PATCH] Stack clash protection patch 02b/08 - V4

This breaks the build for powerpcspe. powerpcspe: /scratch/jmyers/glibc-bot/src/gcc/gcc/config/powerpcspe/powerpcspe.c:29691:10: error: 'flag_stack_check_protection' was not declared in this scope || flag_stack_check_protection) ^ -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 20 Sep 2017, Steve Ellcey wrote: > On Wed, 2017-09-20 at 18:01 +, Joseph Myers wrote: > >  > > (It may nevertheless be a good idea to set  > > default_gnu_indirect_function=yes for AArch64 configurations in GCC > > that  > > use glibc.) > > > > I have submitted a patch for that. >

[PATCH] toplev: read from /dev/urandom only when needed

Hi, Most compiler invocations don't actually need an entropy source, so open-read-close syscall sequence on /dev/urandom that GCC performs on each startup is useless (and can easily be avoided). This patch makes GCC read entropy from /dev/urandom lazily on first call to get_random_seed, and en

[Patch] Edit contrib/ files to download gfortran prerequisites

Attached is a patch that adds the downloading of gfortran prerequisites OpenCoarrays and MPICH in the contrib/download_prerequisites script.  The patch also provides a useful error message when neither wget or curl are available on the target platform.  I tested this patch with several choices

Re: [C++ PATCH] P0409R2 - allow lambda capture [=, this]

On 09/20/2017 12:14 PM, Jakub Jelinek wrote: Hi! Another easy patch where c++2a just allows something we've already accepted with a pedwarn. Bootstrapped/regtested on x86_64-linux and i686-linux, including make check-c++-all, ok for trunk? ok, thanks -- Nathan Sidwell

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Sep 20, 2017, at 2:14 PM, Bill Schmidt wrote: > > On Sep 20, 2017, at 3:49 AM, Richard Sandiford > wrote: >> >> But I think this shows up another problem. In the vectorised loop, >> we have 1 copy of the load and 4 copies of the

[PATCH] C++: tweak wording of explicitly-deleted methods

When we complain about uses of explicitly-deleted methods, it seems odd to me to refer to "declared here": /usr/include/c++/7/bits/stl_pair.h:292:17: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = X; _Dp =

[PATCH] C++: underline parameters in mismatching function calls

When we have a type mismatch in a C++ function call, e.g. extern int callee (int one, const char *two, float three); int caller (int first, int second, float third) { return callee (first, second, third); } we currently emit something like this: test.c: In function 'int

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Sep 20, 2017, at 3:49 AM, Richard Sandiford wrote: > > But I think this shows up another problem. In the vectorised loop, > we have 1 copy of the load and 4 copies of the ABS (after unpacking). > But vect_analyze_slp_cost_1 is being called with ncopies_for_cost

[C++ PATCH] P0409R2 - allow lambda capture [=, this]

Hi! Another easy patch where c++2a just allows something we've already accepted with a pedwarn. Bootstrapped/regtested on x86_64-linux and i686-linux, including make check-c++-all, ok for trunk? 2017-09-20 Jakub Jelinek P0409R2 - allow lambda capture [=, this]

[PATCH] Improve x86_64 *movqi_internal at -Os (PR target/82260)

Hi! As mentioned in the PR, in some cases (one or both *movqi_internal operands %dil/%sil/%bpl/%spl, neither %r*b) the movl variant is smaller and in cases where movb and movl is the same size, we might as well choose the faster instruction. Bootstrapped/regtested on x86_64-linux and i686-linux,

Re: [C++ PATCH] Add a testcase for -std=c++1z

OK. On Mon, Sep 18, 2017 at 2:48 PM, Jakub Jelinek wrote: > Hi! > > On Fri, Sep 15, 2017 at 12:08:07PM -0400, Nathan Sidwell wrote: >> On 09/14/2017 04:26 PM, Jakub Jelinek wrote: >> > Hi! >> > >> > Given https://herbsutter.com/2017/09/06/c17-is-formally-approved/ >> > this

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 20 Sep 2017, Steve Ellcey wrote: > On Wed, 2017-09-20 at 18:01 +, Joseph Myers wrote: > >  > > (It may nevertheless be a good idea to set  > > default_gnu_indirect_function=yes for AArch64 configurations in GCC > > that  > > use glibc.) > > > > I have submitted a patch for that. >

Re: [PATCH][2/2] early LTO debug, main part

On 09/20/2017 02:31 AM, Jakub Jelinek wrote: > On Wed, Sep 20, 2017 at 10:20:03AM +0200, Richard Biener wrote: >> Anyway, I did a quick LTO bootstrap with your patch and it seems >> to work fine. >> >> Can you add a testcase verifying -gdwarf-5 works ok (properly >> emitting a debug_line_str

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 2017-09-20 at 18:01 +, Joseph Myers wrote: >  > (It may nevertheless be a good idea to set  > default_gnu_indirect_function=yes for AArch64 configurations in GCC > that  > use glibc.) > I have submitted a patch for that. https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00285.html

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 20 Sep 2017, Steve Ellcey wrote: > > I'm not intimately familiar with the Glibc ifunc infrastructure > > to suggest a good solution here, so assuming this works my only > > idea is to suppress the warning for these builds. > > > > Joseph, do you have a better suggestion? > > > > Martin

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

On 09/19/2017 03:00 PM, Joseph Myers wrote: On Tue, 19 Sep 2017, Martin Sebor wrote: In general, the data structures where you need to ensure manually that if attribute A is listed in EXCL for B, then attribute B is also listed in EXCL for A, seem concerning. I'd expect either data structures

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 20 Sep 2017, Martin Sebor wrote: > I'm not intimately familiar with the Glibc ifunc infrastructure > to suggest a good solution here, so assuming this works my only > idea is to suppress the warning for these builds. > > Joseph, do you have a better suggestion? Is the warning because of

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

On 20/09/17 17:52 +0100, Jonathan Wakely wrote: On 20/09/17 16:36 +0100, Jonathan Wakely wrote: On 04/09/17 16:48 +0100, Jonathan Wakely wrote: On 30/07/17 15:01 +0200, Daniel Krügler wrote: 2017-07-28 22:40 GMT+02:00 Daniel Krügler : 2017-07-28 22:29 GMT+02:00

libgo patch committed: enable ParseDirent for AIX

This libgo patch from Tony Reix enables ParseDirent for AIX. Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision 253021) +++

Re: [PATCH] detect incompatible aliases (PR c/81854)

> I'm not intimately familiar with the Glibc ifunc infrastructure > to suggest a good solution here, so assuming this works my only > idea is to suppress the warning for these builds. > > Joseph, do you have a better suggestion? > > Martin Now that I know building GCC with

libgo patch committed: Work around AIX getsockname bug

This patch from Tony Reix works around a bug in getsockname on AIX. Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. This actually includes part of the previous patch, as I forgot to run `svn add`. Ian Index: gcc/go/gofrontend/MERGE

Re: [PATCH] detect incompatible aliases (PR c/81854)

On 09/20/2017 10:38 AM, Steve Ellcey wrote: On Wed, 2017-09-20 at 10:17 -0600, Martin Sebor wrote: The comment copied below from sysdeps/aarch64/multiarch/memmove.c suggests this might be deliberate: /* Redefine memmove so that the compiler won't complain about the type mismatch with the

Re: [PATCH] detect incompatible aliases (PR c/81854)

Interesting new data point.  aarch64 GCC does not enable the resolver/indirect function feature by default (--enable-gnu-indirect- function is not set by default).  If I enable this on the GCC build then GCC can build glibc.  Without it, the glibc build fails. Steve Ellcey sell...@cavium.com On

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

On 20/09/17 16:36 +0100, Jonathan Wakely wrote: On 04/09/17 16:48 +0100, Jonathan Wakely wrote: On 30/07/17 15:01 +0200, Daniel Krügler wrote: 2017-07-28 22:40 GMT+02:00 Daniel Krügler : 2017-07-28 22:29 GMT+02:00 Daniel Krügler :

Re: [PATCH] Fix PR79622

On Tue, Sep 19, 2017 at 5:54 PM, Tamar Christina wrote: > -- sorry for the duplicate, forgot to post to list as well first time -- > > Hi Richard, > > The testcase seems to fail on aarch64-none-elf when -O1 or -O2, > > -O0, -Os and -O3 seem to work fine. > > dc[0] ends up

Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

On Tue, Sep 19, 2017 at 5:47 PM, Jack Howarth wrote: > On Mon, Sep 18, 2017 at 1:48 PM, Mike Stump wrote: >> I was hoping an RM would approve this as it seems just a hair beyond a >> normal darwin approval. I'm fine with this, and it does help

[Patch, fortran] Bug fixes, including regressions, for the associate construct

In the last update to the Parameterized Derived Types implementation, I fixed PR60483 as a side effect. I then checked all the ASSOCIATE bugs and noted that I was responsible for a number of regressions due to a patch that I applied last year. I determined to fix them and found that I couldn't

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Wed, 2017-09-20 at 10:17 -0600, Martin Sebor wrote: >  > The comment copied below from sysdeps/aarch64/multiarch/memmove.c > suggests this might be deliberate: > > /* Redefine memmove so that the compiler won't complain about the > type > mismatch with the IFUNC selector in strong_alias,

[PATCH] Fix failing C++17 test

The DejaGnu directives were in the wrong order, so this test was UNSUPPORTED and the error went unnoticed. Fixed like so. * testsuite/24_iterators/range_access_cpp17.cc: Fix order of dg-do and dg-options directives. Fix invalid test. Tested powerpc64le-linux, committed to trunk.

[PATCH] PR libstdc++/81469 deprecate std::uncaught_exception for C++17

C++17 deprecates uncaught_exception in favour of uncaught_exceptions, so this adds the attribute. PR libstdc++/81469 * libsupc++/exception (uncaught_exception): Deprecate for C++17. * testsuite/18_support/exception_ptr/62258.cc: Add -Wno-deprecated. *

[PATCH] Deprecate nested types in std::hash

C++17 deprecates the argument_type and result_type members of std::hash specializations. This adds the deprecated attribute to them. C++17 also deprecates those nested typedefs (and weak result types) in owner_less, plus, minus, function, reference_wrapper, bind, {multi,}map::value_compare etc.

Re: [PATCH] detect incompatible aliases (PR c/81854)

On 09/20/2017 09:37 AM, Steve Ellcey wrote: On Tue, 2017-09-19 at 09:16 -0600, Martin Sebor wrote: On 09/18/2017 03:44 PM, Joseph Myers wrote: On Mon, 18 Sep 2017, Martin Sebor wrote: It's meant as an escape hatch. It allows declaring compatibility symbols, for example by the libstdc++

Re: match.pd handling of three-constant bitops

On Wed, Sep 20, 2017 at 2:18 PM, Richard Sandiford wrote: > natch.pd tries to reassociate two bit operations if both of them have > constant operands. However, with the polynomial integers added later, > there's no guarantee that a bit operation on two integers can

Re: Tighten tree-ssa-ccp.c:get_value_for_expr condition

On Wed, Sep 20, 2017 at 2:12 PM, Richard Sandiford wrote: > bit_value_unop and bit_value_binop require constant values > to be INTEGER_CSTs: > > gcc_assert ((rval.lattice_val == CONSTANT >&& TREE_CODE (rval.value) == INTEGER_CST) > ||

Re: Add missing int_cst_rangeN checks to tree-vrp.c

On Wed, Sep 20, 2017 at 2:09 PM, Richard Sandiford wrote: > The BIT_AND_EXPR handling in extract_range_from_binary_expr_1 > was using value_range_constant_singleton without first checking > whether the range was a constant. The earlier handling was correctly >

Re: range_int_cst_p handling in extract_range_from_binary_expr_1

On Wed, Sep 20, 2017 at 2:06 PM, Richard Sandiford wrote: > extract_range_from_binary_expr_1 had: > > if (range_int_cst_p () > && range_int_cst_p () > && TYPE_OVERFLOW_WRAPS (expr_type)) > ... > ... >

Re: [PATCH] Add offset_int to guard HOST_WIDE_INT overflow (PR tree-optimization/82042).

On Wed, Sep 20, 2017 at 9:50 AM, Martin Liška wrote: > Hi. > > This is partial fix for the PR, where I calculate 2 offsets in offset_int > type. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? That seems to poorly handle

Re: [PATCH] detect incompatible aliases (PR c/81854)

On Tue, 2017-09-19 at 09:16 -0600, Martin Sebor wrote: > On 09/18/2017 03:44 PM, Joseph Myers wrote: > > > > On Mon, 18 Sep 2017, Martin Sebor wrote: > > > > > > > > It's meant as an escape hatch.  It allows declaring compatibility > > > symbols, for example by the libstdc++ _GLIBCXX_3_4_SYMVER

Re: [PATCH] PR libstdc++/79162 ambiguity in string assignment due to string_view overload (LWG 2946)

On 04/09/17 16:48 +0100, Jonathan Wakely wrote: On 30/07/17 15:01 +0200, Daniel Krügler wrote: 2017-07-28 22:40 GMT+02:00 Daniel Krügler : 2017-07-28 22:29 GMT+02:00 Daniel Krügler : 2017-07-28 22:25 GMT+02:00 Tim Song

Re: Don't query the frontend for unsupported types

On September 20, 2017 2:36:03 PM GMT+02:00, Richard Sandiford wrote: >When forcing a constant of mode MODE into memory, force_const_mem >asks the frontend to provide the type associated with that mode. >In principle type_for_mode is allowed to return null, and

Re: Make more use of simplify_gen_binary

On September 20, 2017 2:30:53 PM GMT+02:00, Richard Sandiford wrote: >This patch replaces various places that previously used: > > if (GET_CODE (y) == CONST_INT) >... plus_constant (..., x, [-]INTVAL (y)) ... > else >... gen_rtx_PLUS/MINUS (..., x, y) ...

Re: Add copy_rtx call to RTL loop unroller

On September 20, 2017 2:27:49 PM GMT+02:00, Richard Sandiford wrote: >This is needed if the step is an unshared constant, like many >(const ...)s are. Without this patch, libgfortran would fail >to build for SVE. > >Tested on aarch64-linux-gnu, x86_64-linux-gnu and

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

On 09/20/2017 01:24 AM, Martin Liška wrote: > > Hello. > > Thank you Jeff for very verbose explanation what's happening. I'm planning to > do > follow-up of this patch that will include clustering for bit-tests and jump > tables. > Maybe that will make aforementioned issues even more

libgo patch commited: AIX updates

This patch by Tony Reix adds some AIX updates, notably for the recent 1.9 update. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE

Re: [PATCH][AArch64] PR71951: Fix unwinding with -fomit-frame-pointer

On Tue, Aug 15, 2017 at 05:27:37PM +0100, Wilco Dijkstra wrote: > > ping This seems like a bit of a theoretical issue as we would normally build libgcc with -fno-omit-frame-pointer anyway, but it can't hurt to guarantee this, so OK. Thanks, James > From: Wilco Dijkstra > Sent: 31 July 2017

Re: Fix unguarded uses of tree_to_uhwi

On September 20, 2017 2:15:19 PM GMT+02:00, Richard Sandiford wrote: >This patch uses tree_fits_uhwi_p to protect a previously unguarded >use of tree_to_uhwi. Without this we would ICE for variable-sized >types. > >Tested on aarch64-linux-gnu, x86_64-linux-gnu and

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Sep 20, 2017, at 3:49 AM, Richard Sandiford wrote: > > Bill Schmidt writes: >> On Sep 19, 2017, at 4:21 PM, Bill Schmidt >> wrote: >>> On Sep 19, 2017, at 3:58 PM, Richard Sandiford >>>

Re: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

On Wed, Sep 20, 2017 at 3:59 PM, Shalnov, Sergey wrote: > Uros, > > This is the ChangeLog > > 2017-09-20 Sergey Shalnov sergey.shal...@intel.com > * config/i386/i386.opt (mprefer-avx256): command line documentation added for > -mprefer-avx256 > * config/i386/i386.c

Re: [PATCH] cp: fix location comparison in member_name_cmp

On Wed, 20 Sep 2017, Nathan Sidwell wrote: > > You can use the gcc_assert mentioned in the previous email on GCC > > bootstrap/regtest to find examples. For me, the following example breaks > > (no > > command line flags needed, just bare 'cc1plus t.i'): > > > > struct > > { > >int a, b, c,

Re: 0005-Part-5.-Add-x86-CET-documentation

On Wed, Sep 20, 2017 at 11:20 AM, Tsimbalist, Igor V wrote: > Uros, could you please review this patch as it's a part of x86 specific > changes you have reviewed already. Please proofread and spell-check the text. There are grammatical errors, e.g.: +When compiled

Re: [PATCH] cp: fix location comparison in member_name_cmp

On 09/19/2017 06:07 AM, Alexander Monakov wrote: On Tue, 19 Sep 2017, Nathan Sidwell wrote: After recent changes, the member_name_cmp qsort comparator can indicate A < B < A (i.e. lacks anti-commutativity) for distinct TYPE_DECL nodes that have the same source location. If their order doesn't

RE: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

Uros, This is the ChangeLog 2017-09-20 Sergey Shalnov sergey.shal...@intel.com * config/i386/i386.opt (mprefer-avx256): command line documentation added for -mprefer-avx256 * config/i386/i386.c (ix86_preferred_simd_mode): Prefer 256-bit AVX modes when the flag -mprefer-avx256 is on. *

Re: [PATXH, i386]: Add BT setcc patterns

On Tue, Sep 19, 2017 at 11:17 PM, Uros Bizjak wrote: > Hello! > > As mentioned in PR 82259. These are similar to existing BT jcc patterns. > > 2017-09-19 Uros Bizjak > > * config/i386/i386.md (*scc_bt): New insn_and_split pattern. > (*scc_bt_1):

Re: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

On Wed, Sep 20, 2017 at 10:48 AM, Shalnov, Sergey wrote: > Uros, > Could you please merge the patch into mainline? Please send updated ChangeLog that describes all changes in the patch. Uros.

[PATCH] Remove non-standard std::copy_exception function

We should have removed this function years ago. It was the original name for std:make_exception_ptr in C++0x drafts, which we kept for backwards compatibility, but deprecated since 4.9.0. It's not in any C++ standard, so should be removed now. * libsupc++/exception_ptr.h

[PATCH] PR libstdc++/82262 fix std::hash<std::optional>

The std::hash specialization for std::optional was missing a remove_const_t so tried to use a disabled hash specialization. PR libstdc++/82262 * include/std/optional (__optional_hash_call_base): Add template parameter for remove_const_t<_Tp> and use it consistently.

[AArch64] Patches for review

Hi, Here is the list of my AArch64 patches for review: * https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02040.html (Fix unwinding with -fomit-frame-pointer) * https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01216.html (Fix symbol offset limit) *

Re: [AArch64], patch] PR71727 fix -mstrict-align

Hi, On 11 September 2017 at 10:45, Andrew Pinski wrote: > On Tue, Jul 18, 2017 at 5:50 AM, Christophe Lyon > wrote: >> Hello, >> >> I've received a complaint that GCC for AArch64 would generate >> vectorized code relying on unaligned memory

Re: [PING, ARM] Handle DWARF2_UNWIND_INFO in arm_except_unwind_info

On Wed, Sep 20, 2017 at 1:32 PM, Olivier Hainque wrote: > Hello, > > Ping for > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00278.html > >> On Aug 3, 2017, at 11:39 , Olivier Hainque wrote: >> >> On top of the correction for fallouts proposed in >>

Don't query the frontend for unsupported types

When forcing a constant of mode MODE into memory, force_const_mem asks the frontend to provide the type associated with that mode. In principle type_for_mode is allowed to return null, and although one use site correctly handled that, the other didn't. I think there's agreement that it's bogus to

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

On Wed, Sep 20, 2017 at 1:53 AM, Maxim Ostapenko wrote: > Hi Ian, > > On 12/09/17 17:05, Ian Lance Taylor via gcc-patches wrote: >> >> On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov >> wrote: >>> >>> Thanks for answer. >>> I understood

Re: [PING, ARM] Handle DWARF2_UNWIND_INFO in arm_except_unwind_info

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00278.html > On Aug 3, 2017, at 11:39 , Olivier Hainque wrote: > > On top of the correction for fallouts proposed in > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00271.html > > the attached patch is

Make more use of simplify_gen_binary

This patch replaces various places that previously used: if (GET_CODE (y) == CONST_INT) ... plus_constant (..., x, [-]INTVAL (y)) ... else ... gen_rtx_PLUS/MINUS (..., x, y) ... with single calls to simplify_gen_binary. This allows them to handle polynomial integers as well as

Re: [RFC][PATCH] ipa: fix dumping with deleted multiversioning nodes

> On 09/18/2017 11:08 AM, Evgeny Kudryashov wrote: > > Hello, > > > > The code below causes an internal compiler error in cc1plus (trunk on > > x86-64) if it is compiled with -fdump-ipa-cgraph. > > > > int foo () __attribute__ ((target ("default"))); > > int foo () __attribute__ ((target

Add copy_rtx call to RTL loop unroller

This is needed if the step is an unshared constant, like many (const ...)s are. Without this patch, libgfortran would fail to build for SVE. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu. OK to install? Richard 2017-09-20 Richard Sandiford

Re: Enable no-exec stacks for more targets using the Linux kernel

On Wed, 20 Sep 2017, Andreas Schwab wrote: > On Sep 19 2017, Joseph Myers wrote: > > > I've sent a glibc patch > > . I think the > > key questions for architecture experts now are: on each of those three >

Re: Enable no-exec stacks for more targets using the Linux kernel

On Wed, 20 Sep 2017, Nagaraju Mekala wrote: > > I've sent a glibc patch > > . I think the > >key questions for architecture experts now are: on each of those three > >architectures, do trampolines ever require executable stacks, and,

SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn

This is needed by the later SVE LAST reductions, where an 8-bit or 16-bit result is zero- rather than sign-extended to 32 bits. I think it could occur in other situations too. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu. OK to install? Richard 2017-09-20 Richard

match.pd handling of three-constant bitops

natch.pd tries to reassociate two bit operations if both of them have constant operands. However, with the polynomial integers added later, there's no guarantee that a bit operation on two integers can be folded at compile time. This means that the pattern can trigger for operations on three

Fix unguarded uses of tree_to_uhwi

This patch uses tree_fits_uhwi_p to protect a previously unguarded use of tree_to_uhwi. Without this we would ICE for variable-sized types. Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu. OK to install? Richard 2017-09-20 Richard Sandiford

Tighten tree-ssa-ccp.c:get_value_for_expr condition

bit_value_unop and bit_value_binop require constant values to be INTEGER_CSTs: gcc_assert ((rval.lattice_val == CONSTANT && TREE_CODE (rval.value) == INTEGER_CST) || wi::sext (rval.mask, TYPE_PRECISION (TREE_TYPE (rhs))) == -1); However, when deciding whether to

Add missing int_cst_rangeN checks to tree-vrp.c

The BIT_AND_EXPR handling in extract_range_from_binary_expr_1 was using value_range_constant_singleton without first checking whether the range was a constant. The earlier handling was correctly guarded: /* If either input range contains only non-negative values we can

[PATCH][GRAPHITE] Fix PR80213

The following fixes more cases of "lost" PHIs which happen because the block with the loop-closed PHI nodes only get into the SCOP via merge_sese. But if we don't include that we do not handle reductions properly. Fixed by always including that block in SESE regions. Bootstrapped and tested on

range_int_cst_p handling in extract_range_from_binary_expr_1

extract_range_from_binary_expr_1 had: if (range_int_cst_p () && range_int_cst_p () && TYPE_OVERFLOW_WRAPS (expr_type)) ... ... extract_range_from_multiplicative_op_1 (vr, code, , ); but extract_range_from_multiplicative_op_1 also requires

[PATCH] Add testcase for PR77362

Which no longer fails. Tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-09-20 Richard Biener PR tree-optimization/77362 * gcc.dg/graphite/pr77362.c: New testcase. Index: gcc/testsuite/gcc.dg/graphite/pr77362.c

[PATCH] Fix PR82264

One forgets that dyn_cast doesn't work like dynamic_cast ... Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2017-09-20 Richard Biener PR tree-optimization/82264 * tree-ssa-sccvn.c (vn_phi_eq): Use safe_dyn_cast to check

Re: [PATCH] Remove CANADIAN, that break compilation for foreign target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212 On Fri, 20 May 2016 16:10:50 +0300 Petr Ovtchenkov wrote: > Some old ad-hoc (adding -I/usr/include to compiler > flags) break compilation of libstdc++ for foreign > target architecture (due to compiler see includes > of

Re: [PATCH][AArch64] Add BIC-imm and ORR-imm SIMD pattern

On Mon, Aug 07, 2017 at 02:56:09PM +0100, Sudi Das wrote: > > Hi Richard > > I have updated the patch according to your comments. Thanks for pointing it > out and sorry for the delay! Hi Sudi, I've taken a look at your patch - at a high level, I think that adding

[PATCH] Remove CANADIAN, that break compilation for foreign target

Some old ad-hoc (adding -I/usr/include to compiler flags) break compilation of libstdc++ for foreign target architecture (due to compiler see includes of native). --- libstdc++-v3/acinclude.m4 | 5 - libstdc++-v3/configure| 22 -- libstdc++-v3/configure.ac | 14

RE: 0005-Part-5.-Add-x86-CET-documentation

Uros, could you please review this patch as it's a part of x86 specific changes you have reviewed already. Thanks, Igor > -Original Message- > From: Tsimbalist, Igor V > Sent: Tuesday, August 1, 2017 10:57 AM > To: 'gcc-patches@gcc.gnu.org' > Cc: Tsimbalist,

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

Hi Ian, On 12/09/17 17:05, Ian Lance Taylor via gcc-patches wrote: On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov wrote: Thanks for answer. I understood all points which you mentioned, but can't find last one It seems to work out the file name a second time,

  1   2   >