Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

On Thu, May 1, 2014 at 6:42 AM, Wei Mi wrote: > Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk? None of these patches have correct ChangeLog entries. Please follow the rules, outlined in http://gcc.gnu.org/contribute.html (Submitting Patches section), otherwise your patches will be simp

Re: [Patch] Simple change to include/longlong.h to quiet warnings.

"Steve Ellcey " writes: > I would like to make a small change to include/longlong.h for glibc but > I undertand that the GCC version of this file is the master one and > should be changed first, is that right? The copyright says: This file is part of the GNU C Library. but maybe that isn't t

Re: [PATCH] Builtins handling in IVOPT

Ping. Thanks, Wei. On Tue, Dec 17, 2013 at 11:34 AM, Wei Mi wrote: > Ping. > > Thanks, > Wei. > > On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi wrote: >> Ping. >> >> Thanks, >> wei. >> >> On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote: >>> bootstrap and regression of the updated patch pass. >>> >>> O

Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk? Thanks, Wei. >> I attached the patch which combined your two patches and the fix in >> legitimize_tls_address. I tried pr58066.c and c.i in ia32/x32/x86_64, >> the code looked fine. Do you think it is ok? >> >> Thanks, >> Wei. > > Either p

[PATCH] gengtype: Support explicit pointers in template arguments

Currently, gengtype does not support template arguments that are explicitly pointers, such as: static GTY(()) vec test_gimple; giving this error: ../../src/gcc/gimple-expr.c:902: parse error: expected a string constant or ',', have '*' instead requiring them to be typedefs. This patch remove

Go patch committed: Use backend interface for error detection

This patch from Chris Manghane changes the Go frontend to use the backend interface to detect whether any errors have been seen. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2014-04-30 Chris Manghane * go-backend.c: #include "diagnostics.h

libgo patch committed: Use $GOC for compiler characteristics

This patch from Peter Collingbourne changes the libgo configury and make to test $GOC (the target gccgo) for compiler characteristics rather than $CC. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 703f1d4d9227 libgo/Makefile.am --- a/libgo/Mak

Re: [Patch] Simple change to include/longlong.h to quiet warnings.

On Wed, Apr 30, 2014 at 4:22 PM, Steve Ellcey wrote: > > I would like to make a small change to include/longlong.h for glibc but > I undertand that the GCC version of this file is the master one and > should be changed first, is that right? GCC version is not the master either. GMP has the maste

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

On Wed, Apr 30, 2014 at 11:18:18AM +0200, Richard Biener wrote: > On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis > wrote: > >> ISTR we went to typed allocs as part of a transition which not > >> fully materialised? > > > > Yes. I had plans to replace the call-based GC marker routines with a >

[Patch] Simple change to include/longlong.h to quiet warnings.

I would like to make a small change to include/longlong.h for glibc but I undertand that the GCC version of this file is the master one and should be changed first, is that right? My change is to check __mips16 with "defined (__mips16)" instead of just "__mips16" so that we don't get a warning w

Re: [PATCH][RFC] Always require a 64bit HWI

On 30-Apr-14, at 4:16 AM, Richard Biener wrote: Testing coverage for non-64bit hwi configs is really low these days (I know of only 32bit hppa-*-* that is still built and tested semi-regularly - Dave, I suppose the host compiler has a 64bit long long type there, right?). I'm OK with this chang

Re: Warn when returning the address of a temporary (middle-end)

On Sat, 5 Apr 2014, Marc Glisse wrote: > One hard part is avoiding duplicate warnings. Replacing the address with 0 is > a convenient way to do that, so I did it both for my new warning and for the > existing C/C++ ones. The patch breaks gfortran.dg/warn_target_lifetime_2.f90 That's not safe the

[PATCH, libgfortran] Use -std=gnu11

Hello, the attached patch switches libgfortran C sources to be compiled in gnu11 mode instead of gnu99. As the 4.9 release notes http://gcc.gnu.org/gcc-4.9/changes.html say, "ISO C11 support is now at a similar level of completeness to ISO C99 support: substantially complete modulo bugs, extended

Re: wide-int testing, go bits

On Wed, Apr 30, 2014 at 1:31 PM, Mike Stump wrote: > > I am seeing the below on wide-int. The go teststsuite violates one of the > principals of goo test suite hygiene, the names thought arbitrary, should be > stable. These names are not stable across differing build locations. > s,.*/testsu

Re: [PATCH 00/89] Compile-time gimple-checking

