Re: SSA range class and removal of VR_ANTI_RANGEs

On 06/20/2017 10:59 AM, Martin Sebor wrote: 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

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

> Ok, I was not aware of that policy. The reason is that experience showed that you may have several issues for the same class of processors (e.g. for the original UT699) and you don't want to have to pass a list of -mfix- switches to fix them all. Moreover, the workarounds may interact

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

On Tue, 20 Jun 2017, James Greenhalgh wrote: > > 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

Re: [RFC PATCH] -fsanitize=pointer-overflow support (PR sanitizer/80998)

On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote: > > It would be an attempt to avoid sanitizing int foo (int *p) { return p[10] > > + p[-5]; } > > (when the offset is constant and small and we dereference it). > > If there is no page mapped at NULL or at the highest page in the

Re: NOP conversions in X+CST+CST

On Tue, Jun 20, 2017 at 11:00 PM, Marc Glisse wrote: > 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

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

On 21/06/17 09:44, Andreas Schwab wrote: > On Jun 21 2017, "Richard Earnshaw (lists)" wrote: > >> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the >> stack which, with at least 8 parameters passed in registers, would allow >> for calls with 40

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

On Tue, Jun 20, 2017 at 4:34 PM, Pierre-Marie de Rodat wrote: > 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? >

Re: [i386] __builtin_ia32_stmxcsr could be pure

Hello! > glibc marks fegetround as a pure function. On x86, people tend to use > _MM_GET_ROUNDING_MODE instead, which could benefit from the same. I think it > is safe, but > a second opinion would be welcome. I could have handled just this builtin, > but it seemed better to > provide

Re: [RFC PATCH] -fsanitize=pointer-overflow support (PR sanitizer/80998)

On Wed, 21 Jun 2017, Jakub Jelinek wrote: > On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote: > > > It would be an attempt to avoid sanitizing int foo (int *p) { return > > > p[10] + p[-5]; } > > > (when the offset is constant and small and we dereference it). > > > If there is no

Re: [RFC PATCH] -fsanitize=pointer-overflow support (PR sanitizer/80998)

