Re: [patch] Fix Unwind support on DragonFly BSD after sigtramp move

On 07/07/2017 05:17 PM, John Marino wrote: > Right after DragonFly 4.8 was released (27 Mar 2017), the signal > trampoline was moved (twice) in response to a Ryzen bug. This broke > GCC's unwind support for DragonFly. > > To avoid hardcoding the sigtramp location to avoid issues like this in >

[PATCH][RFA/RFC] Stack clash mitigation patch 03/08 V2 -- right patch attached

Opps, I clearly attached the wrong file. -- I don't think this patch changed in any significant way since V1. -- One of the painful aspects of all this code is the amount of target dependent bits that have to be written and tested. I didn't want to be scanning assembly code or RTL for

[PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2

This time with the patch attached. Forwarded Message Subject: [PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2 Date: Tue, 18 Jul 2017 23:17:23 -0600 From: Jeff Law To: gcc-patches The biggest change since V1 of this patch

[Bug libstdc++/81480] New: Assertion `ec' failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81480 Bug ID: 81480 Summary: Assertion `ec' failed Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[PATCH][RFA/RFC] Stack clash mitigation patch 08/08 V2

I don't think this patch has changed in any significant way since the V1 patch. I have tested a slightly different version which punts stack clash protection for very large static stack frames -- otherwise tests which have *huge* frames will timeout, run out of memory during compilation, etc. --

[PATCH][RFA/RFC] Stack clash mitigation patch 04/08 V2

I don't think this has changed in any significant way since V1. -- This patch introduces x86 target specific bits to mitigate stack clash attacks. The key differences relative to the -fstack-check=specific expander are that it never allocates more than PROBE_INTERVAL bytes at a time, it probes

[PATCH][RFA/RFC] Stack clash mitigation patch 07/08 V2

So this patch has changed considerably since V1 as well. First, we no longer track the bulk of the register stores in the prologue. Those may be separately shrink wrapped and thus not executed on all paths and as such are not candidates for implicit probes. Second, per the discussions we've

[PATCH][RFA/RFC] Stack clash mitigation patch 06/08 V2

These are the PPC bits for stack clash mitigation. As noted before the PPC bits were larger/more complex than other ports. Part of that was due to the PPC defining its own dynamic stack allocation expander -- which in turn means we weren't using any of the generic code in explow.c for stack

[PATCH][RFA/RFC] Stack clash mitigation patch 05/08

I don't think this has changed in any significant way since V1. -- The prior patch introduced -fstack-clash-protection prologues for the x86. And yet we still saw large allocations in our testing. It turns out combine-stack-adjustments would take allocate PROBE_INTERVAL probe allocate

[PATCH][RFA/RFC] Stack clash mitigation patch 03/08 V2

I don't think this patch changed in any significant way since V1. -- One of the painful aspects of all this code is the amount of target dependent bits that have to be written and tested. I didn't want to be scanning assembly code or RTL for prologues. Each target would have to have its own

[PATCH] [RFA/RFC] Stack clash mitigation patch 02/08 V2

The biggest change since V1 of this patch is dropping the changes to STACK_CHECK_MOVING_SP. They're not needed. This patch also refactors a bit of the new code in explow.c. In particular it pulls out 3 chunks of code for protecting dynamic stack adjustments so they can be re-used by backends

[PATCH][RFA/RFC] Stack clash mitigation patch 02b/08 V2

-fstack-clash-protection is now separate from -fstack-check=. But we still want targets without stack-clash specific prologue support to be able to get partial coverage from -fstack-clash-protection. This adds the necessary checks for flag_stack_clash_protection to the appropriate targets so we

[PATCH][RFA/RFC] Stack clash mitigation patch 01/08 V2

The biggest change in this update to patch 01/08 is moving of stack clash protection out of -fstack-check= and into its own option, -fstack-clash-protection. I believe other issues raised by reviewers have been addressed as well. -- This patch introduces a new option -fstack-clash-protection

[PATCH][RFA/RFC] Stack clash mitigation patch 00/08 V2

So later than I wanted, here's the V2 of the stack clash mitigation work. Probably the biggest change in this version was moving the protection out of -fstack-check= and into its own option (-fstack-clash-protection) This has been bootstrapped and regression tested on the same set of targets

Re: [PATCH] Fix pr80044, -static and -pie insanity, and pr81170

On Tue, Jul 18, 2017 at 07:49:48AM -0700, H.J. Lu wrote: > The difference is with --enable-default-pie, the gcc driver doesn't pass > both -pie and -static ld when "-static -pie" is used. Does your change > pass both -pie and -static ld when "-static -pie" is used? Again, as I said in the

Re: [PING} [PATCH] Transform (m1 > m2) * d into m1> m2 ? d : 0

Hi,   Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same.   https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00178.html Thanks, Naveen

Re: [PING 5] [PATCH] [AArch64] vec_pack_trunc_ should split after register allocator

Hi,   Please consider this as a personal reminder to review the patch at following link and let me know your comments on the same.  https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01334.html Thanks, Naveen    

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 --- Comment #2 from Sean McAllister --- *** Bug 81479 has been marked as a duplicate of this bug. ***

[Bug c++/81479] By default, GCC emits a function call for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81479 Sean McAllister changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 --- Comment #1 from Sean McAllister --- Created attachment 41785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41785=edit cfloat class

[Bug c++/81479] New: By default, GCC emits a function call for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81479 Bug ID: 81479 Summary: By default, GCC emits a function call for complex multiplication Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal

[Bug c++/81478] New: By default, GCC emits a function call for complex multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 Bug ID: 81478 Summary: By default, GCC emits a function call for complex multiplication Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

在 2017年07月19日 04:54, Trevor Saunders 写道: On Tue, Jul 18, 2017 at 03:52:55PM +0800, Leslie Zhai wrote: Hi Trevor, Thanks for your kind response! 在 2017年07月17日 19:51, Trevor Saunders 写道: On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote: PS: Trevor's email is not available?

Re: [PATCH] PR libstdc++/81395 fix crash when write follows large read

On 19/07/17 01:17 +0100, Jonathan Wakely wrote: This fixes a crash that happens in std::filebuf when a large read consumes the entire get area and is followed by a write, which is then synced to the file by a call to overflow. The problem is that xsgetn calls _M_set_buffer(0) after reading from

[PATCH] PR libstdc++/81395 fix crash when write follows large read

This fixes a crash that happens in std::filebuf when a large read consumes the entire get area and is followed by a write, which is then synced to the file by a call to overflow. The problem is that xsgetn calls _M_set_buffer(0) after reading from the file (i.e. when in 'read' mode). As the

[Bug libstdc++/81395] [5/6/7/8 Regression] basic_filebuf::overflow recurses and overflows stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Tue Jul 18 23:39:34 2017 New Revision: 250328 URL: https://gcc.gnu.org/viewcvs?rev=250328=gcc=rev Log: PR libstdc++/81395 fix crash when write follows large read PR

Go patch committed: Insert type conversion for closure function value

This patch by Than McIntosh changes the Go frontend, in Func_expression::do_get_backend, when creating the backend representation for a closure, to create a backend type conversion to account for potential differences between the closure struct type (where the number of fields is dependent on the

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jul 18 23:14:29 2017 New Revision: 250326 URL: https://gcc.gnu.org/viewcvs?rev=250326=gcc=rev Log: PR go/81451 runtime: inline runtime_osinit We had two

libgo patch committed: Inline runtime.osinit

Libgo had two identical copies of runtime_osinit. They set runtime_ncpu, a variable that is no longer used. Removing that leaves us with two lines. Inline those two lines in the two places the function was called. This fixes GCC PR 81451. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

gcc-5-20170718 is now available

Snapshot gcc-5-20170718 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170718/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5

Go patch committed: Pass correct 'function' flag to circular_pointer_type

The code in Named_type::do_get_backend in the Go frontend was not passing the correct flag value for circular function types to Backend::circular_pointer_type (it was always setting this flag to false). This patch by Than McIntosh passes a true value if the type being converted is a function type.

Re: [PATCH, rs6000] Rev 2, 1/2 Add x86 MMX <mmintrin,h> intrinsics to GCC PPC64LE target

Hi! On Mon, Jul 17, 2017 at 02:15:00PM -0500, Steven Munroe wrote: > Correct the problems Segher found in review and added a changes to deal > with the fallout from the __builtin_cpu_supports warning for older > distros. > > Tested on P8 LE and P6/P7/P8 BE. No new tests failures. > >

[Bug go/81324] libgo does not build with glibc 2.18

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81324 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH rs6000] Fix up BMI/BMI2 intrinsic DG tests

On Tue, 2017-07-18 at 16:54 -0500, Segher Boessenkool wrote: > Hi! > > On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote: > > After a resent GCC change the previously submitted BMI/BMI2 intrinsic > > test started to fail with the following warning/error. > > > >

[Bug go/81324] libgo does not build with glibc 2.18

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81324 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jul 18 22:06:31 2017 New Revision: 250324 URL: https://gcc.gnu.org/viewcvs?rev=250324=gcc=rev Log: PR go/81324 sysinfo.c: ignore ptrace_peeksiginfo_args from

libgo patch committed: Ignore ptrace_pseeksiginfo_args from

This patch should fix PR 81324 filed against libgo. With some versions of glibc and GNU/Linux ptrace_pseeksiginfo_args is defined in both and . We don't actually care about the struct, so use a #define to avoid a redefinition error. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

Re: [PATCH rs6000] Fix up BMI/BMI2 intrinsic DG tests

Hi! On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote: > After a resent GCC change the previously submitted BMI/BMI2 intrinsic > test started to fail with the following warning/error. > > ppc_cpu_supports_hw_available122373.c: In function 'main': >

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jul 18 21:44:03 2017 New Revision: 250322 URL: https://gcc.gnu.org/viewcvs?rev=250322=gcc=rev Log: PR target/81471 * config/i386/i386.md

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

On Tue, Jul 18, 2017 at 03:52:55PM +0800, Leslie Zhai wrote: > Hi Trevor, > > Thanks for your kind response! > > 在 2017年07月17日 19:51, Trevor Saunders 写道: > > On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote: > > > PS: Trevor's email is not available? thanks! > > Sorry about that, I've

[PATCH], Update cpu-builtin-1.c test on PowerPC

This patch modifies the change I made on July 12th. It modifies the test for the __builtin_cpu_is and __builtin_cpu_supports built-in functions to use an #ifdef instead of target-requires for doing the tests. One motavation is to make the back port to GCC 6/7 easier, as I won't have to back port

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jul 18 20:16:47 2017 New Revision: 250319 URL: https://gcc.gnu.org/viewcvs?rev=250319=gcc=rev Log: PR target/81471 * config/i386/i386.md

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL|

[Bug sanitizer/78654] ubsan can lead to excessive stack usage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug sanitizer/55316] gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error "Unsupported arch"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55316 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug sanitizer/61693] [asan] is not intercepting aligned_alloc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693 Yury Gribov changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|