On 04/23/14 08:32, Richard Biener wrote: Also I see you introduce a const_FOO class with every FOO one. I wonder whether, now that we have C++, can address const-correctness in a less awkward way than with a typedef. Can you try to go back in time and see why we did with that in the first place

Re: [C PATCH] Add -Wdiscarded-qualifiers (PR c/43245)

On 04/29/14 15:20, Marek Polacek wrote: I think we should have an option to turn off various "discards qualifier" warnings (only for C), or to make them hard errors. This patch adds new option, called -Wdiscarded-qualifiers (as suggested in the BZ) for that. Regtested/bootstrapped on x86_64-linu

Re: [C PATCH] Improve error on attrs after declarator in a fndef (PR c/60915)

On 04/24/14 08:31, Marek Polacek wrote: This PR is about not very clear error message when one tries to add attributes *after* the declarator in a function definition. cc1plus already handles this well, so I used the same message. Regtested/bootstrapped on x86_64-linux, ok for trunk? 2014-04-24

Re: [C PATCH] Another locus improvements (PR c/60257)

On 04/26/14 03:15, Marek Polacek wrote: Another column info improvements, this time for initializer warnings. warning_init and add_pending_init had to gain new location parameter. What is worth mentioning is that the "(near initialization for X)" message seems next to useless to me now with car

Re: [PATCH] New target hook: keep_leaf_when_profiled

On 04/30/14 08:15, Andreas Krebbel wrote: On Wed, Apr 30, 2014 at 12:18:08PM +0200, Steven Bosscher wrote: On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote: diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index b8ca17e..937c2d5 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -4953,6

Re: [C PATCH] Improve warn msg (PR c/43395)

On 04/29/14 15:17, Marek Polacek wrote: It's correct to warn about returning an address of a local label, but it's clumsy to say it's "local variable. We can easily distinguish between a label and a variable. Regtested/bootstrapped on x86_64-linux, ok for trunk? 2014-04-29 Marek Polacek

Re: [C PATCH] Warn about booleans in C89 mode (PR c/29467)

On 04/29/14 15:18, Marek Polacek wrote: Boolean types were introduced with the advent of C99, which means we should pedwarn when _Bool is used in ansi/c89/c90/iso9899:1990 mode with -Wpedantic, similarly what we do for _Complex. We don't warn for system headers, so it's possible to include and t

Re: [C PATCH] Another column info tweak (PR c/56989)

On 04/29/14 15:19, Marek Polacek wrote: At least for function calls we can use their location info to generate better diagnostics. Regtested/bootstrapped on x86_64-linux, ok for trunk? 2014-04-29 Marek Polacek PR c/56989 * c-typeck.c (default_conversion): Use better location

Re: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c

