RE: [PATCH 1/5] [ARC] Update sleep builtin.

Committed. Thank you for your review, Claudiu From: Andrew Burgess [andrew.burg...@embecosm.com] Sent: Wednesday, April 18, 2018 7:51 PM To: Claudiu Zissulescu Cc: gcc-patches@gcc.gnu.org; francois.bed...@synopsys.com Subject: Re: [PATCH 1/5] [ARC] Update

[PATCH, lto, PR85422] Fixup loops before lto write-out

[ was: Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955 ] On 04/16/2018 08:13 PM, Tom de Vries wrote: On 04/12/2018 08:58 PM, Jakub Jelinek wrote: On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote: Strange. I didn't observe any regressions when I tested it. But,

RE: [PATCH] x86/cet: Use unsigned integer to unwind shadow stack

> -Original Message- > From: Lu, Hongjiu > Sent: Monday, April 23, 2018 1:56 PM > To: gccpat...@intel.com > Cc: Tsimbalist, Igor V ; Uros Bizjak > > Subject: [PATCH] x86/cet: Use unsigned integer to unwind shadow stack > > Use unsigned

RE: [PATCH 2/5] [ARC] Fix FLS, SETI patterns.

Committed. Thank you for your review, Claudiu From: Andrew Burgess [andrew.burg...@embecosm.com] Sent: Wednesday, April 18, 2018 7:57 PM To: Claudiu Zissulescu Cc: gcc-patches@gcc.gnu.org; francois.bed...@synopsys.com Subject: Re: [PATCH 2/5] [ARC] Fix FLS,

Re: [patch] Fix PR middle-end/85496

On Mon, Apr 23, 2018 at 1:24 PM, Eric Botcazou wrote: > Hi, > > this is a regression present on all the active branches for targets that > return values in registers using PARALLELs, when optimization is enabled. > store_field changes the mode of a temporary to ensure that

Re: [PATCH, lto, PR85422] Fixup loops before lto write-out

On Mon, 23 Apr 2018, Tom de Vries wrote: > [ was: Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955 ] > > On 04/16/2018 08:13 PM, Tom de Vries wrote: > > On 04/12/2018 08:58 PM, Jakub Jelinek wrote: > > > On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote: > > > >

[og7, nvptx, PR85486, committed] Force vl32 if calling vector-partitionable routines

Hi, we've recently added the new feature allowing vector length larger than 32. But when we compile a test-case like this: ... #pragma acc routine vector void __attribute__((noinline, noclone)) Vector (int *ptr, int n, const int inc) { #pragma acc loop vector for (unsigned ix = 0; ix < n;

[patch] Fix PR middle-end/85496

Hi, this is a regression present on all the active branches for targets that return values in registers using PARALLELs, when optimization is enabled. store_field changes the mode of a temporary to ensure that it can be used to create a register, leading to a mode mismatch downstream, but

[PATCH] x86/cet: Use unsigned integer to unwind shadow stack

Use unsigned integer to unwind shadow stack by replacing jle with jbe and jg with ja. OK for trunk? H.J. --- PR target/85489 * config/x86/sjlj.S (GTM_longjmp): Replace jle/jg with jbe/ja. --- libitm/config/x86/sjlj.S | 8 1 file changed, 4 insertions(+), 4 deletions(-)

[PATCH] Fix vect_get_peeling_costs_all_drs to not record spurious final costs

The following avoids calling vect_get_load_cost with a NULL prologue_cost_vec because that, when calling record_stmt_cost with a NULL vector, will cause final prologue costs to be registered (redundantly). This only affects powerpc because that is the only target with realign-load[-optimized]

Re: Fix PR 85423 (Re: Fix PRs 80463, 83972, 83480)