[Bug sanitizer/63245] renderMemorySnippet shouldn't show more bytes than the underlying type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63245 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug middle-end/41992] ICE on invalid dereferencing of void *

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992 Yury Gribov changed: What|Removed |Added Status|NEW |RESOLVED CC|

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

* Jeff Law: > On 06/28/2017 12:45 AM, Florian Weimer wrote: >> * Richard Earnshaw: >> >>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt >>> going on here. As Wilco points out, we can never defend against a >>> function that is built without probe operations but skips

Re: [PATCH 4/6] lra-assigns.c: give up on qsort checking in assign_by_spills

On Sat, Jul 15, 2017 at 9:47 PM, Alexander Monakov wrote: > The reload_pseudo_compare_func comparator, when used from assign_by_spills, > can be non-transitive, indicating A < B < C < A if both A and C satisfy > !bitmap_bit_p (_reload_pseudos, rAC), but B does not. > > This

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 Yury Gribov changed: What|Removed |Added Target Milestone|--- |6.0

[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 Yury Gribov changed: What|Removed |Added Target Milestone|--- |4.9.0

[PATCH 2/2] combine: Fix for PR81423

We here have an AND of a SUBREG of an LSHIFTRT. If that SUBREG is paradoxical, the extraction we form is the length of the size of the inner mode, which includes some bits that should not be in the result. Just give up in that case. Tested on powerpc64-linux {-m32,-m64} and on x86_64-linux.

[PATCH 1/2] simplify-rtx: The truncation of an IOR can have all bits set (PR81423)

... if it is an IOR with a constant with all bits set in the mode that is truncated to, for example. Handle that case. With this patch the problematic situation for the PR81423 testcase isn't even reached; but the next patch fixes that anyway. Bootstrapped and tested on powerpc64-linux

[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 ygribov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to

[Bug middle-end/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Component|web

Re: [PATCH, PR81464] Handle equal-argument loop exit phi in expand_omp_for_static_chunk

On 07/18/2017 06:59 PM, Jakub Jelinek wrote: On Tue, Jul 18, 2017 at 06:48:56PM +0200, Tom de Vries wrote: Hi, this patch fixes PR81464, an ICE in ompexpssa. The ICE occurs in expand_omp_for_static_chunk when we're trying to fix up a loop exit phi: ... # .MEM_88 = PHI <.MEM_86(46),

Re: [PATCH] PR libstdc++/81064 fix versioned namespace

On 18/07/2017 16:03, Ville Voutilainen wrote: On 18 July 2017 at 16:31, Jonathan Wakely wrote: This is quite a huge change, so I'd like to wait and see if anyone else has any opinion on it. Personally I think it's necessary (assuming I understand the PR correctly) and so

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jul 18 18:28:12 2017 New Revision: 250317 URL: https://gcc.gnu.org/viewcvs?rev=250317=gcc=rev Log: PR target/81471 * config/i386/i386.md

Re: [PATCH] Kill TYPE_METHODS debug 1/9

On 07/14/2017 09:48 AM, Nathan Sidwell wrote: This changes dbxout and dwarf2out. Oh, the patch series survived a bootstrap on x86_64-linux. Changes to the debug info files requires a gdb make check with and without the patch to check for regressions. Since you are changing both dbxout

Re: [PATCH 1/3] matching tokens: c-family parts

On Tue, Jul 11, 2017 at 11:24:43AM -0400, David Malcolm wrote: > OK for trunk? (assuming the rest is approved) This is ok. I'll have to play with this some more before I approve the C part. Thanks, Marek

Re: [PATCH] match.pd: reassociate multiplications with constants

On Mon, 17 Jul 2017, Alexander Monakov wrote: > On Mon, 17 Jul 2017, Marc Glisse wrote: > > > +/* Combine successive multiplications. Similar to above, but handling > > > + overflow is different. */ > > > +(simplify > > > + (mult (mult @0 INTEGER_CST@1) INTEGER_CST@2) > > > + (with { > > > +

Re: [PATCH, PR81464] Handle equal-argument loop exit phi in expand_omp_for_static_chunk

On Tue, Jul 18, 2017 at 06:48:56PM +0200, Tom de Vries wrote: > Hi, > > this patch fixes PR81464, an ICE in ompexpssa. > > The ICE occurs in expand_omp_for_static_chunk when we're trying to fix up a > loop exit phi: > ... > # .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)> > ... That is something

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, Jul 18, 2017 at 10:47:37AM -0600, Martin Sebor wrote: > On 07/18/2017 09:43 AM, Jakub Jelinek wrote: > > On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote: > > > > --- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200 > > > > +++ gcc/match.pd2017-07-18

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW Component|c++

[Bug web/81464] [8 Regression] ICE in expand_omp_for_static_chunk, at omp-expand.c:4236

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81464 Tom de Vries changed: What|Removed |Added Keywords||patch Component|middle-end

[PATCH, PR81464] Handle equal-argument loop exit phi in expand_omp_for_static_chunk

Hi, this patch fixes PR81464, an ICE in ompexpssa. The ICE occurs in expand_omp_for_static_chunk when we're trying to fix up a loop exit phi: ... # .MEM_88 = PHI <.MEM_86(46), .MEM_86(71)> ... It's a loop exit phi with equal arguments, which means that the variable has the same value when

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #8 from Alexander Monakov --- Yeah, the target.insert(target.cbegin(), ranges::begin(concatenated), ranges::end(concatenated)); appears to cause a bad case of Schlemiel-The-Painter, for each inserted char the tail of target is

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On 07/18/2017 09:43 AM, Jakub Jelinek wrote: On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote: --- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200 +++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200 @@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)

Bug in lto-plugin.c ?

Hi, I tried to build a canadian cross with Configured with --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=avr While the result appears to work under wine, I am getting the following error from ld in a non-LTO compile + link:

Re: [PATCH] Add self as maintainer of D front-end and libphobos

On Thu, 13 Jul 2017, Iain Buclaw wrote: >> As per message on the D language being accepted, this adds myself as a >> maintainer of the D front-end and libphobos runtime library. > I may have to request a ping here. I would commit this when the first bits of D go in. (Technically you could

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #7 from Markus Trippelsdorf --- Ah: - 99.79% 0.02% a.out a.out[.] std::vector::_M_range_insert

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org ---

[PATCH, i386]: Fix PR 81471, ICE in curr_insn_transform

Hello! Attached patch tightens rorx operand 2 predicate to allow only const_int RTXes that are also allowed by the operand constraint. This prevents combine to propagate unsupported const_ints to the pattern. 2017-07-18 Uros Bizjak PR target/81471 *

[Bug target/81471] [5/6/7/8 Regression] internal compiler error: in curr_insn_transform, at lra-constraints.c:3495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81471 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Tue Jul 18 16:10:20 2017 New Revision: 250315 URL: https://gcc.gnu.org/viewcvs?rev=250315=gcc=rev Log: PR target/81471 * config/i386/i386.md

[PATCH] Fix infinite recursion with div-by-zero (PR middle-end/70992)

We ended up in infinite recursion between extract_muldiv_1 and fold_plusminus_mult_expr, because one turns this expression into the other and the other does the reverse: ((2147483648 / 0) * 2) + 2 <-> 2 * (2147483648 / 0 + 1) I tried (unsuccessfully) to fix it in either extract_muldiv_1 or

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, 18 Jul 2017, Jakub Jelinek wrote: On Tue, Jul 18, 2017 at 05:35:54PM +0200, Marc Glisse wrote: On Tue, 18 Jul 2017, Jakub Jelinek wrote: In the PR Marc noted that the optimization might be useful even for constants other than 1, by transforming x+C1 <= C2 if unsigned and

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81281 --- Comment #3 from Marek Polacek --- Before that rev we had int a = (int) (unsigned int) ll - (unsigned int) ci) - (unsigned int) i) + unsigned int) ci - (unsigned int) ll) + (unsigned int) i) - (unsigned int) ci)) + 2270794745); and

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #5 from Hannes Hauswedell --- > Please clarify if the problem is in compilation time (how long the compiler > takes to compile the file), or in performance of generated code. Performance of code. > Please

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, Jul 18, 2017 at 05:35:54PM +0200, Marc Glisse wrote: > On Tue, 18 Jul 2017, Jakub Jelinek wrote: > > > In the PR Marc noted that the optimization might be useful even for > > constants other than 1, by transforming > > x+C1 <= C2 if unsigned and C2-C1==INT_MAX into (int)x > (int)(-1-C1).

Re: [PATCH][RFA/RFC] Stack clash mitigation 0/9

On 07/13/2017 03:26 AM, Christophe Lyon wrote: > I have executed a validation of your patch series on aarch64 and arm > targets, and I have minor comments. > > On arm, all new tests are unsupported, as expected. Good. > On aarch64-linux, the new tests pass, but they fail on aarch64-elf: > -

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #4 from Hannes Hauswedell --- Created attachment 41783 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41783=edit intermediate code

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, Jul 18, 2017 at 09:31:11AM -0600, Martin Sebor wrote: > > --- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200 > > +++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200 > > @@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > > && wi::neg_p (@1, TYPE_SIGN (TREE_TYPE

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81281 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

On Tue, 18 Jul 2017, Jakub Jelinek wrote: In the PR Marc noted that the optimization might be useful even for constants other than 1, by transforming x+C1 <= C2 if unsigned and C2-C1==INT_MAX into (int)x > (int)(-1-C1). (int)x >= (int)(-C1) might be easier (and more valid, except that the

Re: Killing old dead bugs

On 18 July 2017 at 16:32, Yuri Gribov wrote: > Jonathan also mentioned something not immediately obvious in IRC: > logging into BZ with gcc.gnu.org account provides elevated privileges. > So if you have write access, you should get extra BZ rights for free. We should document this at

Re: [PATCH] Move fold_div_compare optimization to match.pd (PR tree-optimization/81346)

On Tue, Jul 18, 2017 at 05:21:42PM +0200, Marc Glisse wrote: > On Tue, 18 Jul 2017, Jakub Jelinek wrote: > > > +/* X / C1 op C2 into a simple range test. */ > > +(for cmp (simple_comparison) > > + (simplify > > + (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2) > > + (if (INTEGRAL_TYPE_P

[Bug c++/81476] severe slow-down with range-v3 library compared to clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476 --- Comment #2 from Andrew Pinski --- For clang are you using GCC's libstdc++ or llvm's libc++?

[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #9 from Carl Love --- Commit 250295 reverts commit 249424 which was causing issues. commit 249424 is actually a fix for the vec_mule and vec_mulo support that was added in commit 248125. The original commit was using the wrong word

Re: Killing old dead bugs

On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote: > On 07/17/2017 02:25 PM, Yuri Gribov wrote: >> >> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote: >>> >>> On 07/17/2017 02:14 AM, Yuri Gribov wrote: Hi Mikhail, On Sun, Jul 2,

Re: [PATCH] Implement one optimization from build_range_check in match.pd (PR tree-optimization/81346)

--- gcc/match.pd.jj 2017-07-17 16:25:20.0 +0200 +++ gcc/match.pd2017-07-18 12:32:52.896924558 +0200 @@ -1125,6 +1125,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) && wi::neg_p (@1, TYPE_SIGN (TREE_TYPE (@1 (cmp @2 @0)) +/* (X - 1U) <= INT_MAX-1U into (int) X

[Bug hsa/81477] New: HSA offloading regressions: "function cannot be cloned"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81477 Bug ID: 81477 Summary: HSA offloading regressions: "function cannot be cloned" Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: openmp

Re: [PATCH] Move fold_div_compare optimization to match.pd (PR tree-optimization/81346)

On Tue, 18 Jul 2017, Jakub Jelinek wrote: +/* X / C1 op C2 into a simple range test. */ +(for cmp (simple_comparison) + (simplify + (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2) + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) + && integer_nonzerop (@1) + && !TREE_OVERFLOW (@1) +

[PATCH] Rename TYPE_{MIN,MAX}VAL

As I mentioned in my previous patch, we currently have TYPE_{MIN,MAX}_VALUES for numeric types and TYPE_{MIN,MAX}VAL for type-agnostic access. This patch renames the latter to TYPE_{MIN,MAX}VAL_RAW, matching TYPE_VALUES_RAW, which had a similar problem. While renaming the macros, I

[Bug other/67552] [meta-bug] x86 interrupt attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/66960] Add interrupt attribute to x86 backend

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

  1   2   3   >