Re: [PATCH][AArch64] Add crypto_pmull attribute

Hi Ramana, Thanks for the review and approval. >> Please update the ARM backend with the new attribute too >> (define_insn "crypto_vmullp64" Its already been updated in the patch posted at:- https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00504.html >> Ok with that change and checking that you

[PATCH, rs6000] Add vec_reve support

GCC maintainers: This patch adds support for the various vec_reve builtins. The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE) and on powerpc64-unknown-linux-gnu (Power 8 BE) with no regressions. Is the patch OK for gcc mainline? Carl Love

Re: [committed] Fix -Werror=class-memaccess failures in jit testsuite (PR jit/81144)

On Tue, 2017-06-20 at 17:15 -0600, Martin Sebor wrote: > On 06/20/2017 03:25 PM, David Malcolm wrote: > > This patch fixes a couple of failures of the form: > > > > error: 'void* memset(void*, int, size_t)' clearing an object of > > non-trivial > > type 'struct quadratic_test'; use

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

Jeff Law wrote: > But the stack pointer might have already been advanced into the guard > page by the caller.   For the sake of argument assume the guard page is > 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that > the caller hasn't touched the 0xf1000 page. > > If FrameSize

Re: [committed] Fix -Werror=class-memaccess failures in jit testsuite (PR jit/81144)

On 06/20/2017 03:25 PM, David Malcolm wrote: This patch fixes a couple of failures of the form: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct quadratic_test'; use assignment or value-initialization instead [-Werror=class-memaccess] note:

Re: [PATCH][libgcc] Fix PR81080, build libgcov with large file support

On Wed, Jun 14, 2017 at 1:01 AM, Richard Biener wrote: > > The following patch makes sure we build the 32bit multilib libgcov with > large file support on x86_64-linux. libgcov.h ends up using auto-host.h > via including tconfig.h which is only valid for the main multilib >

Re: [PATCH] LFS support for libbacktrace

On Wed, Jun 14, 2017 at 3:40 AM, Richard Biener wrote: > > This fixes the [f]open use in libgfortran. Doesn't fix the ones > in libsanitizer because those appearantly use a copy because they > need to rename stuff... > > Bootstrapped and tested on x86_64-unknown-linux-gnu, ok

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

> But what you end up depending on is undocumented behavior of a > particular kernel implementation. That seems rather unwise. And it's the single example of such a thing in the entire codebase? I don't know the code of the sanitizer much, but from the outside it looks full of similar tricks...

Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget

On Tue, Jun 20, 2017 at 09:34:25PM +, Joseph Myers wrote: > On Tue, 20 Jun 2017, Segher Boessenkool wrote: > > > > And as you see see below the gcc.target tests have to be duplicated > > > anyway. Even if the C code is common there will many differences in > > > dg-options and

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 06:27 AM, Richard Biener wrote: > On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak wrote: >> On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote: >>> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote: On 06/20/2017

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 02:16 AM, Eric Botcazou wrote: > > Right, because the Linux kernel for x86/x86-64 is the only OS flavor that > doesn't let you probe the stack ahead of the stack pointer. All other > combinations of OS and architecture we tried (and it's quite a lot) do. But what you end up

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 03:27 AM, Richard Earnshaw (lists) wrote: > On 19/06/17 18:07, Jeff Law wrote: >> As some of you are likely aware, Qualys has just published fairly >> detailed information on using stack/heap clashes as an attack vector. >> Eric B, Michael M -- sorry I couldn't say more when I

Re: [i386] __builtin_ia32_stmxcsr could be pure

Ping. On Sat, 3 Jun 2017, Marc Glisse wrote: Hello, I don't think Richard's "sounds good" was meant as "ok to commit". Does an x86 maintainer want to approve or criticize the patch? https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02009.html On Fri, 26 May 2017, Richard Biener wrote: On

Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget

On Tue, 20 Jun 2017, Segher Boessenkool wrote: > > And as you see see below the gcc.target tests have to be duplicated > > anyway. Even if the C code is common there will many differences in > > dg-options and dg-require-effective-target. Trying to common these > > implementations only creates

