Go patch committed: Don't always call gimplify_function_tree

This patch to the GCC interface to the Go frontend changes the final step of the frontend to not always call gimplify_function_tree. There is no need for it, as the cgraphunit code will do that if required. However, when we don't call gimplify_function_tree we do have to call

Re: [PATCH/AARCH64] Add OcteonTX for -mcpu=

On Tue, Oct 30, 2018 at 10:21 AM Richard Earnshaw (lists) wrote: > > On 30/10/2018 17:06, Andrew Pinski wrote: > > Hi all, > > There was a name change of the Products, ThunderX T81 and ThunderX > > T83 to OcteonTX family name. This change was done a few years ago but > > I had not submmitted

Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count

On Wed, Oct 31, 2018 at 10:36 PM Jeff Law wrote: > > On 10/31/18 12:30 AM, bin.cheng wrote: > > Hi, > > In new profile probability/count infra, we have different precision quality > > categories, > > and probabilities/counts of different categories are not supposed to be > > compared or > >

Re: [PATCH, d] Disable D on systems where it is known not to work.

On Wed, 31 Oct 2018 at 22:56, Joseph Myers wrote: > > On Wed, 31 Oct 2018, Iain Sandoe wrote: > > > maybe if building D .. then libphobos should be automatic > > (i.e. the opt-in/out for the targets under development is to choose to > > build/not build D explicitly)? > > > > [ that would avoid

[PATCH, libphobos] Fix libgphobos.spec in the wrong place with --enable-version-specific-runtime-libs

Hi, This adds --enable-version-specific-runtime-libs configure option to libphbos. Also uncovered that MULTISUBDIR wasn't being set correctly when this option was enabled. Built and checked with make install-target-libphobos. Ok for trunk? -- Iain --- libphobos/ChangeLog: 2018-11-01 Iain

Re: [PATCH, AArch64 v2 01/11] aarch64: Simplify LSE cas generation

On 10/31/18 10:02 AM, Richard Henderson wrote: > On 10/30/18 7:48 PM, James Greenhalgh wrote: >> On Tue, Oct 02, 2018 at 11:19:05AM -0500, Richard Henderson wrote: >>> The cas insn is a single insn, and if expanded properly need not >>> be split after reload. Use the proper inputs for the insn.

Re: C++ PATCH to Implement P0846R0, ADL and function templates [v2]

On Mon, Oct 29, 2018 at 05:59:13PM -0400, Jason Merrill wrote: > On 10/28/18 3:56 PM, Marek Polacek wrote: > > This patch implements P0846R0: ADL and Function Templates that are not > > Visible > > > > whereby a name for which

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On Oct 12, 2018, Alexandre Oliva wrote: > * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, > based on MINGW_DEFAULT_LARGE_ADDR_AWARE. > (LINK_SPEC): Insert it. > * config/i386/mingw-264.h: Likewise. ^ s/2/w/, fixing... Now, it

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

On Wed, Oct 31, 2018 at 06:39:31PM +0300, Alexander Monakov wrote: > FWIW they went ahead and worked around the problem on their end via > assembler macros They have to anyway; they have to support GCC < 9 for a while. At the very least until GCC 9 is released! ;-) > (and Borislav's ping has

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On Wed, Oct 31, 2018 at 04:55:26PM -0500, Richard Henderson wrote: > On 10/31/18 5:51 PM, Will Deacon wrote: > > Aha, maybe this is the problem. An acquire fence on AArch64 is implemented > > using a DMB LD instruction, which orders prior reads against subsequent > > reads and writes. However, the

[PATCH] Fix sanitizer frame unwind on 32-bit ABIs (again)

This re-applies r258525, and this time adds it to LOCAL_PATCHES. Is this okay for trunk? Segher 2018-10-31 Segher Boessenkool libsanitizer/ * LOCAL_PATCHES: Add r258525. * sanitizer_common/sanitizer_stacktrace.cc (BufferedStackTrace::FastUnwindStack): Use the

Re: [PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

On Wed, Oct 31, 2018 at 03:23:27PM +, Richard Earnshaw (lists) wrote: > On 31/10/2018 14:10, co...@sdf.org wrote: > > + > > +# Currently there is a bug somewhere in GCC's alias analysis > > +# or scheduling code that is breaking _fpmul_parts in fp-bit.c. > > +# Disabling function inlining is a

Re: [PATCH, d] Disable D on systems where it is known not to work.

On Wed, 31 Oct 2018, Iain Sandoe wrote: > maybe if building D .. then libphobos should be automatic > (i.e. the opt-in/out for the targets under development is to choose to > build/not build D explicitly)? > > [ that would avoid having to have the UNSUPPORTED stuff in the >

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On 10/31/18 5:51 PM, Will Deacon wrote: > Aha, maybe this is the problem. An acquire fence on AArch64 is implemented > using a DMB LD instruction, which orders prior reads against subsequent > reads and writes. However, the architecture says: > > | The ST instructions, and LD instructions where

Re: [PATCH, d] Disable D on systems where it is known not to work.

On 31.10.18 05:37, Alan Modra wrote: > On Tue, Oct 30, 2018 at 09:07:30PM +0100, Iain Buclaw wrote: >> On Tue, 30 Oct 2018 at 20:50, Andreas Schwab wrote: >>> >>> On Okt 30 2018, Iain Buclaw wrote: >>> This turns off D front-end where there's been reported bootstrap problems that need

[PATCH, d] Commited fix for PR 87825

Hi, This fixes build for profiledbootstrap when D is enabled. Commited as obvious. -- Iain --- gcc/d/ChangeLog: 2018-10-31 Iain Buclaw PR d/87825 * Make-lang.in (d/idgen) Link with BUILD_LINKERFLAGS. (d/impcvgen): Likewise. --- diff --git a/gcc/d/Make-lang.in

Re: [PATCH] use MAX_OFILE_ALIGNMENT to validate attribute aligned (PR 87795)

On 10/30/2018 04:34 PM, Joseph Myers wrote: On Tue, 30 Oct 2018, Martin Sebor wrote: So it seems that the attribute handler should be using this macro instead. I also took the liberty to add more detail to the error Note that it should only be used for alignments relevant to the object file

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, Oct 31, 2018 at 10:04 AM, Joseph Myers wrote: > On Wed, 31 Oct 2018, Thomas Koenig wrote: > >> Am 31.10.18 um 04:26 schrieb Joseph Myers: >> > This patch (diffs to generated files omitted below) updates GCC to use >> > autoconf 2.69 and automake 1.15.1. >> >> I think this should fix PR

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

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: > > >> > > >> Add -mzero-caller-saved-regs=[skip|used|all] command-line option and

Re: [PATCH, d] Disable D on systems where it is known not to work.

Hi Iain > On 31 Oct 2018, at 19:35, Rainer Orth wrote: > > Hi Iain, > >> This turns off D front-end where there's been reported bootstrap >> problems that need further investigation. Also added a configure.tgt >> for libphobos to allow enabling for targets where there's known good >> runtime

Re: [PATCH, d] Disable D on systems where it is known not to work.

Hi Iain, > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed by existing continuous integration. > > For both,

[ABI PATCH] static anonymous unions of function scope

I fell over this on the modules branch, first with simplifying our internal structures, and then finding a bug. Local entities can need a discriminator in their mangling. We didn't always get that right. Firstly, we rarely need a discriminator, and a non-zero one is even rarer. So there's

[patch, testsuite] Committed test for PR 20520

Hi, I just committed the test case below so the bug can be closed. The error message is less than ideal, but at least it is something. Maybe I'll file a separate PR about translating error messages about artificial variables to user's variables. Regards Thomas 2018-10-31 Thomas

Re: [C++ Patch] PR 71140 ("[concepts] ill-formed nested-requirement lacking a semicolon not rejected")

Sorry for the slow reply. I've been stuck working on some other projects. > Can you say a bit about why that was better than continuing to use > VAR_DECL? > I wanted to make sure that we avoid normal VAR_DECL processing routines, so we don't e.g., slip into a function where we might try to

Re: [PATCH, AArch64 v2 06/11] Add visibility to libfunc constructors

> I thought of that, but thought this was slightly clearer from usage. I'm > open the default option if you prefer. No, either is fine as far as I'm concerned. -- Eric Botcazou

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On Wed, Oct 31, 2018 at 04:38:53PM +, Richard Henderson wrote: > On 10/31/18 3:04 PM, Will Deacon wrote: > > The example test above uses relaxed atomics in conjunction with an acquire > > fence, so I don't think we can actually use ST at all without a change > > to the language specification.

Re: [5/6] Preprocessor include

On 10/31/18, Marek Polacek wrote: > On Wed, Oct 31, 2018 at 11:02:16AM -0400, Nathan Sidwell wrote: >> [Yes, I can't count] >> >> Include file handling duplicated cleanup code in each exit path. Simpler >> to >> just commonize it with goto. Also noticed a memory leak in buffer >> popping. >> >>

Re: [PATCH, AArch64 v2 06/11] Add visibility to libfunc constructors

On 10/31/18 5:32 PM, Eric Botcazou wrote: >> * optabs-libfuncs.c (build_libfunc_function_visibility): >> New, split out from... >> (build_libfunc_function): ... here. >> (init_one_libfunc_visibility): New, split out from ... >> (init_one_libfunc): ... here. > > Either

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, 31 Oct 2018, Eric Gallager wrote: > > Index: zlib/Makefile.am > > === > > --- zlib/Makefile.am(revision 265631) > > +++ zlib/Makefile.am(working copy) > > @@ -1,6 +1,6 @@ > > ## Process this file with

Re: [PATCH v2] powerpc: Optimized conversion of IBM long double to int128/int64

On Wed, 31 Oct 2018, Rajalakshmi Srinivasaraghavan wrote: > On 10/25/2018 09:40 PM, Joseph Myers wrote: > > On Thu, 25 Oct 2018, Rajalakshmi Srinivasaraghavan wrote: > > > > > + if (__builtin_unpack_longdouble (a, 0) < TWO53) > > > +{ > > > + /* In this case the integer portion is

Re: std::vector fix & enhancements

Here is the updated patch. I forgot that pre-C+11 we already had the default copy constructor and assignment operators. And with the trick on definition of _M_start the patch is much smaller.     * include/bits/stl_bvector.h     [_GLIBCXX_INLINE_VERSION](_Bvector_impl_data::_M_start): Define

Re: Fix D compilation on Solaris

On Wed, 31 Oct 2018 at 10:43, Rainer Orth wrote: > > Hi Iain, > > >> My first suspect here would be 'struct UnionExp', see d/dmd/expression.h > >> > >> Upstream dmd use a poor man's alignment, from what I recall to be > >> compatible with the dmc compiler. > >> > >> // Ensure that the

[C++ PATCH] missed testcase

I missed committing this testcase with the recent unsorted overload change. nathan -- Nathan Sidwell 2018-10-31 Nathan Sidwell * g++.dg/lookup/friend21.C: New. Index: testsuite/g++.dg/lookup/friend21.C === ---

Re: [PATCH, AArch64 v2 06/11] Add visibility to libfunc constructors

> * optabs-libfuncs.c (build_libfunc_function_visibility): > New, split out from... > (build_libfunc_function): ... here. > (init_one_libfunc_visibility): New, split out from ... > (init_one_libfunc): ... here. Either that or add the parameter with a

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, 31 Oct 2018, Simon Marchi wrote: > On 2018-10-30 11:26 p.m., Joseph Myers wrote: > > This patch (diffs to generated files omitted below) updates GCC to use > > autoconf 2.69 and automake 1.15.1. (That's not the latest automake > > version, but it's the one used by binutils-gdb, with

[PATCH] command line macros

The processing of command line macros is a little confusing. In the same way we force builtin locations, we should force command line locations. We also call the main-starting debug hook on two separate paths. I found it clearer to call it once, and then restart the non-preprocessed

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On 10/31/18 3:04 PM, Will Deacon wrote: > The example test above uses relaxed atomics in conjunction with an acquire > fence, so I don't think we can actually use ST at all without a change > to the language specification. I previouslyyallocated P0861 for this purpose > but never got a chance to

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, 31 Oct 2018, Thomas Koenig wrote: > Am 31.10.18 um 04:26 schrieb Joseph Myers: > > This patch (diffs to generated files omitted below) updates GCC to use > > autoconf 2.69 and automake 1.15.1. > > I think this should fix PR 82856. Maybe you could confirm that this > restores automake

Re: Fix D compilation on Solaris

On Wed, 31 Oct 2018 at 10:40, Rainer Orth wrote: > > Hi Iain, > > > My first suspect here would be 'struct UnionExp', see d/dmd/expression.h > > > > Upstream dmd use a poor man's alignment, from what I recall to be > > compatible with the dmc compiler. > > > > // Ensure that the union is

[PATCH] Come up with htab_hash_string_vptr and use string-specific if possible.

Hi. As seen in r265663 having htab_hash_string accepting const char * would report a compilation error. The void * argument is needed for old C-style htab used in libiberty. I'm suggesting to come up with htab_hash_string_vptr and change signature of the old one (htab_hash_string). And putting

Re: Update GCC to autoconf 2.69, automake 1.15.1

On 10/30/18, Joseph Myers wrote: > This patch (diffs to generated files omitted below) updates GCC to use > autoconf 2.69 and automake 1.15.1. (That's not the latest automake > version, but it's the one used by binutils-gdb, with which consistency > is desirable, and in any case seems a useful

[PING #3] [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html On 10/08/2018 03:40 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html On 10/01/2018 03:30 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html We have

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

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html On 10/20/2018 06:01 PM, Martin Sebor wrote: On 10/16/2018 03:21 PM, Jeff Law wrote: On 10/4/18 9:51 AM, Martin Sebor wrote: On 10/04/2018 08:58 AM, Jeff Law wrote: On 8/27/18 9:42 AM, Richard Biener wrote: On Mon, Aug 27, 2018

Re: [PATCH v2] powerpc: Optimized conversion of IBM long double to int128/int64

On 10/25/2018 09:40 PM, Joseph Myers wrote: On Thu, 25 Oct 2018, Rajalakshmi Srinivasaraghavan wrote: + if (__builtin_unpack_longdouble (a, 0) < TWO53) +{ + /* In this case the integer portion is completely contained + within the high double. So use the hardware convert

Re: [5/6] Preprocessor include

On Wed, Oct 31, 2018 at 12:24:44PM -0400, Nathan Sidwell wrote: > On 10/31/18 11:44 AM, Marek Polacek wrote: > > > > + else if (to_free) > > > +free ((void *)to_free); > > > > free (NULL) is ok so do you really need the check? > > Probably not :) IIRC the if (X) free (X) idiom was nearby,

Re: [PATCH] add simple attribute introspection

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html With the C++ bits approved I'm still looking for a review/approval of the remaining changes: the C front end and the shared c-family handling of the new built-in. On 10/23/2018 04:08 PM, Martin Sebor wrote: On 10/22/2018 04:08 PM,

Re: [5/6] Preprocessor include

On 10/31/18 11:44 AM, Marek Polacek wrote: + else if (to_free) +free ((void *)to_free); free (NULL) is ok so do you really need the check? Probably not :) IIRC the if (X) free (X) idiom was nearby, and I didn't feel like rocking that boat. nathan -- Nathan Sidwell

Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01481.html There was quite a bit of discussion between Joseph and me about the Glibc changes needed to take advantage of the solution but the GCC patch itself (above) still needs reviewing/approval. Other than some (minor) changes to the C++

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

Ping. The latest patch is here: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01551.html On 10/24/2018 08:02 PM, Martin Sebor wrote: On 10/16/2018 04:35 PM, Jeff Law wrote: On 10/8/18 5:22 PM, Martin Sebor wrote: Attached is an updated patch with the INTEGRAL_TYPE_P test added to detect

Re: [PATCH] Avoid useless lookup_external_ref calls with LTO

> > Honza reports high CPU usage from lookup_external_ref at LTRANS time. > This is likely because build_abbrev_table calls it on all DIEs > rather than just type DIEs which we populate the ref table with. > So we end up calling it for all the DIEs refering to early debug, > possibly many

Re: [5/6] Preprocessor include

On Wed, Oct 31, 2018 at 11:02:16AM -0400, Nathan Sidwell wrote: > [Yes, I can't count] > > Include file handling duplicated cleanup code in each exit path. Simpler to > just commonize it with goto. Also noticed a memory leak in buffer popping. > > Applying to trunk. > > -- > Nathan Sidwell

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

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 inline () is sth similar to always_inline for functions, > that is, even though an

[PATCH] Fix typo in try_peel_loop

I observed the odd looking code while looking into something else and confirmed prior behavior (before r248863) was to sum the counts of the non-latch predecessors of the loop (in order to scale the loop such that it no longer appears to iterate). Bootstrap/regtest on powerpc64le with no

[6/6] Preprocessor forced macro location

There's an API for forcing all macro definition token positions to be X. That takes a pointer to X, so one can distinguish between not forcing a location, and forcing the location to be UNKNOWN_LOCATION. However, we only use this to force BUILTINS_LOCATION, and if you're forcing

Re: [PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

On 31/10/2018 14:10, co...@sdf.org wrote: > + > +# Currently there is a bug somewhere in GCC's alias analysis > +# or scheduling code that is breaking _fpmul_parts in fp-bit.c. > +# Disabling function inlining is a workaround for this problem. > +HOST_LIBGCC2_CFLAGS += -fno-inline This needs to

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

Hi Richard, On Wed, Oct 31, 2018 at 10:27:59AM +, Richard Henderson wrote: > On 10/30/18 8:32 PM, James Greenhalgh wrote: > > On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote: > >> When the result of an operation is not used, we can ignore the > >> result by storing to XZR.

[5/6] Preprocessor include

[Yes, I can't count] Include file handling duplicated cleanup code in each exit path. Simpler to just commonize it with goto. Also noticed a memory leak in buffer popping. Applying to trunk. -- Nathan Sidwell 2018-10-31 Nathan Sidwell * directives.c (do_include_common): Commonize

[4/7] Preprocessor location-kind predicates

This fills out the set of location-kind predicates, and uses them in a couple more places. There may well be other places that could benefit. Applying to trunk. -- Nathan Sidwell 2018-10-31 Nathan Sidwell * include/line-map.h (IS_ORDINARY_LOC, IS_MACRO_LOC): New predicates.

[3/7] Preprocessor macro loc

Now that the cpp_macro structure is properly part of cpplib.h, we don't need to outline its location accessor function. Made inline thusly. Cleaned up duplicate macro checking a bit too. applying to trunk nathan -- Nathan Sidwell 2018-10-31 Nathan Sidwell * include/cpplib.h

[2/7] Preprocessor node access

The hashnode identifier accessor macro unnecessarily casts its operand, and the derived accessors don't use it. Fixed thusly. applying to trunk. -- Nathan Sidwell 2018-10-31 Nathan Sidwell * include/cpplib.h (HT_NODE): Don't cast NODE. (NODE_LEN, NODE_NAME): Use HT_NODE. Index:

[1/7] Preprocessor cleanup

This is patch 1 of 7 from the modules branch, cleaning up random preprocessor stuff I fell over. The directive table has some historical frequency data, which was relevant when we used to have to do a lookup for the directives. Now the data hangs directly off the identifier node. A minor

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 10/30/18 4:35 PM, Stafford Horne wrote: > On Tue, Oct 30, 2018 at 10:49:53AM -0500, Segher Boessenkool wrote: >> On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote: >>> Hello, >>> >>> On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote: Yes, like that. It also

Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count

On 10/31/18 12:30 AM, bin.cheng wrote: > Hi, > In new profile probability/count infra, we have different precision quality > categories, > and probabilities/counts of different categories are not supposed to be > compared or > calculated. Though in general is an improvement, it introduces

Re: LTO partitioning performance & increase default number of partitions

On 10/30/18 10:46 PM, Jan Hubicka wrote: > Hi, > this patch increases lto-partitions to 128. This makes ltrans.o file sizes to > grow from 458MB to 651MB which is still not perfect but a lot better than > prevoiusly. On firefox the growth is smaller (only about 10%) which is > probably caused by

[PATCH] Fix PR87776

The following fixes a thinko in the rpo-vn-max-loop-depth param handling. Bootstrapped and tested on x86_64-unknown-linux-gnu. Richard. >From 172251b9fdd1ace4c18fb9308be3f4f3ed868241 Mon Sep 17 00:00:00 2001 From: Richard Guenther Date: Wed, 31 Oct 2018 13:33:21 +0100 Subject: [PATCH]

[PATCH v2] bring netbsd/arm support up to speed. eabi, etc.

Thanks for the feedback. I made some improvements. Changes from the first patch: config.gcc: need_64bit_hwint=yes No longer needed resolve conflict from strongarm being default for netbsd. switch default cpu for armv7--netbsdelf-eabi: cortex-a8 -> generic-armv7-a, (make -mfpu=auto pick VFPv3-D16)

Re: Update GCC to autoconf 2.69, automake 1.15.1

On 2018-10-30 11:26 p.m., Joseph Myers wrote: > This patch (diffs to generated files omitted below) updates GCC to use > autoconf 2.69 and automake 1.15.1. (That's not the latest automake > version, but it's the one used by binutils-gdb, with which consistency > is desirable, and in any case

[wwwdocs] Document PR 87822 ABI breakage of std::pair in GCC 6.5

I'm committing this addition to the release notes as part of my public shaming. Index: htdocs/gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.110 retrieving revision 1.111 diff -u

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Tue, Oct 30, 2018 at 8:26 PM, Joseph Myers wrote: > > This patch (diffs to generated files omitted below) updates GCC to use > autoconf 2.69 and automake 1.15.1. (That's not the latest automake > version, but it's the one used by binutils-gdb, with which consistency > is desirable, and in any

[PATCH] Avoid useless lookup_external_ref calls with LTO

Honza reports high CPU usage from lookup_external_ref at LTRANS time. This is likely because build_abbrev_table calls it on all DIEs rather than just type DIEs which we populate the ref table with. So we end up calling it for all the DIEs refering to early debug, possibly many distinct ones with

Re: [PATCH] PR libstdc++/87822 fix layout change for nested std::pair

On 31/10/18 12:31 +, Jonathan Wakely wrote: The introduction of the empty __pair_base base class for PR 86751 changed the layout of std::pair, ...>. The outer pair and its first member both have a base class of the same type, which cannot exist at the same address. This causes the first

[C++ PATCH] Simplify overloads

When I redid namespace-scope name lookup I made overload sets ordered hidden, then using, then other. This was with an eye to how modules would need to extend that to add 'exported' on the end. Turns out that's not needed, so we can simplify a bit. This patch changes things so that using

[PATCH] PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751 changed the layout of std::pair, ...>. The outer pair and its first member both have a base class of the same type, which cannot exist at the same address. This causes the first member to be at a non-zero offset. The solution is

Re: [PATCH] Fix PRs70359/86270

On Tue, 30 Oct 2018, Richard Biener wrote: > > This picks up work from earlier this year where Aldy worked on > undoing forwprop during out-of-SSA to improve coalescing across > backedges. > > The following patch first rectifies the existing code which > is meant to insert necessary copies in

Re: [PATCH 6/6] [ARC] Handle store cacheline hazard.

Committed with feedback in. Thank you, Claudiu

Re: [PATCH 2/6] [ARC] Cleanup TLS implementation.

Committed with your feedback in. Thank you, Claudiu

Re: [PATCH 3/6] [ARC] Add BI/BIH instruction support.

Committed with your feedback in. Thank you, Claudiu

Re: [PATCH 1/6] [ARC] Remove non standard funcions calls.

Thank you for your review. Patch pushed, Claudiu

Re: [PATCH 3/6] [ARC] Add BI/BIH instruction support.

Thank you all for your review. The patch is pushed with your input in. //Claudiu

Re: [PATCH 0/7] libsanitizer: merge from trunk

On Wed, Oct 31, 2018 at 12:24:47PM +0100, Martin Liška wrote: > I install the patch set. If I'm correct one last missing piece should > be update of LOCAL_PATCHES. I'm sending patch for it. Ok, thanks. Jakub

Re: [PATCH 0/7] libsanitizer: merge from trunk

Hi. I install the patch set. If I'm correct one last missing piece should be update of LOCAL_PATCHES. I'm sending patch for it. Ready for trunk? Thanks, Martin >From 02134e26743eed447f62f7e22d75ddfe605e88e3 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 31 Oct 2018 12:22:36 +0100 Subject:

[PR87815]Don't generate shift sequence for load replacement in DSE when the mode size is not compile-time constant

Hi all, The patch adds a check if the gap is compile-time constant. This happens when dse decides to replace the load with previous store value. The problem is that, shift sequence could not accept compile-time non-constant mode operand. Another issue raised from this issue is the inefficient

Re: [PATCH 3/7] Update build system: include new files and run autoheader, autoconf, automake

On 10/31/18 11:35 AM, Rainer Orth wrote: > Hi Martin, > >> libsanitizer/ChangeLog: >> >> 2018-10-24 Martin Liska >> >> * config.h.in: Regenerate. >> * configure: Likewise. >> * sanitizer_common/Makefile.am: Include new files, remove old >> files. >> *

Re: [PATCH 3/7] Update build system: include new files and run autoheader, autoconf, automake

Hi Martin, > libsanitizer/ChangeLog: > > 2018-10-24 Martin Liska > > * config.h.in: Regenerate. > * configure: Likewise. > * sanitizer_common/Makefile.am: Include new files, remove old > files. > * sanitizer_common/Makefile.in: Regenerate. I noticed that this

Re: [PATCH, AArch64 v2 06/11] Add visibility to libfunc constructors

Ping for rtl, middle-end, or global reviewers. r~ On 10/2/18 5:19 PM, Richard Henderson wrote: > * optabs-libfuncs.c (build_libfunc_function_visibility): > New, split out from... > (build_libfunc_function): ... here. > (init_one_libfunc_visibility): New, split out from

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On 10/30/18 8:32 PM, James Greenhalgh wrote: > On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote: >> When the result of an operation is not used, we can ignore the >> result by storing to XZR. For two of the memory models, using >> XZR with LD has a preferred assembler alias, ST.

Re: [PATCH] Verify that last argument of __builtin_expect_with_probability is a real cst (PR c/87811).

On Wed, Oct 31, 2018 at 11:04:32AM +0100, Martin Liška wrote: > Hi. > > As Jakub pointed out we should not ICE when last argument > of __builtin_expect_with_probability is not a real cst. > Plus I documented the behavior. That is not what you've implemented. The documentation says that it must

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On 10/30/18 8:32 PM, James Greenhalgh wrote: > On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote: >> When the result of an operation is not used, we can ignore the >> result by storing to XZR. For two of the memory models, using >> XZR with LD has a preferred assembler alias, ST.

[PATCH] Verify that last argument of __builtin_expect_with_probability is a real cst (PR c/87811).

Hi. As Jakub pointed out we should not ICE when last argument of __builtin_expect_with_probability is not a real cst. Plus I documented the behavior. Patch survives regression tests on x86_64-linux-gnu and bootstraps works fine. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-10-30

Re: [PATCH, AArch64 v2 01/11] aarch64: Simplify LSE cas generation

On 10/30/18 7:48 PM, James Greenhalgh wrote: > On Tue, Oct 02, 2018 at 11:19:05AM -0500, Richard Henderson wrote: >> The cas insn is a single insn, and if expanded properly need not >> be split after reload. Use the proper inputs for the insn. > > OK. Thanks. Committed 1-4 & 9. r~

[PATCH][OBVIOUS] Fix hash-table violation in trans-decl.c.

Hello. This is a regression that was introduced in r216127. I tested the patch on ppc64le and I'm going to install it. Martin gcc/fortran/ChangeLog: 2018-10-30 Martin Liska * trans-decl.c (struct module_hasher): Call htab_hash_string for s->name and not for s. ---

Re: [PATCH v2] S/390: Allow LARL of literal pool entries

Ilya Leoshkevich wrote: > Am 30.10.2018 um 18:22 schrieb Ulrich Weigand : > > This definitely looks wrong. If we haven't annotated the address, > > it should *not* be found by find_constant_pool_ref, since we are > > not going to replace it! That was the whole point of not annotating > > it in

Re: hash-table violation in gcc/fortran/trans-decl.c

On 10/31/18 10:40 AM, Trevor Saunders wrote: > On Tue, Oct 30, 2018 at 11:07:16AM +0100, Martin Li??ka wrote: >> On 10/29/18 12:04 PM, Martin Li??ka wrote: >>> 2) gfc_find_module >>> >>> $ ./xgcc -B. >>> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90 >>>

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, Oct 31, 2018 at 4:26 AM Joseph Myers wrote: > > This patch (diffs to generated files omitted below) updates GCC to use > autoconf 2.69 and automake 1.15.1. (That's not the latest automake > version, but it's the one used by binutils-gdb, with which consistency > is desirable, and in any

Re: Update GCC to autoconf 2.69, automake 1.15.1

On Wed, Oct 31, 2018 at 8:12 AM Thomas Koenig wrote: > > Am 31.10.18 um 04:26 schrieb Joseph Myers: > > This patch (diffs to generated files omitted below) updates GCC to use > > autoconf 2.69 and automake 1.15.1. > > I think this should fix PR 82856. Maybe you could confirm that this > restores

Re: Fix D compilation on Solaris

Hi Iain, >> My first suspect here would be 'struct UnionExp', see d/dmd/expression.h >> >> Upstream dmd use a poor man's alignment, from what I recall to be >> compatible with the dmc compiler. >> >> // Ensure that the union is suitably aligned. >> real_t for_alignment_only; >> >>

Re: Fix D compilation on Solaris

Hi Iain, > My first suspect here would be 'struct UnionExp', see d/dmd/expression.h > > Upstream dmd use a poor man's alignment, from what I recall to be > compatible with the dmc compiler. > > // Ensure that the union is suitably aligned. > real_t for_alignment_only; > > What

Re: hash-table violation in gcc/fortran/trans-decl.c

On Tue, Oct 30, 2018 at 11:07:16AM +0100, Martin Li??ka wrote: > On 10/29/18 12:04 PM, Martin Li??ka wrote: > > 2) gfc_find_module > > > > $ ./xgcc -B. > > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90 > > -fcoarray=single -fchecking=3 > > hash table checking

Re: [PATCH AutoFDO/2]Treat ZERO as common profile probability/count

On Wed, Oct 31, 2018 at 5:11 PM Richard Biener wrote: > > On Wed, Oct 31, 2018 at 7:30 AM bin.cheng wrote: > > > > Hi, > > In new profile probability/count infra, we have different precision quality > > categories, > > and probabilities/counts of different categories are not supposed to be > >

Re: [PATCH, d] Disable D on systems where it is known not to work.

On Tue, Oct 30, 2018 at 8:25 PM Iain Buclaw wrote: > > Hi, > > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed

  1   2   >