Re: libgo: update to Go 1.8.1

On Mon, Apr 17, 2017 at 3:11 PM, Ian Lance Taylor wrote: > This patch to libgo updates it to the Go 1.8.1 release. Bootstrapped > and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. As a followup I updated gcc-7/changes.html on the web page as appended. Ian

libgo: update to Go 1.8.1

This patch to libgo updates it to the Go 1.8.1 release. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: libgo/MERGE === --- libgo/MERGE (revision 246951) +++ libgo/MERGE (working copy) @@

Re: port contrib/download_prerequisites script to macOS

On 04/13/2017 05:29 PM, Damian Rouson wrote: Resending as plain text: On April 12, 2017 at 3:03:19 PM, Jeff Law (l...@redhat.com(mailto:l...@redhat.com)) wrote: > > > > 2017-04-05 Damian Rouson > > > > * download_prerequisites (md5_check): New function emulates Linux > > 'md5 --check'

Re: [PATCH] Fix a C++ crash with may_alias type attribute

OK. On Tue, Apr 4, 2017 at 10:34 PM, Bernd Edlinger wrote: > On 04/05/17 00:33, Ville Voutilainen wrote: >> On 5 April 2017 at 00:29, Bernd Edlinger wrote: The new test doesn't really belong in the libstdc++, does it? If this

Re: C++ PATCH for c++/80241, ICE with alignas pack expansion

OK. On Thu, Mar 30, 2017 at 2:26 PM, Marek Polacek wrote: > This fix is similar to c++/79653: if something went wrong during > make_pack_expansion, return error_mark instead of building up the attribute > otherwise we end up with "gnu aligned <<>>" and that would mean >

Re: C++ PATCH for c++/80244, ICE with attribute in template alias

OK. On Wed, Apr 5, 2017 at 5:37 PM, Marek Polacek wrote: > We crashed on this testcase because UNDERLYING_TYPE, a C++-specific code, > got into layout_type. It wound up there via strip_typedefs -> ... -> > build_type_attribute_qual_variant and that calls type_hash_canon

Re: [PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 04/17/2017 09:57 AM, Denys Vlasenko wrote: Index: gcc/doc/invoke.texi === --- gcc/doc/invoke.texi (revision 246948) +++ gcc/doc/invoke.texi (working copy) @@ -351,9 +351,11 @@ Objective-C and Objective-C++ Dialects}. @item

C++ PATCH for variadic initialization bug

When a variable with a pack expansion initializer expands to a null list, we build a value-initialization to use for initializing that variable. We need to mark it as direct-initialization to avoid problems with move-only types. Tested x86_64-pc-linux-gnu, applying to trunk. commit

Re: [PR 80293] Don't totally-sRA char arrays

Hi, On Thu, Apr 13, 2017 at 08:48:38PM +0200, Richard Biener wrote: > On April 13, 2017 7:41:29 PM GMT+02:00, Martin Jambor wrote: > >Hi, > > > >On Wed, Apr 12, 2017 at 01:55:01PM +0200, Richard Biener wrote: > >> On Wed, 12 Apr 2017, Martin Jambor wrote: > >> > >> > Hi, > >> >

C++ PATCH for c++/80415, wrong error with default arg and array reference

Here, converting the default argument to the array type produces a typed CONSTRUCTOR, which we later fail to bind directly to the reference parameter. We should treat this kind of array prvalue the same way we do class prvalues. Tested x86_64-pc-linux-gnu, applying to trunk. commit

Re: Slow compile - find_symtree_for_symbol()

No problem - I'm making use of the faster compile times already! Cheers, Andrew On Monday, April 17, 2017 7:23:29 PM PDT Paul Richard Thomas wrote: > Committed as revision 246952. > > Thanks for finding this deadwood. > > Cheers > > Paul > > On 16 April 2017 at 20:18, Janus Weil

Re: Slow compile - find_symtree_for_symbol()

Committed as revision 246952. Thanks for finding this deadwood. Cheers Paul On 16 April 2017 at 20:18, Janus Weil wrote: > Hi Paul, > >> Prompted by this thread, I have just tried eliminating the call and >> the function altogether. No problem, the regtesting went through

[RFA][PATCH] Fix mips16 codegen issue in a better way

[RFA is for the regcprop bits, reverting the mips.md hack seems like a no-brainer with the regcprop change. ] Per the recent discussion between Richard S. and myself, this is a better fix for the mips16 codegen issue where it's creating invalid lwu insns. As Richard S. pointed out

[RFA][PATCH][P2][PR middle-end/80422] Fix crossjumping ICE

A forwarder block becomes unreachable during cfg_cleanup. Later we're cross jumping an indirect (via more forwarders) successor of the now unreachable forwarder and walk up the CFG looking for hunks of equivalent insns and walk back into the unreachable forwarder block. We then want to

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

falign-functions=N is too simplistic. Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte alignment of functions runs fastest (he tried many other possibilites): this way, after a call CPU can fetch a lot of insns in the first cacheline fill. However, developers are less

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

This change drops forced alignment to 8 if requested alignment is higher than 8: before the patch, -falign-functions=9 was generating .p2align 4,,8 .p2align 3 which means: "align to 16 if the skip is 8 bytes or less; else align to 8". After this change, ".p2align 3" is not

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2016-09-27 Denys Vlasenko * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-common.c

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 7

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" An extended explanation is in commit message of patch 3. The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1;

Re: [PATCH, gfortran] Cleanup the submodule tests

On Sun, Apr 16, 2017 at 10:13:07PM +0200, Janus Weil wrote: > > if {![string match "" $tmp]} { > > foreach i $tmp { > > - regexp "(\[0-9\]+)\[ \t\]+(?:(?:#)?\[ \t\]*include\[ > > \t\]+)\[\"\](\[^\"\]*)\[\"\]" $i dummy lineno include_file > > + regexp -nocase > >

[Patch, Fortran, OOP] PR 80392: [5/6/7 Regression] ICE with allocatable polymorphic function result in a procedure pointer component

Hi all, the attached patch fixes an ICE-on-valid regression, where the compiler runs into an infinite loop if a derived type contains a procedure-pointer component which has a polymorphic result of the original type. We already have a piece of code which prevents the infinite loop for