Re: [PATCH] [i386] Enable Control-flow Enforcement Technology (CET).

This patch is completely missing documentation (in *.texi files) of the new options, attribute, built-in functions etc. You appear to be adding quite target-specific things to the architecture-independent compiler. If the attribute, for example, is to be architecture-independent, the

[committed] Fix bootstrap on armv6-*-freebsd

Hi All, I committed the chunk below to fix bootstrap on armv6*-*-freebsd. Andreas 2017-06-20 Andreas Tobler * config.gcc (armv6*-*-freebsd*): Change the target_cpu_cname to arm1176jzf-s. Index: config.gcc

Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget

On Tue, Jun 20, 2017 at 01:51:24PM -0500, Steven Munroe wrote: > I am not sure this works or is even a good idea. > > As an accident bmiintrin.h can be implemented as C code or common > builtins. But bmi2intrin.h depends on __builtin_bpermd which to my > knowledge is PowerISA only. Right. And

Re: [PATCH/AARCH64] Improve/correct ThunderX 1 cost model for Arith_shift

On Mon, Jun 19, 2017 at 2:00 PM, Andrew Pinski wrote: > On Wed, Jun 7, 2017 at 10:16 AM, James Greenhalgh > wrote: >> On Fri, Dec 30, 2016 at 10:05:26PM -0800, Andrew Pinski wrote: >>> Hi, >>> Currently for the following function: >>> int f(int a,

NOP conversions in X+CST+CST

Hello, now that FRE was fixed to avoid infinite recursion, this patch passes bootstrap+testsuite on x86_64-pc-linux-gnu multilib with all languages (including ada). This isn't exactly the patch that was reverted, because the previous patch did not actually handle vectors properly. It

[PATCH] [i386] Enable Control-flow Enforcement Technology (CET).

Control-flow Enforcement Technology (CET) provides the following capabilities to defend against ROP/JOP style control-flow subversion attacks: - Shadow Stack - return address protection to defend against Return   Oriented Programming, - Indirect branch tracking - free branch protection to defend  

[committed] Fix -Werror=class-memaccess failures in jit testsuite (PR jit/81144)

This patch fixes a couple of failures of the form: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct quadratic_test'; use assignment or value-initialization instead [-Werror=class-memaccess] note: 'struct quadratic_test' declared here cc1plus:

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 02:37 PM, Eric Botcazou wrote: >> But then valgrind won't be able to find bugs in the code (storing and later >> reading stuff into the volatile parts of the stack that could be overwritten >> by any asynchronous signal). GCC had various bugs in this area and >> valgrind has been

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

> But then valgrind won't be able to find bugs in the code (storing and later > reading stuff into the volatile parts of the stack that could be overwritten > by any asynchronous signal). GCC had various bugs in this area and > valgrind has been able to report those. Unless the probe instruction

[PATCH, VAX] Correct ffs instruction constraint

VAX' FFS as variable-length bit field instruction uses a "base" operand of type "vb" meaning "byte address". "base" can be 32 bits (SI) and due to the definition of ffssi2/__builtin_ffs() with the operand constraint "m", code can be emitted which incorrectly implies a mode-dependent (= longword,

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

From: Eric Botcazou Date: Tue, 20 Jun 2017 21:19:37 +0200 >> I'm fine with this change. > > I disagree, the existing policy is to avoid switches like -mfix-b2bst and use > -mfix- where is a CPU (here could be ut699e or ut700). Ok, I was not aware of that

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On Tue, Jun 20, 2017 at 10:21:14AM +0200, Eric Botcazou wrote: > > Out of curiousity, does the old Alpha/VMS stack-checking API meet the > > requirements? From what I recall, I think it does. > > No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it > because of

[PATCH, alpha, go]: Introduce applyRelocationsALPHA

This patch inroduces applyRelocationsALPHA to solve: FAIL: TestCgoConsistentResults FAIL: TestCgoPkgConfig FAIL: TestCgoHandlesWlORIGIN gotools errors. Bootstrapped and regression tested on alphaev68-linux-gnu. Uros. Index: go/debug/elf/file.go

Re: C++ PATCH for c++/81073, constexpr and static var in statement-expression

On Jun 20 2017, Jason Merrill wrote: > On Tue, Jun 20, 2017 at 5:40 AM, Andreas Schwab wrote: >> FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for errors, line 10) >> FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for excess errors) >> FAIL:

[PING^2] Re: [PATCH] c/c++: Add fix-it hints for suggested missing #includes

Ping re: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html On Fri, 2017-05-26 at 15:54 -0400, David Malcolm wrote: > Ping: > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html > > On Thu, 2017-05-04 at 12:36 -0400, David Malcolm wrote: > > As of r247522, fix-it-hints can

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

> I'm fine with this change. I disagree, the existing policy is to avoid switches like -mfix-b2bst and use -mfix- where is a CPU (here could be ut699e or ut700). -- Eric Botcazou

Re: [PING] C++ Re: [PATCH] C/C++: fix quoting of "aka" typedef information (PR 62170)

On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm wrote: > It's not clear to me what the issue alluded to with negative > obstack_blank is, but I chose to follow the above docs and use > obstack_blank_fast; am testing an updated patch in which the above line > now looks like: >

Re: [PING] C++ Re: [PATCH] C/C++: fix quoting of "aka" typedef information (PR 62170)

On Tue, 2017-06-20 at 14:01 -0400, Jason Merrill wrote: > On Tue, Jun 20, 2017 at 1:58 PM, Jason Merrill > wrote: > > On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm < > > dmalc...@redhat.com> wrote: > > > > + ob->next_free = p + type_start + type_len; > > > > I'm

[PATCH, testsuite]: Fix gcc.target/i386/pr80732.c execution test failure

2017-06-20 Uros Bizjak * gcc.target/i386/pr80732.c: Include fma4-check.h. (main): Renamed to ... (fma4_test): ... this. Tested on x86_64-linux-gnu and committed to mainline SVN. Uros. Index: gcc.target/i386/pr80732.c

Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget

On Tue, 2017-06-20 at 09:04 +, Hurugalawadi, Naveen wrote: > Hi Joesph, > > Thanks for your review and valuable comments on this issue. > > Please find attached the patch that merges x86-intrinsics for AArch64 and PPC > architectures. > > >> it would seem to me to be a bad idea to duplicate

Re: [PATCH] Fix UB in ira-costs.c (find_costs_and_classes)

On 06/20/2017 03:27 AM, Jakub Jelinek wrote: Hi! bootstrap-ubsan revealed many ../../gcc/ira-costs.c:1747:20: runtime error: member access within null pointer of type 'cost_classes *[107]' issues. The problem is that cost_classes_ptr is sometimes NULL, but in those cases we have early exit:

Re: C++ PATCH for c++/81073, constexpr and static var in statement-expression

