Re: [PATCH 13/25] Create TARGET_DISABLE_CURRENT_VECTOR_SIZE

On Fri, Sep 28, 2018 at 2:47 PM Andrew Stubbs wrote: > > On 19/09/18 14:45, Richard Biener wrote: > > So I guess the current_vector_size thing isn't too hard to get rid of, what > > you'd end up with would be using that size when you decide for vector > > types for loads (where there are no USEs w

Re: [PATCH][IRA,LRA] Fix PR87466, all pseudos live across setjmp are spilled

On Sat, Sep 29, 2018 at 5:12 AM Peter Bergner wrote: > > Currently, both IRA and LRA spill all pseudo regs that are live across a > setjmp call. If the target has a sane setjmp, then the compiler should not > have to treat the setjmp call any differently than is does any other normal > function c

Re: [patch] Fix PR tree-optimization/86659

On Fri, Sep 28, 2018 at 7:01 PM Eric Botcazou wrote: > > Hi, > > this is a regression introduced by the canonicalization of BIT_FIELD_REF in > match.pd, which totally disregards the REF_REVERSE_STORAGE_ORDER flag, and > visible as the failure of gnat.dg/sso/q[23].adb on SPARC 64-bit. But the > un

Re: No a*x+b*x factorization for signed vectors

On Sat, Sep 29, 2018 at 1:06 PM Marc Glisse wrote: > > Hello, > > this is a simple patch to remove the wrong-code part of PR 87319. I didn't > spend much time polishing that code, since it is meant to disappear > anyway. > > We could probably remove the inner == inner2 test in > signed_or_unsigned

Re: ((X /[ex] A) +- B) * A --> X +- A * B

On Sat, Sep 29, 2018 at 1:35 PM Marc Glisse wrote: > > Hello, > > I noticed quite ugly code from both testcases. This transformation does > not fix either, but it helps a bit. I'm curious why you chose to restrict to INTEGER_CST A and B? Is that because of the case when (X / [ex] A) +- B evaluate

Re: Fold more boolean expressions

On Sun, Sep 30, 2018 at 5:11 PM MCC CS wrote: > > > Now that it has got enough reviews and there's > been no comments for a week, I believe > now it's time for us to install it on trunk. > The patch is the same as previous, but rebased > on current trunk. > > Could you please push it for me? If th

Re: [PATCH][IRA,LRA] Fix PR87466, all pseudos live across setjmp are spilled

Hi Peter, On Fri, Sep 28, 2018 at 10:12:02PM -0500, Peter Bergner wrote: > Currently, both IRA and LRA spill all pseudo regs that are live across a > setjmp call. If the target has a sane setjmp, then the compiler should not > have to treat the setjmp call any differently than is does any other n

Re: [PATCH][IRA,LRA] Fix PR87466, all pseudos live across setjmp are spilled

> Since all implementations of this hook will have to do the same, I think > it is better if you leave this test at the (only two) callers. The hook > doesn't need an argument then, and maybe is better named something like > setjmp_is_normal_call? (The original code did not test CALL_P btw). Sec

[PATCH] Fix typo, fixing PR87465

The following typo-fix happens to fix a --param max-peel-branches limit caused missed peeling. The typo is present everywhere, the missed peeling is a regression from GCC 7. Bootstrap and regtest running on x86_64-unknown-linux-gnu. I'm not really considering to backport this anywhere. Note t

Re: [PATCH 2/2] [ARC] Avoid specific constants to end in limm field.

Pushed. Thank you for your review, Claudiu On Fri, Sep 21, 2018 at 12:12 AM Andrew Burgess wrote: > > * Claudiu Zissulescu [2018-09-17 15:50:27 +0300]: > > > The 3-operand instructions accepts to place an immediate into the > > second operand. However, this immediate will end up in the long > > i

Re: [PATCH 1/2] [ARC] Check for odd-even register when emitting double mac ops.

Pushed with suggested changes. Thank you for your review, Claudiu On Thu, Sep 20, 2018 at 11:59 PM Andrew Burgess wrote: > > * Claudiu Zissulescu [2018-09-17 15:50:26 +0300]: > > > Avoid generate dmac instructions when the register is not odd-even, > > use instead the equivalent mac instruction.

[c-family] Small fix for -fdump-ada-spec

The translation of a pointer to constant value was lacking the package prefix. Tested on x86_64-suse-linux, applied on the mainline. 2018-10-01 Eric Botcazou * c-ada-spec.c (get_underlying_decl): Get to the main type variant. (dump_ada_node): Add const keyword. -- Eric Botc

Re: RFC: variant and ODR based type merging during LTO streaming

On Fri, 28 Sep 2018, Jan Hubicka wrote: > Hi, > this is a proof-of-concept patch for type merging during LTO streaming. It > does two things > 1) replace type variant by first compatible one in TYPE_NEXT_VARIANT list >This is useful at compilation time because frontends produce more variants >