On Mon, 23 Apr 2018, Andrey Belevantsev wrote: > Hello, > > So this PR shows that I have incorrectly mirrored the conditional from > sched-deps.c that creates the dependence from a debug insn on the previous > insn (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463#c3 for the > hunk). Thus

Fix PR 85423 (Re: Fix PRs 80463, 83972, 83480)

Hello, So this PR shows that I have incorrectly mirrored the conditional from sched-deps.c that creates the dependence from a debug insn on the previous insn (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463#c3 for the hunk). Thus we have incorrectly discarded some legitimate debug-debug

[PATCH] Update nvptx newlib installation requirements

The nvptx port has been merged into newlib, so the Mentor Embedded github repository is no longer needed. While we're still maintaining the github mirror, given the stability of the nvptx port, going forward I expect all of the development to occur in the upstream newlib repository directly. This

Re: [PATCH] rs6000 PR83660 fix ICE with vec_extract

This also affects gcc 7 and is fixed by the same patch. I've tested the backport to 7 on ppc64le and it causes no new fails. OK for backport to 7 (and 6 if it's also needed there)? Thanks, Aaron On Fri, 2018-04-13 at 15:37 -0500, Aaron Sawdey wrote: > Per the discussion on the 83660, I've

Re: [PATCH] rs6000 PR83660 fix ICE with vec_extract

On Mon, Apr 23, 2018 at 11:36:20AM -0500, Aaron Sawdey wrote: > This also affects gcc 7 and is fixed by the same patch. I've tested the > backport to 7 on ppc64le and it causes no new fails. OK for backport to > 7 (and 6 if it's also needed there)? Yes please (for both). Thanks! Segher > On

Re: Fix PR 85423 (Re: Fix PRs 80463, 83972, 83480)