On Wed, 21 Jun 2017, Jakub Jelinek wrote: > On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote: > > > 2) libcpp/line-map.c has this: > > > static int > > > location_adhoc_data_update (void **slot, void *data) > > > { > > > *((char **) slot) += *((int64_t *) data); > > > return 1;

Re: SSA range class and removal of VR_ANTI_RANGEs

Hi folks. The following is another iteration of the SSA range class, taking into account many of the suggestions posted on this thread, especially the addition of a memory efficient class for storage, folding non-zero bits back into the range information, C++ suggestions by Martin, and some

Re: Add quality tracking for profile counter

On Jun 19 2017, Jan Hubicka wrote: > this patch makes us to track quality of the profile. This is useful > to disable some agressive optimizations when counts are known to be > unreliable. This breaks bootstrap on ia64 with a comparison failure in value-prof.o. The only

RE: [PATCH] [Aarch64] Variable shift count truncation issues

Updated the patch per Richard's suggestions to allow scheduling of instructions before reload. Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? 2017-05-22 Kyrylo Tkachov Michael Collison PR target/70119

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

On 20/06/17 22:39, Jeff Law wrote: > 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

[patch][x86] Remove old rounding code

Hi, This patch removes old parallel code for avx512er. Parallel in this case can't be generated anymore, because all existing patterns were reworked to unspec in r249423 and r249009. Ok for trunk? gcc/ * gcc/config/i386/i386.c (ix86_erase_embedded_rounding): Remove code for old

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

On Jun 21 2017, "Richard Earnshaw (lists)" wrote: > A mere 256 bytes for the caller would permit 32 x 8byte arguments on the > stack which, with at least 8 parameters passed in registers, would allow > for calls with 40 parameters. There can't be many in that space.

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

On 20 Jun, Jason Merrill wrote: > 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

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

> > Ok, so I fixed that in the described way. There's one remaining fallout of: > gcc/testsuite/gcc.dg/tree-ssa/ipa-split-5.c > > Where a fnsplit is properly done, but then it's again inlined: > > Considering split_me.part.0/5 with 23 size > to be inlined into test/2 in unknown:0 > Estimated

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

On 21/06/17 00:22, Wilco Dijkstra wrote: > 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

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

On Jun 20 2017, 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. Take a

Re: [RFC PATCH] -fsanitize=pointer-overflow support (PR sanitizer/80998)

On Tue, Jun 20, 2017 at 09:41:43AM +0200, Richard Biener wrote: > > 2) libcpp/line-map.c has this: > > static int > > location_adhoc_data_update (void **slot, void *data) > > { > > *((char **) slot) += *((int64_t *) data); > > return 1; > > } > > where the (why int64_t always?, we really need

Backports to 6.x

As release managers are planning to release next version of GCC 6. I would like to do backport revisions attached. The only complicated one is the one for PR69953 where I decided to backport also refactoring patches applied by Nathan (244529, 244156). I would appreciate another pair of eyes to

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

On 21/06/17 09:46, Richard Earnshaw (lists) wrote: > On 21/06/17 09:44, Andreas Schwab wrote: >> On Jun 21 2017, "Richard Earnshaw (lists)" wrote: >> >>> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the >>> stack which, with at least 8 parameters

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

Richard Earnshaw wrote: > A mere 256 bytes for the caller would permit 32 x 8byte arguments on the > stack which, with at least 8 parameters passed in registers, would allow > for calls with 40 parameters.  There can't be many in that space.  Any > function making calls with more than that might

Re: [committed] Fix bootstrap on armv6-*-freebsd

On 20/06/17 22:29, Andreas Tobler wrote: > 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:

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

On 20/06/17 16:41, James Greenhalgh wrote: > > 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

Re: [gcn][patch] Add -mgpu option and plumb in assembler/linker

On 06/06/17 20:52, Andrew Stubbs wrote: Thomas objects to the new option, and after talking with him the reasoning seems sound. GCC has been moving away from -mcpu in any case, so I guess I'll put -march and -mtune back, and use those for the same purpose. I'll commit the patch with those

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

On Tue, Jun 20, 2017 at 09:45:10PM +0200, Andreas Schwab wrote: > 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:

Re: [PATCH] PR libstdc++/81092 add std::wstring symbols and bump library version

On 14/06/17 19:13 +0100, Jonathan Wakely wrote: There are two symbols defined in GCC 7.1's libstdc++.6.0.23 library which are not exported on all targets (because I wrote "m" in the linker script instead of "[jmy]"). This patch bumps the library version on gcc-7-branch to 6.0.24 and exports the

RE: [PATCH][GCC][AArch64] optimize float immediate moves (2 /4) - HF/DF/SF mode.

> > movi\\t%0.4h, #0 > > - mov\\t%0.h[0], %w1 > > + fmov\\t%s0, %w1 > > Should this not be %h0? The problem is that H registers are only available in ARMv8.2+, I'm not sure what to do about ARMv8.1 given your other feedback Pointing out that the bit patterns between how it's stored in s

Re: [Patch AArch64] Stop generating BSL for simple integer code

*ping* Thanks, James On Mon, Jun 12, 2017 at 02:44:40PM +0100, James Greenhalgh wrote: > [Sorry for the re-send. I spotted that the attributes were not right for the > new pattern I was adding. The change between this and the first version was: > > + [(set_attr "type"

[committed] Fix ICE with shared clause on non-static data member in a member function (PR c++/81130)

Hi! This patch is both a fix for the ICE on the testcase below and an optimization - there is no point to keep shared clauses for vars that have ctors/dtors, but aren't referenced in the construct, for privatization clauses we do it because of the ctors/dtors involved, but for shared there is no

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

On Tue, Jun 20, 2017 at 02:07:22PM -0700, Andrew Pinski wrote: > 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:

Re: [Patch AArch64 2/2] Fix memory sizes to load/store patterns

*ping* Thanks, James On Mon, Jun 12, 2017 at 02:54:00PM +0100, James Greenhalgh wrote: > > Hi, > > There seems to be a partial misconception in the AArch64 backend that > load1/load2 referred to the number of registers to load, rather than the > number of words to load. This patch fixes that

Re: [Mechanical Patch ARM/AArch64 1/2] Rename load/store scheduling types to encode data size

On Mon, Jun 12, 2017 at 03:28:52PM +0100, Kyrill Tkachov wrote: > > On 12/06/17 14:53, James Greenhalgh wrote: > >Hi, > > > >In the AArch64 backend and scheduling models there is some confusion as to > >what the load1/load2 etc. scheduling types refer to. This leads to us using > >load1/load2 in

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

On 20/06/17 15:56, Wilco Dijkstra wrote: > 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

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

On Tue, Jun 20, 2017 at 11:13:24AM -0700, Andrew Pinski wrote: > 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 >

Re: Backports to 6.x

On 06/21/2017 04:14 AM, Martin Liška wrote: As release managers are planning to release next version of GCC 6. I would like to do backport revisions attached. The only complicated one is the one for PR69953 where I decided to backport also refactoring patches applied by Nathan (244529,

Re: [PATCH 2/3] Simplify wrapped binops

> use INTEGRAL_TYPE_P. Done. > but you do not actually _use_ vr_outer. Do you think that if > vr_outer is a VR_RANGE then the outer operation may not > possibly have wrapped? That's a false conclusion. These were remains of a previous version. vr_outer is indeed not needed anymore; removed.

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

On 06/21/2017 09:11 AM, Richard Biener wrote: Sure, no obligation for you to enhance Fortran debug! Understood, thanks. For your information, I just committed the change. Thank you again for reviewing! -- Pierre-Marie de Rodat

Re: [PATCH] Fix PR81090, properly free niter estimates

On 20 June 2017 at 11:45, Richard Biener wrote: > On Tue, 20 Jun 2017, Alan Hayward wrote: > >> >> > On 19 Jun 2017, at 13:35, Richard Biener wrote: >> > >> > On Mon, 19 Jun 2017, Christophe Lyon wrote: >> > >> >> Hi Richard, >> >> >> >> On 16 June 2017 at

Re: [PATCH 4/N] Recover GOTO predictor.

On 06/21/2017 03:06 PM, Martin Liška wrote: > Hello. > > There's one additional predictor enhancement that is GOTO predict that > used to working. Following patch adds expect statement for C and C++ family > languages. > > There's one fallout which is vrp24.c test-case, where only 'Simplified >

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

Hello all, I have modified the patch so that the workaround is enabled by using either mfix-ut699, -mfix-ut700, or -mfix-gr712rc. Daniel - This patch adds a workaround to the Sparc backend for the LEON3FT store-store errata. It is enabled when using the -mfix-ut699, -mfix-ut700, or

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

On 06/21/2017 10:26 AM, Jan Hubicka wrote: >> >> Ok, so I fixed that in the described way. There's one remaining fallout of: >> gcc/testsuite/gcc.dg/tree-ssa/ipa-split-5.c >> >> Where a fnsplit is properly done, but then it's again inlined: >> >> Considering split_me.part.0/5 with 23 size >> to

[PATCH][AArch64] Fix atomic_cmp_exchange_zero_reg_1.c with +lse

Hi all, As Andrew pointed out, the patch at r248921 (https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01648.html) that allowed const0_rtx as an argument to the compare-exchange patterns was incomplete. It didn't extend the TARGET_LSE patterns as well, causing the expander to generate an invalid

[PATCH 4/N] Recover GOTO predictor.

Hello. There's one additional predictor enhancement that is GOTO predict that used to working. Following patch adds expect statement for C and C++ family languages. There's one fallout which is vrp24.c test-case, where only 'Simplified relational' appears just once. Adding Richi and Patrick who

Re: [PATCH, testsuite] Add effective target stack_size

On Fri, Jun 09, 2017 at 04:24:30PM +0200, Tom de Vries wrote: > * gcc.dg/tree-prof/comp-goto-1.c: Same. > * gcc.dg/tree-prof/pr44777.c: Same. > --- a/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c > +++ b/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c > @@ -1,6 +1,8 @@ > /* {

[PATCH, committed], Update tests for pr80510 on PowerPC

Andreas Schwab noticed that the tests for PR target/80510 were failing on 32-bit PowerPC systems. In looking at the tests, the reason was it was trying to create a test that had more than 32 live floating point values. The loop to use all of the values had tests of the form: for (i = 0; i <

libgo patch committed: implement randomTrap on mips64p32*

This patch from James Cowgill implements randomTrip for mips64p32*. Bootstrapped on x86_64-pc-linux-gnu, which proves little. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision

Go patch committed: Fix missing case in Array_type::get_lvalue_pointer

This patch from Than McIntosh fixes a missing case in Array_type::get_value_pointer in the Go frontend. It updates the code in Array_type::get_value_pointer that handles "lvalue" context to look for both regular var expressions and temp var expressions, since both can appear in array/slice index

libgo patch committed: Fix ptrace implementation on MIPS

This patch from James Cowgill fixes the libgo ptrace implementation for MIPS by modifying mksysinfo.sh to look for the pt_regs struct. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, which admittedly proves little. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE

libgo patch committed: Remove old MIPS architecture names

This patch from James Cowgill finishes standardizing on the names used in the gc toolchain by removing the old names used in the gofrontend sources. It drops the mipso64 ABI, which has been dead for a long time (as a historical note I think I invented the o64 ABI by accident when I did the

[PATCH,rs6000] Add IEEE 128 support for several existing built-in functions

This patch adds IEEE 128 support to the existing scalar_insert_exp, scalar_extract_exp, scalar_extract_sig, scalar_test_data_class, and scalar_test_neg rs6000 built-in functions. Test programs are provided to exercise the new IEEE 128 functionality and to validate forms of these built-in

Re: [PATCH, alpha, go]: Introduce applyRelocationsALPHA

On Tue, Jun 20, 2017 at 12:46 PM, Uros Bizjak wrote: > This patch inroduces applyRelocationsALPHA to solve: > > FAIL: TestCgoConsistentResults > FAIL: TestCgoPkgConfig > FAIL: TestCgoHandlesWlORIGIN > > gotools errors. > > Bootstrapped and regression tested on

Re: [PATCH v2, rs6000] Add vec_reve support

GCC maintainers: I have updated the patch per the comments from Segher. I used the functions GET_MODE_UNIT_SIZE() and GET_MODE_NUNITS() as suggested. I didn't know about these functions, I checked out all the various functions defined in machmode.h for future reference. Note, I did make some

libgo patch committed: Use gc toolchain names for MIPS variants

This patch from James Cowgill changes libgo to use the gc toolchain names for MIPS variants. Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE

libgo patch committed: Add mips64p32* to cgo tool

This libgo patch by James Cowgill adds mips64p32* to the size maps in the cgo tool. Bootstrapped on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (revision

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

On 06/20/2017 11:52 PM, Jeff Law wrote: > I've also wondered if a 2 page guard would solve some of these problems. > In the event of stack overflow, the kernel maps in one of the two pages > for use by the signal handler. But changing things at this point may > not be worth the effort. I think

Re: [PATCH] Fix -Wmaybe-uninitialized warning on sse.md (PR target/81151)

On Wed, Jun 21, 2017 at 8:27 PM, Jakub Jelinek wrote: > Hi! > > This expander has a gap in between the operands and match_dup indexes, > which results in genemit generating: > operand2 = operands[2]; > (void) operand2; > where operands[2] has not been initialized. > >

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

On 06/21/2017 02:41 AM, Richard Earnshaw (lists) 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

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

On 21 June 2017 16:07:29 CEST, "Tsimbalist, Igor V" wrote: >Thanks for the feedback. I'll redo the patch according to your >comments. what is "noni-tracking" ? Surplus i. "codegeneration" probably lacks a space. Thanks,

[committed] Fix ICE on OVERLOAD in OpenMP clauses (PR c++/81154)

Hi! tsubst_* ICEs when seeing an OVERLOAD that is dependent on template arguments. But if we see an OVERLOAD in an OpenMP data sharing/mapping clause, even when processing_template_decl we know that it won't be a variable, so we can as well diagnose it right away, without having to wait for the

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

On Wed, Jun 21, 2017 at 12:55:54PM -0500, Steven Munroe wrote: > > > I don't expect many different effective-target / dg-add-options keywords > > > to be needed for common tests (obviously, duplicating tests for each > > > architecture wanting these intrinsics is generally a bad idea). > > > >

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

Jeff Law wrote: > I'm a little confused.  I'm not defining or changing the ABI.  I'm > working within my understanding of the existing aarch64 ABI used on > linux systems.  My understanding after reading that ABI and the prologue > code for aarch64 is there's nothing that can currently be relied

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

On Tue, 2017-06-20 at 17:16 -0500, Segher Boessenkool wrote: > 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

[PATCH] Fix -Wmaybe-uninitialized warning on sse.md (PR target/81151)

Hi! This expander has a gap in between the operands and match_dup indexes, which results in genemit generating: operand2 = operands[2]; (void) operand2; where operands[2] has not been initialized. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

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

On 06/20/2017 04:20 PM, Eric Botcazou wrote: >> 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

Go patch committed: Better stack trace for `go f()` where f is nil

This Go frontend patch produces a better stack trace for `go f()` where f is nil. The test for this is TestGoNil in the runtime package, which we don't run yet but will run with a subsequent gotools patch. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian

libgo patch committed: Print "panic" rather than "runtime.gopanic"

This libgo patch changes tracebacks to print "panic" rather than "runtime.gopanic". Since the user's code calls "panic", this is generally clearer. The test for this is TestPanicTraceback in runtime/crash_test.go; we don't run it yet, but we will soon. Bootstrapped and ran Go testsuite on

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

Thanks for the feedback. I'll redo the patch according to your comments. Igor -Original Message- From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Tuesday, June 20, 2017 11:30 PM To: Tsimbalist, Igor V Cc: gcc-patches@gcc.gnu.org; Chupin, Pavel V

[RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

On Tue, Jun 20, 2017 at 10:18:20AM +0200, Richard Biener wrote: > > > > 3) not really related to this patch, but something I also saw during the > > > > bootstrap-ubsan on i686-linux: > > > > ../../gcc/bitmap.c:141:12: runtime error: signed integer overflow: > > > > -2147426384 - 2147475412

Re: [PATCH][AArch64] Fix atomic_cmp_exchange_zero_reg_1.c with +lse

On Wed, Jun 21, 2017 at 02:48:20PM +0100, Kyrill Tkachov wrote: > Hi all, > > As Andrew pointed out, the patch at r248921 > (https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01648.html) that allowed > const0_rtx as an argument to the compare-exchange patterns was incomplete. It > didn't extend the

Re: [PATCH, GCC/contrib] Fix variant selection in dg-cmp-results.sh

On Jun 21, 2017, at 8:30 AM, Thomas Preudhomme wrote: > > Commit r249422 to dg-cmp-results.sh broke the variant selection feature > 2017-06-21 Thomas Preud'homme > > * dg-cmp-results.sh: Restore filtering on target variant. >

[PATCH, GCC/contrib] Fix variant selection in dg-cmp-results.sh

Hi, Commit r249422 to dg-cmp-results.sh broke the variant selection feature where one can restrict the regression test to a specific target variant. This fix restores the feature. ChangeLog entry is as follows: *** contrib/ChangeLog *** 2017-06-21 Thomas Preud'homme

Re: [PATCH] [Aarch64] Variable shift count truncation issues

Michael Collison writes: > Updated the patch per Richard's suggestions to allow scheduling of > instructions before reload. Thanks, this looks good to me FWIW, but obviously I can't approve it. Richard > Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? >

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

On Tue, 2017-06-20 at 15:11 -0400, Jason Merrill wrote: > 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

Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

On Wed, Jun 21, 2017 at 04:40:01PM +0200, Jakub Jelinek wrote: > So, I wrote following patch to do the subtraction in unsigned > type. It passes bootstrap, but on both x86_64-linux and i686-linux > regresses: > +FAIL: gcc.dg/torture/pr66178.c -O* (test for excess errors) > +FAIL:

[PATCH] Implement cond and induction cond reduction w/o REDUC_MAX_EXPR

During my attempt to refactor reduction vectorization I ran across the special casing of inital values for INTEGER_INDUC_COND_REDUCTION and tried to see what it is about. So I ended up implementing cond reduction support for targets w/o REDUC_MAX_EXPR by simply doing the reduction in scalar code

[testsuite, committed] Fix warning in gcc.dg/tree-prof/comp-goto-1.c

Hi, this patch fixes a 'return type defaults to int' warning in test-case gcc.dg/tree-prof/comp-goto-1.c. Committed as obvious. Thanks, - Tom Fix warning in gcc.dg/tree-prof/comp-goto-1.c 2017-06-21 Tom de Vries * gcc.dg/tree-prof/comp-goto-1.c: Fix 'return type

[testsuite, committed] Support dg-add-options in profopt.exp

[ was: Re: [PATCH, testsuite] Add effective target stack_size ] On 06/21/2017 03:19 PM, Jakub Jelinek wrote: On Fri, Jun 09, 2017 at 04:24:30PM +0200, Tom de Vries wrote: * gcc.dg/tree-prof/comp-goto-1.c: Same. * gcc.dg/tree-prof/pr44777.c: Same. ---

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

On Wed, Jun 21, 2017 at 6:32 AM, Jakub Jelinek wrote: > The following patch fixes it by allowing that wording too on the line 10. > Is this ok for trunk or do you have some other preference? OK, thanks. Jason

Re: [PATCH, rs6000] Add vec_reve support

Hi Carl, On Tue, Jun 20, 2017 at 06:23:33PM -0700, Carl Love wrote: > * config/rs6000/rs6000-builtin.def (VREVE_V2DI, VREVE_V4SI, > VREVE_V8HI, VREVE_V16QI, VREVE_V2DF, VREVE_V4SF, VREVE): New "New." or "New builtin.". > * config/rs6000/altivec.md (UNSPEC_VREVEV, VEC_A_size, >

[Patch AArch64 / libstdc++] Update baseline symbols for aarch64-none-linux-gnu

Regenerate symbols file for aarch64-none-linux-gnu. Tested with make check in libstdc++ and eyeballing outputs. Applied as obvious. Tested on aarch64-none-linux-gnu with no issues in libstdc++ tests. regards Ramana * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate diff

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

On 06/20/2017 05:22 PM, Wilco Dijkstra wrote: > 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

Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998))

On Wed, 21 Jun 2017, Jakub Jelinek wrote: So, I wrote following patch to do the subtraction in unsigned type. It passes bootstrap, but on both x86_64-linux and i686-linux regresses: +FAIL: gcc.dg/torture/pr66178.c -O* (test for excess errors) +FAIL: gcc.dg/tree-ssa/cmpexactdiv-2.c

Re: [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

Hi, On 19 June 2017 at 11:32, Richard Earnshaw (lists) wrote: > On 16/06/17 15:56, Prakhar Bahuguna wrote: >> On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote: >>> On 16/06/17 08:48, Prakhar Bahuguna wrote: On 15/06/2017 17:23:43, Richard Earnshaw (lists)

Re: [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

Hi, On 19 June 2017 at 11:32, Richard Earnshaw (lists) wrote: > On 16/06/17 15:56, Prakhar Bahuguna wrote: >> On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote: >>> On 16/06/17 08:48, Prakhar Bahuguna wrote: On 15/06/2017 17:23:43, Richard Earnshaw (lists)