Re: RFC: variant and ODR based type merging during LTO streaming

> > The ODR savings really look good but as you say the implementation is > somewhat "tricky". > > I'd like to see the type-variant done separately (of course) and > also differently. This is because when enabling > free-lang-data by default we should be able to get benefits for > non-LTO compi

Re: [PATCH][IRA,LRA] Fix PR87466, all pseudos live across setjmp are spilled

On Mon, Oct 01, 2018 at 11:25:21AM +0200, Eric Botcazou wrote: > > Since all implementations of this hook will have to do the same, I think > > it is better if you leave this test at the (only two) callers. The hook > > doesn't need an argument then, and maybe is better named something like > > se

Re: RFC: variant and ODR based type merging during LTO streaming

On Mon, 1 Oct 2018, Jan Hubicka wrote: > > > > The ODR savings really look good but as you say the implementation is > > somewhat "tricky". > > > > I'd like to see the type-variant done separately (of course) and > > also differently. This is because when enabling > > free-lang-data by default

Re: [PATCH] GCOV: introduce --json-format.

On 9/27/18 3:55 PM, David Malcolm wrote: > On Thu, 2018-09-27 at 09:46 +0200, Martin Liška wrote: >> Hi. >> >> For some time we've been providing an intermediate format as >> output of GCOV tool. It's documented in our code that primary >> consumer of it is lcov. Apparently that's not true: >> http

New Russian PO file for 'gcc' (version 8.2.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Russian team of translators. The file is available at: http://translationproject.org/latest/gcc/ru.po (This file, 'gcc-8.2.0.ru.po', has just

Re: RFC: variant and ODR based type merging during LTO streaming

On Mon, 1 Oct 2018, Richard Biener wrote: > On Mon, 1 Oct 2018, Jan Hubicka wrote: > > > > > > > The ODR savings really look good but as you say the implementation is > > > somewhat "tricky". > > > > > > I'd like to see the type-variant done separately (of course) and > > > also differently. T

Re: vector _M_start and 0 offset

On 29/09/18 10:56 +0200, Marc Glisse wrote: Hello, here is a clang-friendly version of the patch (same changelog), tested a while ago. Is it ok or do you prefer something like the + if(this->_M_impl._M_start._M_offset != 0) __builtin_unreachable(); version suggested by François? I don't th

Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On Sun, Sep 30, 2018 at 6:18 PM Peter Bergner wrote: > > On 9/30/18 7:57 PM, H.J. Lu wrote: > > This caused: > > > > FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx > > FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx > > FAIL: gcc.target/i386/pr643

Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On Mon, Oct 1, 2018 at 5:44 AM H.J. Lu wrote: > > On Sun, Sep 30, 2018 at 6:18 PM Peter Bergner wrote: > > > > On 9/30/18 7:57 PM, H.J. Lu wrote: > > > This caused: > > > > > > FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx > > > FAIL: gcc.target/i386/pr63534.c scan-asse

Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On Mon, Oct 1, 2018 at 5:45 AM H.J. Lu wrote: > > On Mon, Oct 1, 2018 at 5:44 AM H.J. Lu wrote: > > > > On Sun, Sep 30, 2018 at 6:18 PM Peter Bergner wrote: > > > > > > On 9/30/18 7:57 PM, H.J. Lu wrote: > > > > This caused: > > > > > > > > FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl

[PATCH][C]/[C++] Remove DECL_FROM_INLINE use

This patch removes checks of DECL_FROM_INLINE from the respective -Wshadow code of the C/C++ FE. I noticed those when looking after DECL_ABSTRACT_ORIGIN uses. Those checks may be from times where we did inlining very early? Bootstrapped and tested on x86_64-unknown-linux-gnu with no regression

Re: RFC: variant and ODR based type merging during LTO streaming

> > I see. So one possible canonicalization is to make _all_ > > pointer-typed FIELD_DECLs point to incomplete variants since the memory > > accesses should already have the "proper" access types. Can you > > get statistics on that? Not sure how to get an "incomplete" type > > though (iff we can

Re: RFC: variant and ODR based type merging during LTO streaming

On Mon, 1 Oct 2018, Jan Hubicka wrote: > > > I see. So one possible canonicalization is to make _all_ > > > pointer-typed FIELD_DECLs point to incomplete variants since the memory > > > accesses should already have the "proper" access types. Can you > > > get statistics on that? Not sure how to

Re: RFC: variant and ODR based type merging during LTO streaming

> On Mon, 1 Oct 2018, Jan Hubicka wrote: > > > > > I see. So one possible canonicalization is to make _all_ > > > > pointer-typed FIELD_DECLs point to incomplete variants since the memory > > > > accesses should already have the "proper" access types. Can you > > > > get statistics on that? Not

Re: [PATCH, AArch64 10/11] aarch64: Implement TImode compare-and-swap

Hi Richard, On 26/09/18 06:03, rth7...@gmail.com wrote: From: Richard Henderson This pattern will only be used with the __sync functions, because we do not yet have a bare TImode atomic load. Does this mean that the libatomic `defined(atomic_compare_exchange_n)` checks would return false fo

Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On 10/1/18 7:50 AM, H.J. Lu wrote: > On Mon, Oct 1, 2018 at 5:45 AM H.J. Lu wrote: >> You may have undone: >> >> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218059 >> > > I opened: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87479 Thanks for checking. I'll have a look. Peter

Re: [PATCH] libgo: Don't assume sys.GoarchAmd64 == 64-bit pointer

"H.J. Lu" writes: > On Sat, Sep 29, 2018 at 9:01 PM Ian Lance Taylor wrote: >> >> "H.J. Lu" writes: >> >> > On x86-64, sys.GoarchAmd64 == 1 for -mx32. But -mx32 has 32-bit >> > pointer, not 64-bit. There is >> > >> > // _64bit = 1 on 64-bit systems, 0 on 32-bit systems >> > _64bit = 1 << (^ui

Re: [PATCH] dumpfile.c: use prefixes other that 'note: ' for MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}

On Sun, 2018-09-30 at 00:12 +0200, Andreas Schwab wrote: > That produces extra output that breaks a few tests. > > g++.dg/vect/pr33426-ivdep-2.cc -std=c++11 (test for excess errors) > g++.dg/vect/pr33426-ivdep-2.cc -std=c++14 (test for excess errors) > g++.dg/vect/pr33426-ivdep-2.cc -std=c++98

Re: [PATCH] dumpfile.c: use prefixes other that 'note: ' for MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}