On 04/25/14 03:16, Dhakshinamoorthy, Soundararajan wrote: 2014-04-25 Soundararajan Dhakshinamoorthy * gcc.c-torture/execute/pr58419.c: Adjust the test to work with bare metal targets. The test code references to functions that is not implemented for the avr target (getpid(

Re: [PATCH] A new reload-rewrite pattern recognizer for GCC vectorizer.

Thank you for reminding me the omp possibility. Yes, in this case my pattern is incorrect, because I assume all aliases will be resolved by alias checks, which may not be true with omp. LOOP_VINFO_NO_DATA_DEPENDENCIES or LOOP_REQUIRES_VERSIONING_FOR_ALIAS may not help here because vect_pattern_rec

Go patch committed: Remove GCC langhooks from Go frontend

This patch from Chris Manghane removes the GCC langhooks from the Go frontend. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2014-04-30 Chris Manghane * go-lang.c (go_langhook_type_for_size): Do it here, rather than calling into G

[aarch64] Remove aarch64_function_profiler prototype

aarch64_function_profiler was removed in rev203028 but the prototype was left behind. If OK, can someone apply? Thanks. Regards, Ryan Mansfield 2014-04-30 Ryan Mansfield * config/aarch64/aarch64-protos.h (aarch64_function_profiler): Remove. Index: config/aarch64/aarch64-protos.

Re: Changes for if-convert to recognize simple conditional reduction.

On Wed, Apr 30, 2014 at 8:50 AM, Yuri Rumyantsev wrote: > Thanks a lot Richard for you review. > I did all proposed changes, checked that bootstrap and regression > testing did not show new failures. > Updated patch is attached. > Does this help http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21998

Re: [PATCH][RFC] Always require a 64bit HWI

On 4/30/2014 12:00 PM, Jeff Law wrote: My recollection is that HP aCC supports long long, but I don't recall when support for that was introduced. I'm really trying hard to forget hpux-isms. Plus, they can always start the bootstrapping process with GCC 4.9. I can't remember but without ans

Go patch committed: Use backend interface for built-in functions

This patch from Chris Manghane changes the Go frontend to use the backend interface for built-in functions. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2014-04-30 Chris Manghane * go-gcc.cc: #include "langhooks.h". (Gcc_backend:

Re: [PATCH][RFC] Always require a 64bit HWI

On 04/30/14 02:16, Richard Biener wrote: On Tue, 29 Apr 2014, Jeff Law wrote: On 04/29/14 05:21, Richard Biener wrote: The following patch forces the availability of a 64bit HWI (without applying the cleanups that result from this). I propose this exact patch for a short time to get those th

Re: Changes for if-convert to recognize simple conditional reduction.

Thanks a lot Richard for you review. I did all proposed changes, checked that bootstrap and regression testing did not show new failures. Updated patch is attached. Best regards. Yuri. 2014-04-30 16:40 GMT+04:00 Richard Biener : > On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev wrote: >> 2014-0

Re: [wide-int] fix 32-bit x86 builds

Mike Stump writes: > We changed the underlying type a while back, and it matters on 32-bit > pointer machines that use long long for a HOST_WIDE_INT… Caught by > fold-checking, thanks fold checking. > > This is the tree-vrp problem, I think this was seen on arm as well. Trivial follow-up to keep

[patch] fix ppc spe bootstrap error in dwf_regno

I've been working on a patch to switch a few ppc targets to use softfp in libgcc instead of fpbit and I noticed that ppc-none-eabispe fails to bootstrap in both trunk and 4.9. The regression was introduced in . Essentially, the assert for a h

Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC

On Wed, Apr 30, 2014 at 07:56:07AM +0200, Marc Glisse wrote: > Minor detail: > > + if ((flags & OPTION_MASK_FLOAT128) != 0) > +rs6000_define_or_undefine_macro (define_p, "__FLOAT128__"); > > I recently added __SIZEOF_FLOAT128__ to the x86 target to advertise > the availability of __float128,

Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.

Ping. On Fri, Apr 18, 2014 at 2:05 PM, Evgeny Stupachenko wrote: > Hi, > > Merged with current master the patch passes bootstrap and is giving > expected gains. > Patch and new tests are attached. > > ChangeLog: > > 2014-04-18 Evgeny Stupachenko > > * tree-vect-data-refs.c (vect_groupe

Re: [PATCH 2/2, x86] Add palignr support for AVX2.

On Tue, Apr 29, 2014 at 9:39 PM, Richard Henderson wrote: > On 04/29/2014 10:13 AM, Evgeny Stupachenko wrote: >> + /* For a rotaion permutation with one operand like: {5 6 7 0 1 2 3 4} >> + PALIGNR is better than PSHUFB. Check for a rotation in permutation. >> */ >> + for (i = 0; i < nelt

C++ PATCH for c++/60980 (value-initialization of array member)

My change to handle trivial but not callable constructors mistakenly removed the check that an object is of class type before we try to call its constructor. Tested x86_64-pc-linux-gnu, applying to trunk and 4.9. commit 3635dadac4d1e507b80f21f673530f322752df9b Author: Jason Merrill Date: Tue

C++ PATCH for c++/60951 (ICE with constexpr and aggregate init)

I'm not sure why I changed the use of maybe_constant_init to maybe_constant_value when I added the call to fold_non_dependent_expr_sfinae. And that caused this problem, so I'm changing it back. Tested x86_64-pc-linux-gnu, applying to trunk and 4.9. commit f103a8af382f2dcb3022cdbefa18b96361221

Re: [PATCH] New target hook: keep_leaf_when_profiled

On Wed, Apr 30, 2014 at 12:18:08PM +0200, Steven Bosscher wrote: > On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote: > > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi > > index b8ca17e..937c2d5 100644 > > --- a/gcc/doc/tm.texi > > +++ b/gcc/doc/tm.texi > > @@ -4953,6 +4953,10 @@ Define this

[committed] Remove W_TYPE_SIZE==64 handling for i386

Using longlong.h for wide-int.cc failed on 32-bit x86 because the 64-bit x86_64 patterns were being defined for i386 too. Specifically: #define umul_ppmm(w1, w0, u, v) \ __asm__ ("mul{q} %3" \ : "=a" ((UDItype) (w0)),

[PING] [PATCH, FORTRAN] Fix PR fortran/60718

Ping... > Date: Tue, 15 Apr 2014 13:49:37 +0200 > > Hi Tobias, > > On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote: >> >> Hi Tobias, >> >> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: >>> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: >>> Hmm, >>> >>> I was hoping somehow

RE: [PATCH] Work around for current Cygwin-32 Build problems

Opps... this time with the attachment. > > Hi Rainer, > > > > On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: >> >> Bernd Edlinger writes: >> >>> 2014-04-30 Bernd Edlinger >>> >>> Work around for current cygwin32 build problems (Bug gas/16858). >>> * config/i386/cygming-crtbegin.c (__register_

RE: [PATCH] Work around for current Cygwin-32 Build problems

Hi Rainer, On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: > > Bernd Edlinger writes: > >> 2014-04-30 Bernd Edlinger >> >> Work around for current cygwin32 build problems (Bug gas/16858). >> * config/i386/cygming-crtbegin.c (__register_frame_info, >> __deregister_frame_info, _Jv_RegisterClass

RE: [PATCH, MIPS] Alter default number of single-precision registers

Richard Sandiford writes: > -march is "which instructions can I use?" and -mtune is "which > instructions > give good performance?". My understanding is that you wanted to disable > the instructions for mips32r2 etc. so that they can be safely linked > with loongson3a code, in which case it's an

Re: Changes for if-convert to recognize simple conditional reduction.

On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev wrote: > 2014-04-28 16:16 GMT+04:00 Richard Biener : >> On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev wrote: >>> Hi All, >>> >>> We implemented enhancement for if-convert phase to recognize the >>> simplest conditional reduction and to transform

Re: [PATCH] Work around for current Cygwin-32 Build problems

Bernd Edlinger writes: > 2014-04-30 Bernd Edlinger > > Work around for current cygwin32 build problems (Bug gas/16858). > * config/i386/cygming-crtbegin.c (__register_frame_info, > __deregister_frame_info, _Jv_RegisterClasses): Compile weak default > functions only for

Re: [PATCH] Work around for current Cygwin-32 Build problems

2014-04-30 14:01 GMT+02:00 Bernd Edlinger : > Hi, > > due to a defect in the currently available binutils-2.24 and earlier, it is > not possible > to boot-strap GCC 4.9.0 and trunk with certain widely used configurations for > Cygwin-32 environment. > See PR 60830 for details. > > Boot-Strapped o

[PATCH] Fix PR61010

This fixes an endless recursion in folding that appears because we are inconsistent in how we treat X & CST canonicalization if we can omit some bits in CST. The following patch makes the two places that do this consistent. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 20

[PATCH] Work around for current Cygwin-32 Build problems

Hi, due to a defect in the currently available binutils-2.24 and earlier, it is not possible to boot-strap GCC 4.9.0 and trunk with certain widely used configurations for Cygwin-32 environment. See PR 60830 for details. Boot-Strapped on x86-64-cygwin and i686-pc-cygwin with binutils-2.24. OK f

[PATCH][C++] Fix PR61004

With no longer recording alias subsets using BINFOs we now emit bogus alias warnings for accessing empty bases. The following avoids this, accessing those with an incompatible alias-set is harmless. Bootstrapped and tested on x86_64-unknown-linux-gnu, ok? Thanks, Richard. 2014-04-30 Richard B

Re: [PATCH][3/3] Fix PR54733 Optimize endian independent load/store

On Wed, Apr 30, 2014 at 8:23 AM, Thomas Preud'homme wrote: > Hi Richard, > > I addressed all your comments but the ones below. > >> From: Richard Biener [mailto:richard.guent...@gmail.com] >> >> + /* Convert the result of load if necessary. */ >> + if (!useless_typ

[PATCH] Testcase for PR48329

Committed. Richard. 2014-04-30 Richard Biener PR tree-optimization/48329 * gfortran.dg/vect/pr48329.f90: New testcase. Index: gcc/testsuite/gfortran.dg/vect/pr48329.f90 === --- gcc/testsuite/gfortran.dg/vect/pr4

Re: [PATCH] New target hook: keep_leaf_when_profiled

On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote: > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi > index b8ca17e..937c2d5 100644 > --- a/gcc/doc/tm.texi > +++ b/gcc/doc/tm.texi > @@ -4953,6 +4953,10 @@ Define this macro if the code for function profiling > should come before > the functio

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

> > * http://gcc.gnu.org/ml/fortran/2014-04/msg00091.html > > "dg2final" Surely this is a typo? ... I also see dg1final and dg.final. Dominique

Re: [AArch64/ARM 3/3] Add execution tests of ARM UZP Intrinsics

On Thu, Mar 27, 2014 at 5:28 PM, Alan Lawrence wrote: > inal patch in series, adds new tests of the ARM UZP Intrinsics (subsuming > the autogenerated ones in testsuite/gcc.target/arm/neon/), that also check > the execution results, reusing the test bodies introduced into AArch64 in > the first pat

Re: [AArch64/ARM 3/3] Add execution tests of ARM EXT intrinsics

On Wed, Apr 23, 2014 at 9:32 PM, Alan Lawrence wrote: > Final patch in series, adds new tests of the ARM EXT Intrinsics, that also > check > the execution results, reusing the test bodies introduced into AArch64 in > the > first patch. (These tests subsume the autogenerated ones in > testsuite/gcc

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis wrote: >> ISTR we went to typed allocs as part of a transition which not >> fully materialised? > > Yes. I had plans to replace the call-based GC marker routines with a > generic routine that operates on a type marker stored next to the > object.

Re: [AArch64/ARM 3/3] Add execution tests of ARM ZIP Intrinsics

On Thu, Mar 27, 2014 at 10:53 AM, Alan Lawrence wrote: > Final patch adds new tests of the ARM ZIP Intrinsics (subsuming the > autogenerated ones in testsuite/gcc.target/arm/neon/), that also check the > execution results, reusing the test bodies introduced into AArch64 in the > first patch. > > A

[C++ Patch] PR 60999

Hi, this regression unfortunately has to do with my fix for c++/57887, thus the code in maybe_begin_member_template_processing: if (nsdmi) decl = (CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl)) ? CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (decl)) : NULL_TREE); The check is t

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

> ISTR we went to typed allocs as part of a transition which not > fully materialised? Yes. I had plans to replace the call-based GC marker routines with a generic routine that operates on a type marker stored next to the object. That enables partial, generational, etc GC. > I actually dislike t

[wide-int] fix 32-bit x86 builds

[ sorry for the dup ] We changed the underlying type a while back, and it matters on 32-bit pointer machines that use long long for a HOST_WIDE_INT… Caught by fold-checking, thanks fold checking. This is the tree-vrp problem, I think this was seen on arm as well. Checked in as obvious. Index

[wide-int] fix 32-bit x86 builds

We changed the underlying type a while back, and it matters on 32-bit pointer machines that use long long for a HOST_WIDE_INT… Caught by fold-checking, thanks fold checking. Checked in as obvious. Index: tree.c === --- tree.c

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

Dear Tobias, On 27 April 2014 20:56, Tobias Burnus wrote: > First, I would be really delighted if someone could review my coarray > patches for the trunk as it makes simpler to develop patches on top of it: > * http://gcc.gnu.org/ml/fortran/2014-04/msg00087.html This is OK for trunk. > * http:/

Re: [PATCH][RFC] Always require a 64bit HWI

On Tue, 29 Apr 2014, Jeff Law wrote: > On 04/29/14 05:21, Richard Biener wrote: > > > > The following patch forces the availability of a 64bit HWI > > (without applying the cleanups that result from this). I propose > > this exact patch for a short time to get those that are affected > > and do

Re: [PATCH, MIPS] Alter default number of single-precision registers

Matthew Fortune writes: > Richard Sandiford writes: >> Matthew Fortune writes: >> > Hi Richard, >> > >> > When MIPSr1 introduced the ability to use odd-numbered >> > single-precision registers some implementations continued to only >> > support even-numbered single-precision registers. Notably,

RE: [PATCH, MIPS] Alter default number of single-precision registers

Richard Sandiford writes: > Matthew Fortune writes: > > Hi Richard, > > > > When MIPSr1 introduced the ability to use odd-numbered > > single-precision registers some implementations continued to only > > support even-numbered single-precision registers. Notably, > loongson3a > > in FR=0 mode on

Re: [PATCH] Implement -fsanitize=float-divide-by-zero

On Wed, Apr 30, 2014 at 08:55:10AM +0200, Jakub Jelinek wrote: > Please assign the result of the divisions to some other volatile variables, > otherwise I don't see why the compiler couldn't optimize them away all. > > Otherwise looks good to me. Done, thanks. Marek