On Mon, Apr 23, 2018 at 05:03:09PM +0300, Andrey Belevantsev wrote: > I have put the test in gcc.dg though it requires -march=nano. Do you want > me to create an extra machine-dependent test? If it is a compile time test, no need for that. Just add /* { dg-additional-options "-march=nano" {

[PATCH 0/2] Require that constraints are used to reference global regs

Hello, In discussion of proposed fix for PR 44281 Michael said: [ https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01963.html ] > [...] What I mean to say is, the following is currently proper use of > global reg vars: > > > register uint64_t ugh __asm__("rbx"); //r11, whatever > void

[PATCH 2/2] df-scan: remove ad-hoc handling of global regs in asms

As discussed in the cover letter, the code removed in this patch is unnecessary, references to global reg vars from inline asms do not work reliably, and so we should simply require that inline asms use constraints to make such references properly visible to the compiler. Bootstrapped/regtested

[PATCH 1/2] extend.texi: update Global Register Variables section

This rewrites global register vars doc to reflect that the register is no longer reserved exclusively, but in fact is available for general allocation, and also adds the requirement to properly inform the compiler where inline asms are accessing the variable. This: -@item The register is not

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Mon, 23 Apr 2018, Alexander Monakov wrote: > In discussion of proposed fix for PR 44281 Michael said: > [ https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01963.html ] > > [...] What I mean to say is, the following is currently proper use of > > global reg vars: > > > > > > register

Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell wrote: > On 04/20/2018 01:44 PM, Jason Merrill wrote: > > > Any time we need an actual adjustment, there will be a PLUS_EXPR. The > > issue is somehow distinguishing between a reinterpret_cast and one of > > the many other sources of

Re: [PATCH v2, rs6000] (PR84302) Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative

On 04/13/2018 05:40 PM, Segher Boessenkool wrote: > Rest looks fine... Let's see if I manage to commit it :-) Thanks, Segher! Can I push this to ibm/gcc-7-branch? PC

????????????!!!!!!

2018 FIFA World Cup Russia ? ?? ? ?, 1500 Pennsylvania Ave NW, Washington, DC 20005 ??? !! ??

Re: [PATCH 0/2] Require that constraints are used to reference global regs

Hi, On Mon, 23 Apr 2018, Alexander Monakov wrote: > I don't see how a user reading the documentation could infer that asms > and global reg vars interact like you say. That was always my interpretation of this clause (old docu, the current bullet list seems to have removed some clarity) and

Re: [C++ Patch] PR 68374 ("G++ -Wshadow doesn't warn about static member shadowing")

On Mon, Apr 23, 2018 at 5:17 PM, Paolo Carlini wrote: > Hi, > > this issue is by and large fixed in trunk, thus I wanted to resolve it as > such, marking it as fixed for 8.1.0. However the text of the warning is > misleading / wrong: > > declaration of ‘mVar’ shadows

[C++ Patch] PR 68374 ("G++ -Wshadow doesn't warn about static member shadowing")

Hi, this issue is by and large fixed in trunk, thus I wanted to resolve it as such, marking it as fixed for 8.1.0. However the text of the warning is misleading / wrong:     declaration of ‘mVar’ shadows a previous local where in fact the shadowed declaration isn't local, is a static data

C++ PATCH for c++/85470, wrong error with static data member

As Jakub suggested in the PR, these places that were checking DECL_IN_AGGR_P really should have been checking DECL_INITIALIZED_IN_CLASS_P. Tested x86_64-pc-linux-gnu, applying to trunk. commit f0c8d6d89ec136e9c35d057f742df5bbc397997d Author: Jason Merrill Date: Mon Apr 23

Re: [PATCH v2, rs6000] (PR84302) Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative

On Mon, Apr 23, 2018 at 02:23:42PM -0500, Paul Clarke wrote: > On 04/13/2018 05:40 PM, Segher Boessenkool wrote: > > Rest looks fine... Let's see if I manage to commit it :-) > > Thanks, Segher! > > Can I push this to ibm/gcc-7-branch? Don't ask me, I'm not maintainer of that branch. I would

Re: [PATCH 0/2] Require that constraints are used to reference global regs

On Mon, 23 Apr 2018, Michael Matz wrote: > In your follow-up patches you actually change the very documentation that > makes the above valid and supported ... I don't see how a user reading the documentation could infer that asms and global reg vars interact like you say. I am particularly

Re: RFC: C++ PATCH for c++/69763, making C++ alignof match C _Alignof

On Tue, Apr 17, 2018 at 8:50 AM, Joseph Myers wrote: > On Tue, 10 Apr 2018, Jason Merrill wrote: > >> But really this is beside the point: the x86 ABI says that the >> alignment of double is 4, so alignof(double) should be 4 regardless of >> what GCC wants to do

Re: [PATCH v2, rs6000] (PR84302) Fix _mm_slli_epi{32,64} for shift values 16 through 31 and negative

On 04/23/2018 02:47 PM, Segher Boessenkool wrote: > On Mon, Apr 23, 2018 at 02:23:42PM -0500, Paul Clarke wrote: >> Can I push this to ibm/gcc-7-branch? > Don't ask me, I'm not maintainer of that branch. I would point you > to the wiki page explaining who owns it, but i cannot find that page. >

Re: [PATCH 0/2] Require that constraints are used to reference global regs

On Mon, 23 Apr 2018, Michael Matz wrote: > Sooo, hmm, I don't know ;-) We could try doing a roll backwards and > demand explicit dependencies from asms with unknown effects on the few > unknown users, though the timing really makes me nervous. But my gut > feeling says to remain (or become

Re: [C++ Patch] PR 68374 ("G++ -Wshadow doesn't warn about static member shadowing")

Hi, On 23/04/2018 23:43, Jason Merrill wrote: On Mon, Apr 23, 2018 at 5:17 PM, Paolo Carlini wrote: Hi, this issue is by and large fixed in trunk, thus I wanted to resolve it as such, marking it as fixed for 8.1.0. However the text of the warning is misleading /

[PATCH] Optimize 128-bit vector insertion into zero 512-bit vector (PR target/85480)

Hi! As mentioned in the PR, vmov{aps,apd,dqa{,32,64}} 128-bit instructions zero the rest of 512-bit register, so we can optimize insertion into zero vectors using those instructions. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1? 2018-04-23 Jakub Jelinek

[PATCH] Fix reg-stack error-recovery on pr84828 testcase (PR target/84828)

Hi! My earlier attempts to replace bogus inline asm with something that reg-stack.c would be happy about failed, so this is just a quick hack to help the error-recovery on the pr84828.C testcase with -m32. I bet bunch of other spots will need any_malformed_asm tweaks, just don't have testcases