On Okt 01 2018, David Malcolm wrote: > Is there a link to the .log files somewhere so I can see the precise > messages in question? (e.g. are they all "loop versioned for > vectorization to enhance alignment"?). Yes, they are all the same message. Andreas. -- Andreas Schwab, sch...@linux-m68

Re: [libstdc++,doc] adjust link to www.oracle.com

On 30/09/18 16:06 +0200, Gerald Pfeifer wrote: I applied the patch below. Given a number of fixes in libstdc++/doc I've applied recently, can one of you please regenerate the HTML pages in the next days? Done and committed as r264760. Regenerate libstdc++ HTML pages * doc/ht

RFC: x87 reduc_plus_scal_* AVX (and AVX512?) expanders

I notice that for Zen we create 0.00 │ vhaddp %ymm3,%ymm3,%ymm3 1.41 │ vperm2 $0x1,%ymm3,%ymm3,%ymm1 1.45 │ vaddpd %ymm1,%ymm2,%ymm2 from reduc_plus_scal_v4df which uses a cross-lane permute vperm2f128 even though the upper half of the result is unused in the end (we only

Re: ((X /[ex] A) +- B) * A --> X +- A * B

On Mon, 1 Oct 2018, Richard Biener wrote: On Sat, Sep 29, 2018 at 1:35 PM Marc Glisse wrote: Hello, I noticed quite ugly code from both testcases. This transformation does not fix either, but it helps a bit. I'm curious why you chose to restrict to INTEGER_CST A and B? Is that because of t

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

Hi, Martin, I have studied a little more on https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md in the Section “Usages”, from the example, we can see: the tool will report a list of affected functions for a

Re: [PATCH][C]/[C++] Remove DECL_FROM_INLINE use

On Mon, 1 Oct 2018, Richard Biener wrote: > This patch removes checks of DECL_FROM_INLINE from the respective > -Wshadow code of the C/C++ FE. I noticed those when looking after > DECL_ABSTRACT_ORIGIN uses. Those checks may be from times where > we did inlining very early? > > Bootstrapped and

[libiberty] Use pipe inside pex_run

Ian, this patch implements the pipe error channel you suggested a while back. Before the (v)fork we create a pipe and set it up for CLOEXEC. If exec failure happens in the child, we write errno & the fnname to the pipe. In the parent we attempt to read the pipe. We'll get EOF if the child

Re: [libiberty] Use pipe inside pex_run

On Mon, Oct 1, 2018 at 10:53 AM, Nathan Sidwell wrote: > Ian, > this patch implements the pipe error channel you suggested a while back. > Before the (v)fork we create a pipe and set it up for CLOEXEC. If exec > failure happens in the child, we write errno & the fnname to the pipe. In > the pare

[libstdc++,doc] adjust a link in doc/xml/manual/allocator.xml

This just moved from http to https, and they put a redirect in place, so pretty straightforward. Applied. 2018-10-01 Gerald Pfeifer * doc/xml/manual/allocator.xml: Adjust link to "Reconsidering Custom Memory Allocation". Index: doc/xml/manual/allocator.xml ===

Re: [PATCH][C]/[C++] Remove DECL_FROM_INLINE use

OK. On Mon, Oct 1, 2018 at 1:14 PM Joseph Myers wrote: > > On Mon, 1 Oct 2018, Richard Biener wrote: > > > This patch removes checks of DECL_FROM_INLINE from the respective > > -Wshadow code of the C/C++ FE. I noticed those when looking after > > DECL_ABSTRACT_ORIGIN uses. Those checks may be fr

Re: Fix pretty printers in _GLIBCXX_DEBUG mode

On 09/28/2018 02:01 PM, Jonathan Wakely wrote: On 25/09/18 22:11 +0200, François Dumont wrote: I guess it must have something to do with the [] but as I escaped both I don't understand what's wrong. You might need to escape them twice, or more ... so that TCL doesn't try to handle them as sp

Re: libgo patch committed: Update to 1.11 release

On Wed, Sep 26, 2018 at 3:54 AM, Andreas Schwab wrote: > All execution tests are now failing with "fatal error: impossible call > to aeshashbody". Thanks. Fixed by this patch, which adds AES hash code for arm64 using intrinsics. Bootstrapped and tested on x86_64-pc-linux-gnu and aarch4-unknown-

Re: libgo patch committed: Update to 1.11 release

On Wed, Sep 26, 2018 at 7:50 AM, H.J. Lu wrote: > On Mon, Sep 24, 2018 at 2:46 PM, Ian Lance Taylor wrote: >> I've committed a patch to update libgo to the 1.11 release. As usual >> for these updates, the patch is too large to attach to this e-mail >> message. I've attached some of the more rel

Re: libgo patch committed: Update to 1.11 release

On Mon, Oct 1, 2018 at 1:18 PM, Ian Lance Taylor wrote: > On Wed, Sep 26, 2018 at 7:50 AM, H.J. Lu wrote: >> On Mon, Sep 24, 2018 at 2:46 PM, Ian Lance Taylor wrote: >>> I've committed a patch to update libgo to the 1.11 release. As usual >>> for these updates, the patch is too large to attach

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

PR 81824 is a request to detect and diagnose alias declarations with less restrictive attributes than those of their targets. I promised I'd implement this for GCC 9 so with the end of stage 1 approaching I figured it was about time to post my attempt at this enhancement. I expect it to need twea

[PATCH] libstdc++: Remove unused define

__NO_STRING_INLINES was removed from uClibc around 2004 so has no effect. Ok for trunk? libstdc++-v3/ChangeLog: 2018-10-01 Bernhard Reutner-Fischer * config/os/uclibc/os_defines.h (__NO_STRING_INLINES): Delete. --- libstdc++-v3/config/os/uclibc/os_defines.h | 3 --- 1 file changed,

[PING] [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 09/21/2018 11:13 AM, Martin Sebor wrote: On 09/17/2018 07:30 PM, Jeff Law wrote: On 8/28/18 6:12 PM, Martin Sebor wrote: Sadly, dstbase is the PARM_DECL for d. That's where things are going "wrong". Not sure why you're getting

[PING] [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 We have discussed a number of different approaches to moving the warning somewhere else but none is feasible in the limited amount of time remaining in stage 1 of GCC 9. I'd like to avoid the false positive in GCC 9 by using the orig

Re: [committed] Use structure to bubble up information about unterminated strings from c_strlen

On Sat, 29 Sep 2018 at 18:06, Jeff Law wrote: > > > This patch changes the NONSTR argument to c_strlen to instead be a > little data structure c_strlen can populate with nuggets of information > about the string. > > There's clearly a need for the decl related to the non-string argument. > I see a

Re: [PATCH 6/6] detect unterminated const arrays in strnlen calls (PR 86552)

On 8/13/18 3:29 PM, Martin Sebor wrote: > The attached changes implement the detection of past-the-end reads > by strncpy due to unterminated arguments and excessive bounds. > > > gcc-86552-6.diff > > PR tree-optimization/86552 - missing warning for reading past the end of > non-string arrays >

Re: [committed] Use structure to bubble up information about unterminated strings from c_strlen

On 10/1/18 3:46 PM, Christophe Lyon wrote: > On Sat, 29 Sep 2018 at 18:06, Jeff Law wrote: >> >> >> This patch changes the NONSTR argument to c_strlen to instead be a >> little data structure c_strlen can populate with nuggets of information >> about the string. >> >> There's clearly a need for th

Go patch committed: Use underlying type to build placeholder type for aliases

This patch to the Go frontend by Cherry Zhang uses the underlying type to build the placeholder type for aliases. When asking for a placeholder type of an alias type, this builds a placeholder for the underlying type, instead of treating the alias as a named type and calling get_backend. The latt

C++ PATCH to implement C++20 P0892R2 - explicit(bool)

This patch implements C++20 explicit(bool), as described in: . I tried to follow the noexcept specifier implementation where I could, which made the non-template parts of this fairly easy. To make explicit(expr) work with depen

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

On Mon, 1 Oct 2018, Martin Sebor wrote: > Testing the patch with Glibc triggers thousands of warnings of > both kinds. After reviewing a small subset it became apparent Thousands of warnings suggests initially having the warning outside -Wall (though one might hope to move it into -Wall at some

Re: C++ PATCH to implement C++20 P0892R2 - explicit(bool)

On Mon, Oct 1, 2018 at 6:41 PM Marek Polacek wrote: > > This patch implements C++20 explicit(bool), as described in: > . > > I tried to follow the noexcept specifier implementation where I could, which > made the non-template pa

Re: libgo patch committed: Update to 1.11 release

On Mon, Oct 1, 2018 at 1:27 PM, H.J. Lu wrote: > On Mon, Oct 1, 2018 at 1:18 PM, Ian Lance Taylor wrote: >> On Wed, Sep 26, 2018 at 7:50 AM, H.J. Lu wrote: >>> On Mon, Sep 24, 2018 at 2:46 PM, Ian Lance Taylor wrote: I've committed a patch to update libgo to the 1.11 release. As usual >>>

Re: libgo patch committed: Update to 1.11 release

On Mon, Oct 1, 2018 at 4:56 PM, H.J. Lu wrote: > > Compared with my patch, there are some new failures: Thanks. We probably need a patch in gcc/testsuite/go.test/go-test.exp to set goarch to amd64p32 when appropriate. Other than that there seems to be some sort of signal handling problem. Hard

Use -fno-show-column in libstdc++ installed testing

arranged for libstdc++ tests to use -fno-show-column by default, but only for build-tree testing. This patch adds it to the options used for installed testing as well. Tested with installed testing for a cross to x86_64-linux-gnu, where it

Re: libgo patch committed: Update to 1.11 release

On Mon, Oct 1, 2018 at 5:06 PM Ian Lance Taylor wrote: > > On Mon, Oct 1, 2018 at 4:56 PM, H.J. Lu wrote: > > > > Compared with my patch, there are some new failures: > > Thanks. We probably need a patch in gcc/testsuite/go.test/go-test.exp > to set goarch to amd64p32 when appropriate. > > Other

Re: [PATCH][2/n] Make _INLINE_ENTRY markers have the location we finally need

On Sep 28, 2018, Richard Biener wrote: > Alex - any particular reason for not doing this? The only concern that comes to mind is a vague thought about this possibly messing up the nesting of lexical scopes in executable code, but I don't think that's a given to begin with, I like this move, and

Re: [PATCH 0/2][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

On 10/1/18 7:45 AM, H.J. Lu wrote: > You may have undone: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218059 Yes, the code above also needed to be modified to handle conflicts being added at definitions rather than at uses. The patch below does that. I don't really have access to

Re: libgo patch committed: Update to 1.11 release

On Mon, Oct 1, 2018 at 6:57 PM, H.J. Lu wrote: > On Mon, Oct 1, 2018 at 5:06 PM Ian Lance Taylor wrote: >> >> On Mon, Oct 1, 2018 at 4:56 PM, H.J. Lu wrote: >> > >> > Compared with my patch, there are some new failures: >> >> Thanks. We probably need a patch in gcc/testsuite/go.test/go-test.exp

[PATCH][rs6000][PR target/87474] fix strncmp expansion with -mno-power8-vector

PR/87474 happens because I didn't check that both vector and VSX instructions were enabled, so insns that are disabled get generated with -mno-power8-vector. Regstrap passes on ppc64le, ok for trunk? Thanks! Aaron 2018-10-01 Aaron Sawdey PR target/87474 * config/rs6000/rs