On Tue, Jun 20, 2017 at 5:40 AM, Andreas Schwab wrote: > FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for errors, line 10) > FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++11 (test for excess errors) > FAIL: g++.dg/cpp0x/constexpr-cast.C -std=c++14 (test for errors, line

Re: [PATCH v2] C++: Add fix-it hints for -Wold-style-cast

On Wed, May 3, 2017 at 9:51 AM, David Malcolm wrote: > On Thu, 2017-04-27 at 23:03 +0200, Marek Polacek wrote: >> On Thu, Apr 27, 2017 at 05:10:24PM -0400, David Malcolm wrote: >> > + /* First try const_cast. */ >> > + trial = build_const_cast (dst_type, orig_expr, 0 /*

Re: [PATCH][X86] Fix rounding pattern similar to PR73350

Hello Julia, Uroš, On 16 Jun 09:05, Uros Bizjak wrote: > On Fri, Jun 16, 2017 at 8:46 AM, Koval, Julia wrote: > > Hi, > > > > This test hangs on avx512er, maybe that's why: > >> According to POSIX, the behavior of a process is undefined after it > >> ignores a SIGFPE,

Re: [Patch AArch64] Add rcpc extension

On Tue, Jun 20, 2017 at 6:50 AM, James Greenhalgh wrote: > > Hi, > > While GCC doesn't need to know anything about the RcPc extension for code > generation, we do need to add the extension flag to the string we pass > to the assembler when we're compiling for a CPU which

[PATCH/AARCH64 v2] Enable software prefetching (-fprefetch-loop-arrays) for ThunderX 88xxx

Here is the updated patch based on the new infrastructure which is now included. OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions and tested again on SPEC CPU 2006 on THunderX T88 with the speed up mentioned before. Thanks, Andrew Pinski ChangeLog: *

Re: [PING] C++ Re: [PATCH] C/C++: fix quoting of "aka" typedef information (PR 62170)

On Tue, Jun 20, 2017 at 1:58 PM, Jason Merrill wrote: > On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm wrote: >>> + ob->next_free = p + type_start + type_len; > > I'm uncomfortable with modifying the obstack directly. Why not use > obstack_free?

Re: [PING] C++ Re: [PATCH] C/C++: fix quoting of "aka" typedef information (PR 62170)

On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm wrote: >> + ob->next_free = p + type_start + type_len; I'm uncomfortable with modifying the obstack directly. Why not use obstack_free? I guess for that you'd want to change type_start to a pointer and get it from

C++ PATCH for c++/80972, C++17 ICE with packed class

In C++17 mode we check to make sure that we are initializing directly from class prvalues rather than copying them, which hit an issue with packed fields: we create a temporary for binding a reference to a packed field, and then pass that temporary to the copy constructor. This isn't actually a

[C++ PATCH] remove unused identifier

'nelts' was a suspiciously gnu user space identifier to have. Turns out we don't use it anywhere. so killed ... nathan -- Nathan Sidwell 2017-06-20 Nathan Sidwell * cp-tree.h (CPTI_NELTS_IDENTIFIER): Delete. (nelts_identifier): Delete. * decl.c

Re: [PATCH] Improved diagnostics for casts and enums

So here's the patch that reverts the special enum handling in type_to_string and uses %q#T instead of %qT for two casting-related diagnostics. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk? The "E {enum}'" notation is still on trunk so it seems that this patch has never been

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 06:17 AM, Uros Bizjak wrote: > On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote: >> On 06/20/2017 01:10 PM, Uros Bizjak wrote: >> >>> 74,99% a.outa.out [.] test_or >>> 12,50% a.outa.out [.] test_movb >>> 12,50% a.out

[PATCH, alpha]: Update libstdc++ baseline_symbols.txt

2017-06-20 Uros Bizjak * config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update. Tested on alphaev68-linux-gnu and committed to mainline SVN. Uros. Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt

[PING] C++ Re: [PATCH] C/C++: fix quoting of "aka" typedef information (PR 62170)

Ping re the C++ part of this: https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00242.html Marek approved the C parts; are the C++ parts OK for trunk? Or can I self-approve this? (exactly what the boundaries of my"diagnostic messages" maintainer remit are aren't clear to me). Thanks Dave On

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 02:27 AM, Richard Earnshaw (lists) wrote: > On 19/06/17 20:04, Jeff Law wrote: >> On 06/19/2017 11:50 AM, Joseph Myers wrote: >>> On Mon, 19 Jun 2017, Jeff Law wrote: >>> A key point to remember is that you can never have an allocation (potentially using more than one

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 02:21 AM, Eric Botcazou wrote: >> Out of curiousity, does the old Alpha/VMS stack-checking API meet the >> requirements? From what I recall, I think it does. > > No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it > because of valgrind. I'd personally

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

On Jun 20, 2017, at 8:31 AM, Thomas Preudhomme wrote: > > 2017-06-14 Thomas Preud'homme > > * dg-cmp-results.sh: Keep test result lines rather than throwing > header and summary to support sum files with multiple tools.

Re: [Patch match.pd] Fold (A / (1 << B)) to (A >> B)

On Fri, Jun 16, 2017 at 11:41:57AM +0200, Richard Biener wrote: > On Fri, 16 Jun 2017, James Greenhalgh wrote: > > On Mon, Jun 12, 2017 at 03:56:25PM +0200, Richard Biener wrote: > > > + We can't do the same for signed A, as it might be negative, which > > > would > > > + introduce undefined

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

From: Sebastian Huber Date: Tue, 20 Jun 2017 07:55:33 +0200 > would someone mind reviewing this patch please. It was already sent > for review on January this year and got no attention. Now we are in a > different development stage. > >

[Patch AArch64] Add initial tuning support for Cortex-A55 and Cortex-A75

Hi, This patch adds support for the ARM Cortex-A75 and Cortex-A55 processors through the -mcpu/-mtune values cortex-a55 and cortex-a75, and an ARM DynamIQ big.LITTLE configuration of these two processors through the -mcpu/-mtune value cortex-a75.cortex-a55 The ARM Cortex-A75 is ARM's latest and

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

Hi Mike, Sorry, there was a mistake in the patch I sent. Please find an updated patch below. ChangeLog entry unchanged: *** contrib/ChangeLog *** 2017-06-14 Thomas Preud'homme * dg-cmp-results.sh: Keep test result lines rather than throwing

Re: [PATCH/AARCH64] Improve aarch64 conditional compare usage

On Tue, 2017-06-20 at 14:58 +0100, James Greenhalgh wrote: > On Fri, Jun 16, 2017 at 10:06:51AM -0700, Steve Ellcey wrote: > > > > > > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html > > > > Ping. > Hi Steve, > > These changes all look like they are to the tree pass rather than to the

Re: [PATCH][AArch64] Improve dup pattern

James Greenhalgh wrote: > > Have you tested this in cases where an integer dup is definitely the right > thing to do? Yes, this still generates:   #include   void f(unsigned a, unsigned b, uint32x4_t *c)   {     c[0] = vdupq_n_u32(a);     c[1] = vdupq_n_u32(b);   } dup v1.4s, w0

[PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

Hi, Function cmse_nonsecure_entry_clear_before_return has code to deal with high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do not support more than 16 double VFP registers (D0-D15). This makes this security-sensitive code harder to read for not much benefit since libcall

Re: SSA range class and removal of VR_ANTI_RANGEs

On 06/20/2017 02:41 AM, Aldy Hernandez wrote: On 05/23/2017 03:26 PM, Martin Sebor wrote: On 05/23/2017 04:48 AM, Aldy Hernandez wrote: + void Union (wide_int x, wide_int y); + bool Union (const irange ); + bool Union (const irange , const irange ); + + // THIS = THIS ^ [X,Y]. Return

Re: [PATCH][AArch64] Mark symbols as constant

Richard Earnshaw wrote: > What testing has this had with -fpic?  I'm not convinced that this > assertion is true in that case? I ran the GLIBC tests which pass. -fpic works since it does also form a constant address, ie. instead of: adrp x1, global add x1, x1, :lo12:global we do: adrp x1,

Re: [Patch AArch64] Add rcpc extension

On 20/06/17 14:50, James Greenhalgh wrote: > > Hi, > > While GCC doesn't need to know anything about the RcPc extension for code > generation, we do need to add the extension flag to the string we pass > to the assembler when we're compiling for a CPU which implements the RcPc > extension. > >

Re: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only

On 06/20/2017 02:16 PM, Richard Biener wrote: Nice. This looks ok. Great, thank you! I'm mildy curious about the deecrease of debuginfo size for cc1 -- did you spot anything obvious there? Well, the benchmark I exposed was for the whole file size, not just .debug_info section size. Just

Re: [testsuite, i386] Always check for target i?86 and x86_64

On 06/20/2017 01:35 PM, Rainer Orth wrote: > JonY <10wa...@gmail.com> writes: > >> On 06/20/2017 01:01 PM, Rainer Orth wrote: >>> Given that there were no other comments, I've installed the patch. It >>> would still be nice if the Cygwin/MingW maintainer could comment on the >>> testcase

Re: [patch, libfortran, RFC] Speed up cshift with array shift

Hi Thomas, On my machine I get the following timings without the patch cpu time cshift dim=1 0.490763009 cpu time do loop dim=15.57969809E-02 cpu time cshift dim=2 0.416319966 cpu time do loop dim=2 0.187106013 cpu time cshift dim=31.37362707 cpu time do loop

[AArch64] Improve HFA code generation

Hi, For this code: struct y { float x[4]; }; float bar3 (struct y x) { return x.x[3]; } GCC generates: bar3: fmovx1, d2 mov x0, 0 bfi x0, x1, 0, 32 fmovx1, d3 bfi x0, x1, 32, 32 sbfxx0, x0, 32, 32

Re: [PATCH] Fix PR71815 (SLSR misses PHI opportunities)

On Jun 20, 2017, at 6:23 AM, Richard Biener wrote: > > On Fri, Jun 16, 2017 at 6:10 PM, Bill Schmidt > wrote: >> Hi, >> >> PR71815 identifies a situation where SLSR misses opportunities for >> PHI candidates when code hoisting is enabled

[PING^3] re [PATCH v2] C++: Add fix-it hints for -Wold-style-cast

Ping re this patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00204.html (more description can be seen in v1 of the patch here: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01429.html ) On Mon, 2017-06-05 at 12:41 -0400, David Malcolm wrote: > Ping re this patch: > >

Re: [PATCH/AARCH64] Improve aarch64 conditional compare usage

On Fri, Jun 16, 2017 at 10:06:51AM -0700, Steve Ellcey wrote: > > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html > > Ping. Hi Steve, These changes all look like they are to the tree pass rather than to the AArch64 back end. Maybe reposting it without the AArch64 tag will get it more

[Patch AArch64] Add rcpc extension

Hi, While GCC doesn't need to know anything about the RcPc extension for code generation, we do need to add the extension flag to the string we pass to the assembler when we're compiling for a CPU which implements the RcPc extension. I've built a toolchain with this patch applied, and checked

Re: [PATCH 2/3] Simplify wrapped binops

On Tue, Jun 20, 2017 at 3:08 PM, Robin Dapp wrote: >>> Currently, extract_... () does that all that for me, is it really too >>> expensive to call? I guess, using get_range_info first and calling >>> extract when get_range_info returns a VR_RANGE is not really a

[arm-embedded] [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

Hi, We have decided to apply the following patch to the embedded-6-branch to fix naming of an ARM intrinsic. ChangeLog entry is as follows: 2017-06-20 Thomas Preud'homme Backport from mainline 2017-05-04 Prakhar Bahuguna

[Patch AArch64 obvious] Fix expected string for fp16 extensions

Hi, As currently coded, the native detection of the fp16 architecture extension from the ARMv8.2-A extensions looks for the string "fp16", but the kernel exposes support of these features through two strings "fphp, for scalar 16-bit floating point support, and "asimdhp" for vector 16-bit

Re: [testsuite, i386] Always check for target i?86 and x86_64

JonY <10wa...@gmail.com> writes: > On 06/20/2017 01:01 PM, Rainer Orth wrote: >> Given that there were no other comments, I've installed the patch. It >> would still be nice if the Cygwin/MingW maintainer could comment on the >> testcase situation for those targets. > > Honestly, I'm not sure

[Patch AArch64 obvious] Rearrange the processors in aarch64-cores.def

Hi, This patch rearranges the cores in aarch64-cores.def first by architecture revision, then by alphabetical order of implementer ID. This just neatens up the file a bit, as it is growing to be unwieldy. Committed as revision 249410. Thanks, James --- 2017-06-20 James Greenhalgh

Re: [RFC] Dejagnu patch to handle multi-line directives

Mike Stump writes: > On Jun 10, 2017, at 12:57 AM, Tom de Vries wrote: >> >> one thing that has bothered me on a regular basis is the inability to >> spread long dejagnu directives over multiple lines. > > I'm not terribly in favor of this. I'd

Re: [testsuite, i386] Always check for target i?86 and x86_64

On 06/20/2017 01:01 PM, Rainer Orth wrote: > > once I got the syntax right, this worked fine: it needs > > { target { ilp32 || lp64 } } > > instead ;-) > > I've also now managed to complete a Darwin/x86_64 bootstrap by locally > reverting the two culprit patches for PR bootstrap/81033

[arm-embedded] [PATCH, GCC/LTO, ping] Fix PR69866: LTO with def for weak alias in regular object file

Hi, We have decided to apply the referenced fix (r249352) to the ARM/embedded-6-branch along with its initial commit (r249224) to fix an ICE with LTO and aliases. Fix PR69866 2017-06-20 Thomas Preud'homme Backport from mainline 2017-06-15

[arm-embedded] [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

Hi, We have decided to apply the following patch to the ARM/embedded-6-branch and ARM/embedded-7-branch to implement the __ARM_FEATURE_COPROC coprocessor intrinsic feature macro. 2017-06-20 Thomas Preud'homme Backport from mainline 2017-06-20

Re: [PATCH 2/3] Simplify wrapped binops

>> Currently, extract_... () does that all that for me, is it really too >> expensive to call? I guess, using get_range_info first and calling >> extract when get_range_info returns a VR_RANGE is not really a favorable >> thing to do either? :) > Not only the cost, we should avoid introducing more

Re: [PATCH] ASAN: handle addressable params (PR sanitize/81040).

On 06/20/2017 11:32 AM, Jakub Jelinek wrote: > On Tue, Jun 20, 2017 at 11:23:36AM +0200, Martin Liška wrote: >>> Then something needs to be done for debugging too. If it is without VTA, >>> then probably just having DECL_VALUE_EXPR is good enough, otherwise >>> (VTA) you probably don't want that

Re: [testsuite, i386] Always check for target i?86 and x86_64

Hi Jonathan, > On 15/06/17 12:51 +0200, Rainer Orth wrote: >>I happened to notice that recently a couple of testcases have sneaked in >>that are restricted to x86_64-*-* targets only. This is always wrong: >>it should be i?86-*-* and x86_64-*-* alike, eventually restricing the >>test to ilp32 or

Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.

On Mon, Jun 19, 2017 at 12:40:53PM -0500, Segher Boessenkool wrote: > On Mon, Jun 19, 2017 at 05:01:10PM +0100, Richard Earnshaw (lists) wrote: > > Yeah, and I'm not suggesting we change the logic there (sorry if the > > description was misleading). Instead I'm proposing that we handle more > >

[PR c++/67074] Namespace aliases to same name

This patch fixes a couple of places where namespace aliases refer to the same namespace. These are not ambiguous or conflicting. Firstly, aliases of the same name may exist in namespaces searched via using directives. Those should be merged in lookup, which is the change to add_value.

[PATCH] Fix PR81097

The following fixes PR81097 but not eventually more latent issues in transforming ~x "back" to -x - 1. I want a testcase before fiddling more with this. The following follows the pattern of previous fixes to this function, making sure to do negation in 'type'. Bootstrapped and tested on

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19 June 2017 at 16:47, Thomas Preudhomme wrote: > > > On 19/06/17 15:31, Christophe Lyon wrote: >> >> On 19 June 2017 at 16:11, Thomas Preudhomme >> wrote: >>> >>> >>> >>> On 19/06/17 10:16, Thomas Preudhomme wrote:

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak wrote: > On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote: >> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote: >>> On 06/20/2017 01:10 PM, Uros Bizjak wrote: >>> 74,99% a.out

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote: > On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote: >> On 06/20/2017 01:10 PM, Uros Bizjak wrote: >> >>> 74,99% a.outa.out [.] test_or >>> 12,50% a.outa.out [.]

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote: > On 06/20/2017 01:10 PM, Uros Bizjak wrote: > >> 74,99% a.outa.out [.] test_or >> 12,50% a.outa.out [.] test_movb >> 12,50% a.outa.out [.] test_movl > > Could you try

Re: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only

On Fri, Jun 16, 2017 at 6:35 PM, Pierre-Marie de Rodat wrote: > On 05/31/2017 11:08 AM, Pierre-Marie de Rodat wrote: >> >> On 05/31/2017 09:34 AM, Richard Biener wrote: >>> >>> Actually for the bigger picture I'd refactor >>> rest_of_decl_compilation, not calling it from the

Re: [PATCH] Call BUILT_IN_ASAN_HANDLE_NO_RETURN before BUILT_IN_UNWIND_RESUME (PR sanitizer/81021).

PING^1 On 06/13/2017 10:09 AM, Martin Liška wrote: > Hi. > > For a function that does not handle an expection (and calls > BUILT_IN_UNWIND_RESUME), > we need to emit call to BUILT_IN_ASAN_HANDLE_NO_RETURN. That will clean up > stack > which can possibly contain poisoned shadow memory that will

Re: [PATCH 2/3] Make early return predictor more precise.

On 06/19/2017 01:11 PM, Jan Hubicka wrote: >> Ok, you're right that we can preserve the predictor. However, let's consider >> following test-case: >> >> static >> int baz(int a) >> { >> if (a == 1) >> return 1; >> >> return 0; >> } >> >> >> static >> int bar(int a) >> { >> if (a ==

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 01:10 PM, Uros Bizjak wrote: > 74,99% a.outa.out [.] test_or > 12,50% a.outa.out [.] test_movb > 12,50% a.outa.out [.] test_movl Could you try notl/notb/negl/negb as well, please? Thanks, Florian

Re: [PATCH][AArch64] Emit SIMD moves as mov

James Greenhalgh wrote: > > Does this introduce a dependency on a particular binutils version, or have > we always supported this alias? > > The patch looks OK, but I don't want to introduce a new dependency so please > check how far back this is supported. Well gas/testsuite/gas/aarch64/alias.s

Re: [PATCH GCC][12/13]Workaround reduction statements for distribution

On Tue, Jun 20, 2017 at 11:20 AM, Bin.Cheng wrote: > On Fri, Jun 16, 2017 at 6:15 PM, Bin.Cheng wrote: >> On Fri, Jun 16, 2017 at 11:21 AM, Richard Biener >> wrote: >>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng

Re: [PATCH GCC][11/13]Annotate partition by its parallelism execution type

On Tue, Jun 20, 2017 at 11:18 AM, Bin.Cheng wrote: > On Fri, Jun 16, 2017 at 11:10 AM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >>> Hi, >>> This patch checks and records if partition can be

Re: [PATCH GCC][07/13]Preserve data references for whole distribution life time

On Mon, Jun 19, 2017 at 5:59 PM, Bin.Cheng wrote: > On Mon, Jun 19, 2017 at 4:16 PM, Richard Biener > wrote: >> On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote: >>> On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener >>>

Re: [PATCH GCC][10/13]Compute and cache data dependence relation

On Tue, Jun 20, 2017 at 11:15 AM, Bin.Cheng wrote: > On Fri, Jun 16, 2017 at 11:03 AM, Richard Biener > wrote: >> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote: >>> Hi, >>> This patch computes and caches data dependence

Re: [PATCH] Fix PR71815 (SLSR misses PHI opportunities)

On Fri, Jun 16, 2017 at 6:10 PM, Bill Schmidt wrote: > Hi, > > PR71815 identifies a situation where SLSR misses opportunities for > PHI candidates when code hoisting is enabled (which is now on by > default). The basic problem is that SLSR currently uses an overly >

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

On Wed, 7 Jun 2017, Richard Biener wrote: > On Fri, 19 May 2017, Richard Biener wrote: > > > > > This is a repost of the main part of the early LTO debug support. > > The only changes relative to the last post is in the dwarf2out.c > > pieces due to Jasons review and Jakubs introduction of > >

Re: [PATCH][AArch64] Emit SIMD moves as mov

On Tue, Jun 20, 2017 at 12:06:29PM +0100, Wilco Dijkstra wrote: > SIMD moves are currently emitted as ORR. Change this to use the MOV > pseudo instruction just like integer moves (the ARM-ARM states MOV is the > preferred disassembly), improving readability of -S output. > > Passes bootstrap, OK

  1   2   >