Re: [PATCH][ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect

Kyrill Tkachov writes: > Hi all, > > This hunk that slightly reduces the cost of immediate moves doesn't > actually have any effect. In the whole of SPEC2006 it didn't make a > difference. In any case, I'd like to move to a point where we use > COSTS_N_INSNS units for our costs and not increment

Re: [PATCH diagnostics/fortran] Handle two locations for the same diagnostic. Convert all gfc_warning_1 and gfc_notify_std_1 calls

Dear all, Dodji: The gcc/*.[ch] part is your realm. David: I added you as CC because you looked into fancier diagnostics before Manuel López-Ibáñez wrote: > The Fortran FE allows diagnostics with two different locations. [...] > This is the last remaining issue Thanks for working on this - and s

Re: [RFC] Tighten memory type assumption in RTL combiner pass.

Jeff Law writes: > On 01/16/2015 12:13 AM, Venkataramanan Kumar wrote: >> >> The below test case which I am working on is from the PR63949 >> >> int subsi_sxth (int a, short i) >> { >>/* { dg-final { scan-assembler "sub\tw\[0-9\]+,.*sxth #?1" } } */ >>return a - ((int)i << 1); >> } >> >

[PATCH][libstdc++-v3] Add _GLIBCXX_HAVE_LIMIT_FSIZE to guard 27_io/fpos/14775.cc

Hi all, This is a simple patch to add _GLIBCXX_HAVE_LIMIT_FSIZE to guard the test. In libstdc++-v3/testsuite/util/testsuite_hooks.cc. set_file_limit() function is nullified when either _GLIBCXX_RES_LIMITS or _GLIBCXX_HAVE_LIMIT_FSIZE is not defined. _GLIBCXX_USE_LFS can cover _GLIBCXX_RES_LIMI

Re: [PATCH][ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect

Hi Richard, On 06/05/15 08:15, Richard Sandiford wrote: Kyrill Tkachov writes: Hi all, This hunk that slightly reduces the cost of immediate moves doesn't actually have any effect. In the whole of SPEC2006 it didn't make a difference. In any case, I'd like to move to a point where we use COS

[4.9 PATCH, testsuite]: Use c++1y target for g++.dg/cpp1y/auto-fn26.C

Hello! 2015-05-06 Uros Bizjak * g++.dg/cpp1y/auto-fn26.C (dg-do): Use c++1y target. Tested on x86_64-linux-gnu and committed to 4.9 branch. Uros. Index: g++.dg/cpp1y/auto-fn26.C === --- g++.dg/cpp1y/auto-fn26.C(revision

Re: [PATCH][libstc++v3]Add new dg-require-thread-fence directive.

Hi Jonathan, On 22/04/15 13:58, Jonathan Wakely wrote: On 22 April 2015 at 12:25, Renlin Li wrote: Hi Jonathan, Thank you for the suggestion. I have just attached the updated the patch. It works as before. Is this Okay to commit? OK, thanks. Is it Okay for me to backport this patch to bran

Re: [PATCH] Fix OpenACC shutdown and PTX image unloading (PR65904)

Hi! On Fri, 1 May 2015 10:47:19 +0100, Julian Brown wrote: > This patch fixes PR65904, a double-free error that started occurring > after recent libgomp changes to the way offload images are registered > with the runtime. > > Offload images now map all functions/data using just two malloc'ed > b

[patch 1/28] top-level: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for top-level files. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. compile: Recreate. config.guess: Recreate. config.sub: Recreate. depcomp: Recreat

[patch 2/28] boehm-gc: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for boehm-gc. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. include/Makefile.in:

[patch 3/28] fixincludes: Use automake-1.11.6 (across the tree)

Trivial patch for fixincludes. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-

[patch 4/28] gotools: Use automake-1.11.6 (across the tree)

Patch for gotools. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Gla

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for intl. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: intl/aclocal.m4 =

[patch 6/28] libatomic: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libatomic. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. Index: libatomic/Makefile.in =

[patch 7/28] libbacktrace: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libbacktrace. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. Index: libbacktrac

[patch 8/28] libcc1: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libcc1. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. Index: libcc1/Makefile.i

[patch 9/28] libcilkrts: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libcilkrts. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. Index: libcilkrts/Ma

[patch 10/28] libcpp: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for libcpp. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: libcpp/aclocal.m4 =

[patch 11/28] libdecnumber: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for libdecnumber. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: libdecnumber/aclocal.m4 =

[patch 12/28] libffi: Use automake-1.11.6 (across the tree)

Patch for libffi. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Glaw

[patch 13/28] libgfortran: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libgfortran. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. Index: libgfortran/Makefile.in =

[patch 14/28] libgomp: Use automake-1.11.6 (across the tree)

Patch for libgomp. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Gla

[patch 15/28] libgo: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libgo. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. testsuite/Makefile.in: Re

[patch 16/28] libitm: Use automake-1.11.6 (across the tree)

Patch for libitm. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Glaw

Re: [patch 1/28] top-level: Use automake-1.11.6

On Wed, May 06, 2015 at 10:50:57AM +0200, Michael Haubenwallner wrote: > > Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > Patch for top-level files. > 2015-05-06 Michael Haubenwallner > > Use automake-

Re: ping**n re [patch, ARM] Add support for crtfastmath.o

On Tue, May 5, 2015 at 6:53 PM, Sandra Loosemore wrote: > This patch I posted last fall: > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00711.html > > still has not been reviewed, in spite of me pinging it several times before > GCC 5 went into stage 4. Now that we're back in stage 1 again, ca

Re: [patch, arm] align saved FP regs on stack

On Sat, Nov 15, 2014 at 12:46 AM, Sandra Loosemore wrote: > On ARM targets, the stack is aligned to an 8-byte boundary, but when > saving/restoring the VFP coprocessor registers in the function > prologue/epilogue, it is possible for the 8-byte values to end up at > locations that are 4-byte align

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

Ping? Best regards, Thomas > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Monday, March 16, 2015 8:39 PM > To: 'Steven Bosscher' > Cc: GCC Patches; Eric Botcazou > Subject: RE: [PATCH, stage1] M

Re: [PATCH, ARM, PR64208] LRA ICE Fix

On Thu, Apr 30, 2015 at 6:49 PM, Yvan Roux wrote: > Hi, > > On 23 March 2015 at 18:47, Yvan Roux wrote: >> Hi, >> >> On 23 March 2015 at 17:08, Ramana Radhakrishnan >> wrote: >>> On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote: Hi, This is a fix for PR64208 where LRA loops when

[RS6000] Fix PR66020, -mprofile-kernel related

-mprofile-kernel changed recently to not save lr on the stack before calling _mcount. This means a change is required in the _mcount used by one of the powerpc64 tests to grab function parameter registers. While fixing that, I noticed that the asm defined the _mcount label, which is a bit rude;

Re: RFA: Doc update: Describe new MSP430 feature

Hi Gerald, as maintainer of the port you do not need anyone else's approval. Thanks - have checked the (editted) patch in. That said, I am always happy to provide a second pair of eyes, so here are some comments: Thanks for those too. I have made the appropriate changes following your su

Re: [PATCH][AArch64] PR target/65491: Classify V1TF vectors as AAPCS64 short vectors rather than composite types

Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01004.html Thanks, Kyrill On 20/04/15 11:16, Kyrill Tkachov wrote: Hi all, The ICE in the PR happens when we pass a 1x(128-bit float) vector as an argument. The aarch64 backend erroneously classifies it as a composite type when in fact it is

[patch 19/29] libjava: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libjava, without classpath and libltdl. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * confi

[patch 20/29] libmpx: Use automake-1.11.6 (across the tree)

Patch for libmpx. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Glaw

[patch 21/29] libobjc: Use automake-1.11.6 (across the tree)

Patch for libobjc. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict Gla

[patch 22/29] liboffloadmic: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for liboffloadmic.

[patch 18/29] libltdl Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libjava/libltdl, need to gzip for recipients gcc.gnu.org. libjava.libltdl.patch.gz Description: application/gzip

[patch 23/29] libquadmath: Use automake-1.11.6 (across the tree)

Patch for libquadmath. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict

Re: RFA: RL78: Save the frame pointer if it is used.

Hi DJ, OK to apply ? Ok, but... Thanks - committed. - if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed) + if (regno == FRAME_POINTER_REGNUM + && (frame_pointer_needed || df_regs_ever_live_p (regno))) Do we want regs_ever_live or regs_ever_written_to ? I seem to recall

[patch 24/29] libsanitizer: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libsanitizer. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * asan/Makefile.in: Likewise. *

[patch 25/29] libssp: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libssp. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * configure: Likewise. Index: libssp/M

Re: Movable initializer lists (C++ N4166)

> On 2015–05–04, at 12:00 AM, David Krauss wrote: > > Besides that, are some machines overloaded? If I need to use POWER, will > there be a learning curve or brittleness as on Darwin? To avoid trial and > error whilst wading into the process, I’m just asking for some personal > confirmation o

[patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree)

Patch for libstdc++-v3. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedic

[patch 27/29] libvtv: Use automake-1.11.6 (across the tree)

Patch for libvtv, also recreated (apparently) unused testsuite/other-tests/Makefile.in Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.c

[patch 28/29] lto-plugin: Use automake-1.11.6 (across the tree)

Patch for lto-plugin. Removing "by automake version number" from Makefile.am to avoid false positives when hunting for "by automake 1.11.[^6]". Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patc

[patch 29/29] zlib: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for zlib. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * configure: Likewise. Index: zlib/Makef

Re: [patch 22/29] liboffloadmic: Use automake-1.11.6

of course I forgot one to attach... Am 2015-05-06 um 12:13 schrieb Michael Haubenwallner: > > Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: >> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > Patch for liboffloadmic. > 2015-05-06 Michael Haubenwallner * Ma

[PATCH] Allow all target supported load permutations in BB SLP

Well - only those with no gaps in the groups with this patch. More as followup. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-05-06 Richard Biener * tree-vect-slp.c (vect_supported_load_permutation_p): Use vect_transform_slp_perm_load to check

Re: Fix PR48052: loop not vectorized if index is "unsigned int"

On Mon, May 4, 2015 at 9:47 PM, Abderrazek Zaafrani wrote: > This is an old thread and we are still running into similar issues: > Code is not being vectorized on 64-bit target due to scev not being > able to optimally analyze overflow condition. > > While the original test case shown here seems t

Re: [PATCH, PR target/66015]: Fix alignments with attribute_optimize for aarch64

On 05/05/2015 02:42 PM, Marcus Shawcroft wrote: > On 5 May 2015 at 12:07, Christian Bruel wrote: >> This fixes PR target/66015 and a latent issue revealed by >> gcc.dg/ipa/iinline-attr.c since >> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01609.html >> >> Regtested on aarch64-linux-gnu by Lin

Re: [PATCH 2/13] musl libc config

On 29/04/15 00:30, Joseph Myers wrote: > On Mon, 20 Apr 2015, Szabolcs Nagy wrote: > >> * config/linux.opt (mmusl): New option. > > New -m options need documenting in invoke.texi. > Patch v3. Now with documentation in invoke.texi. Based on previous discussion I assume it is OK to commit

Re: [PATCH 5/13] microblaze musl support

On 29/04/15 14:51, Szabolcs Nagy wrote: > On 29/04/15 14:17, Michael Eager wrote: >> On 04/27/2015 07:35 AM, Szabolcs Nagy wrote: >>> On 20/04/15 19:54, Szabolcs Nagy wrote: Set up dynamic linker name for microblaze. >>> >>> Patch v2. >>> (undef MUSL_DYNAMIC_LINKER that comes from confi

Re: [PATCH 0/13] Add musl support to GCC

On 30/04/15 00:18, Joseph Myers wrote: > On Wed, 29 Apr 2015, Szabolcs Nagy wrote: >> only affects [u]int_fastN_t types >> (on 64bit systems for N=16,32 musl uses int but glibc uses long) >> >> i can fix glibc-stdint.h, but it's yet another way in which the >> compiler is tied to a particular libc

Re: [C/C++ PATCH] Implement -Wshift-negative-value (PR c/65179)

On Wed, Apr 29, 2015 at 10:54:58PM +, Joseph Myers wrote: > On Mon, 27 Apr 2015, Marek Polacek wrote: > > > trigger by default. One change is that we reject programs that use shift > > with > > undefined behavior in a context where a constant expression is required, > > thus > > e.g. enum E

Fix logic error in Fortran OpenACC parsing (was: [PATCH 3/3] Fix indentation issues seen by -Wmisleading-indentation)

Hi! On Tue, 5 May 2015 15:38:03 -0400, David Malcolm wrote: > On Wed, 2015-04-29 at 14:10 +0200, Mikael Morin wrote: > > Le 29/04/2015 02:02, David Malcolm a écrit : > > > diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c > > > index 2c7c554..30e4eab 100644 > > > --- a/gcc/fortran/parse.c >

[PATCH] Fix another testsuite fallout for PR62283

Vectorization is now possible even for targets that don't support unaligned loads. Committed. Richard. 2015-05-06 Richard Biener PR tree-optimization/62283 * gcc.dg/vect/bb-slp-32.c: Remove XFAIL. Index: gcc/testsuite/gcc.dg/vect/bb-slp-32.c ===

[RS6000] Fix PR66033, nop pattern

Using a plain [(const_int 0)] for a nop pattern apparently no longer survives optimization. rtl_dce deletes these nops. This patch uses an unspec so that explicitly inserted nops are kept. Fixing that revealed a number of patterns and splitters that accidentally inserted [(const_int 0)] insns int

Re: [RFC] Tighten memory type assumption in RTL combiner pass.

On Wed, May 06, 2015 at 08:32:13AM +0100, Richard Sandiford wrote: > > Alternately, you could find a way to accurately track if we're inside a > > MEM, where we want to canonicalize things slightly differently. Once we > > can accurately track if we're inside a MEM, then we no longer have to >

[patch] fix gotools cross build

Yes, it's documented that there is still some work to do for cross builds, however a cross build for gotools currently fails. The toplevel make always passes the GOC variable in the environment, overwriting anything configured in gotools own configure.ac. Fixed by explictly using @GOC@ for GOCOMPI

Re: Next set of OpenACC changes: Fortran

Tobias, First, thank you for taking the time to review the patch. Second, thank you for providing the comments. It appears all of the comments need to be acted upon in some manner. Thanks! On 05/05/2015 05:01 AM, Tobias Burnus wrote: Thomas Schwinge wrote: In follow-up messages, I'll be post

Re: [RS6000] Fix PR66020, -mprofile-kernel related

On Wed, May 6, 2015 at 5:50 AM, Alan Modra wrote: > -mprofile-kernel changed recently to not save lr on the stack before > calling _mcount. This means a change is required in the _mcount > used by one of the powerpc64 tests to grab function parameter > registers. While fixing that, I noticed tha

Re: [RS6000] Fix PR66033, nop pattern

On Wed, May 6, 2015 at 8:22 AM, Alan Modra wrote: > Using a plain [(const_int 0)] for a nop pattern apparently no longer > survives optimization. rtl_dce deletes these nops. This patch uses > an unspec so that explicitly inserted nops are kept. > Fixing that revealed a number of patterns and spl

RE: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Hi, On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: > > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > BTW, the actual commands I use to re-run automake for everything (I found) is: > $ export AUTOMAKE='automake-1.11 --add-missing --copy --force-missing' > $

Re: [PATCH][AArch64] Fix geniterators.sh to use standard BRE syntax in sed

On 01/05/15 13:51, Marcus Shawcroft wrote: On 23 March 2015 at 17:06, Szabolcs Nagy wrote: GCC can be compiled for aarch64 target with busybox sed except for the geniterators.sh script which uses nonstandard basic regex. I explicitly set LC_ALL=C too because the regex depends on collation ord

[PATCH] rs6000: Expand all comparisons against a constant

This patch makes cstore expand all comparisons against a constant (that aren't already handled by a subfc;subfe sequence) as an addi ; [n]{and,or}[c] ; sr[wd]i sequence. It expands all the possible inversions separately (as well as add to zero); combine and friends will take care of all that. Th

Fix compiler warnings

I recently compiled gcc with clang and found few useful warnings (https://gcc.gnu.org/ml/gcc/2015-05/msg00015.html, https://gcc.gnu.org/ml/gcc/2015-05/msg00041.html). I have a patch to fix some of those, it passes bootstrap, please apply these if it is useful. Thanks, -Aditya

Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)

On 05/05/15 19:07, Richard Biener wrote: > On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw > wrote: >> On 05/05/15 15:33, Richard Earnshaw wrote: >>> On 05/05/15 15:29, Jakub Jelinek wrote: On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote: > On 05/05/15 14:06, Jakub

[PATCH] Simple optimization for MASK_STORE.

Hi All, Here is a patch which gives us significant speed-up on HASWELL for test containing masked stores. The main goal of that patch is attempt to avoid HW hazard for maskmove instructions through inserting additional check on zero mask and putting all masked store statements into separate block

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

On 05/05/2015 10:03 AM, Michael Haubenwallner wrote: Hello build machinery maintainers, following up http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 http://thread.gmane.org/gmane.comp.gcc.patches/332160 [ ... snip ... ] Even if I probably need to split this change into one

[PATCH, ARM] attribute target (thumb,arm) [0/6] respin (4th)

> A general note, please reply to each of the patches with a rebased > patch as a separate email. Further more all your patches appear to > have dos line endings so they don't seem to apply cleanly. Please > don't have spurious headers in your patch submission - it then makes > it hard to , please

Re: [PATCH, ARM, PR64208] LRA ICE Fix

On 6 May 2015 at 11:50, Ramana Radhakrishnan wrote: > On Thu, Apr 30, 2015 at 6:49 PM, Yvan Roux wrote: >> Hi, >> >> On 23 March 2015 at 18:47, Yvan Roux wrote: >>> Hi, >>> >>> On 23 March 2015 at 17:08, Ramana Radhakrishnan >>> wrote: On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote: >>

[PATCH, ARM] attribute target (thumb,arm) [1/6] respin (4th)

In preparation of the target attribute, reorganize Âarm_option_override into 3 entities: arm_option_override_internal_p arm_option_check_internal arm_option_param_internal Also define and use TREE_TARGET macros instead of file-scope variables in the machine description. Thanks, Christian 2014-

[PATCH, ARM] attribute target (thumb,arm) [2/6] respin (4th)

In preparation of the pragma target reorganize ÂTARGET_CPU_CPP_BUILTINSÂ to redefine mode dependent macros based on current thumb_p. Thanks, Christian 2014-09-23 Christian Bruel * config/arm/arm-c.c (cpp_def_or_undef): New functions. (arm_cpp_builtins): Likewise. * config/arm/arm.h (TARG

[PATCH, ARM] attribute target (thumb,arm) [3/6] respin (4th)

Re-implement ARM_DECLARE_FUNCTION_NAME as a function. That will make changed related to unified/divided and mode directives easier to insert. Thanks Christian 2014-09-23 Christian Bruel * config/arm/arm-protos.h (arm_declare_function_name): Declare. (is_called_in_ARM_mode): Remove. * conf

[PATCH, ARM] attribute target (thumb,arm) [4/6] respin (4th)

Implements and document the hooks to support target_attributes. The emission of blx is handled directly for armv5 to overcome a bug with the current binutils that fails with calls to a static symbol in a different section. (e.g .text -> .text.startup) in different modes. (ref https://sourceware.o

Re: [PATCH] Add SPECIAL_FLOAT_MODE to enable adding IEEE 128-bit floating point to PowerPC

On 05/05/2015 05:54 PM, Michael Meissner wrote: This patch contains the machine independent changes that I will need to add IEEE 128-bit floating point to the GCC compiler for PowerPC. It adds a new mode defintion macro: SPECIAL_FLOAT_MODE that is similar to FLOAT_MODE. The difference is the co

[PATCH, ARM] attribute target (thumb,arm) [5/6] respin (4th)

Implements the hooks for #pragma GCC target A test included to check that macros were correctly defined/undefined on pragma regions. Thanks Christian 2014-09-23 Christian Bruel * config/arm/arm.h (REGISTER_TARGET_PRAGMAS): Call arm_register_target_pragmas. * config/arm/arm-protos.h (arm_

[PATCH, ARM] attribute target (thumb,arm) [6/6] respin (4th)

Implement the -mflip-thump option. Undocumented for internal testing only. This option artificially inserts alternative attribute thumb/modes on functions. This close the patch set. Thanks for your review, Christian 2014-09-23 Christian Bruel * config/arm/arm.c (add_attribute, arm_insert_att

[C++ patch] N4166: movable initializer lists for C++1z

Hi all, Here is an implementation of std::initializer_list objects that properly own the underlying sequence. This will allow list-initialization for containers like std::vector< std::unique_ptr< T > >, but such library support will come in a subsequent patch if this one is supported. To summa

Re: Fix compiler warnings

On Wed, May 06, 2015 at 01:47:38PM +, Aditya K wrote: > I recently compiled gcc with clang and found few useful warnings > (https://gcc.gnu.org/ml/gcc/2015-05/msg00015.html, > https://gcc.gnu.org/ml/gcc/2015-05/msg00041.html). > I have a patch to fix some of those, it passes bootstrap, please

[PATCH] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

2015-05-06 Gleb Fotengauer-Malinovskiy PR libitm/61164 * local_atomic (__always_inline): Rename to... (__libitm_always_inline): ... this. --- libitm/local_atomic | 299 ++-- 1 file changed, 149 insertions(+), 150 deletions

Re: [PATCH] Add SPECIAL_FLOAT_MODE to enable adding IEEE 128-bit floating point to PowerPC

Jeff Law writes: > On 05/05/2015 05:54 PM, Michael Meissner wrote: >> This patch contains the machine independent changes that I will need to add >> IEEE 128-bit floating point to the GCC compiler for PowerPC. >> >> It adds a new mode defintion macro: SPECIAL_FLOAT_MODE that is similar to >> FLOAT

Re: Fix compiler warnings

Hi! See Trevor's comments on ChangeLog. diff --git a/gcc/reload.h b/gcc/reload.h index c777e54..ae86150 100644 --- a/gcc/reload.h +++ b/gcc/reload.h @@ -168,7 +168,7 @@ struct target_reload { value indicates the level of indirect addressing supported, e.g., two means that (MEM (MEM (R

Re: [PATCH] rs6000: Expand all comparisons against a constant

On Wed, May 6, 2015 at 9:36 AM, Segher Boessenkool wrote: > This patch makes cstore expand all comparisons against a constant > (that aren't already handled by a subfc;subfe sequence) as an > addi ; [n]{and,or}[c] ; sr[wd]i sequence. It expands all the > possible inversions separately (as well a

Re: [PATCH] Expand PIC calls without PLT with -fno-plt

On Mon, 4 May 2015, Jeff Law wrote: > On 05/04/2015 11:39 AM, Jakub Jelinek wrote: > > On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote: > > > On 05/04/2015 10:37 AM, Alexander Monakov wrote: > > > > This patch introduces option -fno-plt that allows to expand calls that > > > > would > > >

Re: [PATCH] Add SPECIAL_FLOAT_MODE to enable adding IEEE 128-bit floating point to PowerPC

On Tue, 5 May 2015, Michael Meissner wrote: > The problem is the PowerPC will have 2 128-bit floating point types, one using > the IBM double-double format (a pair of doubles to give the user more mantissa > bits, but no greater exponent range), and IEEE 128-bit floating point. I > don't > want

Vectorize stores with unknown stride

Hi, I'm sitting on this since quite some time already and always missed stage 1. This implements support for vectorizing strided stores with unknown but loop invariant stride, like: sumit (float * __restrict dest, float * __restrict src, float * __restrict src2, int stride, int n

Re: [PATCH][libstc++v3]Add new dg-require-thread-fence directive.

On 6 May 2015 at 09:27, Renlin Li wrote: > Hi Jonathan, > > > On 22/04/15 13:58, Jonathan Wakely wrote: >> >> On 22 April 2015 at 12:25, Renlin Li wrote: >>> >>> Hi Jonathan, >>> >>> Thank you for the suggestion. I have just attached the updated the patch. >>> It >>> works as before. >>> Is this Ok

Re: [PATCH] Expand PIC calls without PLT with -fno-plt

On Wed, May 06, 2015 at 06:24:58PM +0300, Alexander Monakov wrote: > If the same PLT stubs as today are to be used, it constrains the compiler on > 32-bit x86 and possibly other arches where PLT stubs need GOT pointer in a > specific register. It's possible to imagine more complex PLT stubs that >

C/C++ PATCH to allow deprecating enum values (PR c/47043)

This patch implements a feature quite a lot of people wanted: allow using __attribute__ ((deprecated)) on an enumerator. Implementing it was quite straightforward: parse the attributes and apply them to the CONST_DECL. I hit an issue in the C++ FE though: since r217677 we produce the deprecated d

Re: Fix compiler warnings

Jakub Jelinek writes: > Hi! > > See Trevor's comments on ChangeLog. > > diff --git a/gcc/reload.h b/gcc/reload.h > index c777e54..ae86150 100644 > --- a/gcc/reload.h > +++ b/gcc/reload.h > @@ -168,7 +168,7 @@ struct target_reload { > value indicates the level of indirect addressing supported

Re: [PATCH] Expand PIC calls without PLT with -fno-plt

On 05/06/2015 09:45 AM, Jakub Jelinek wrote: As for hoisting the load of the call address before the loop, with lazy binding that has the obvious disadvantage that you'd resolve the slot again and again, if you are unlucky enough that the function hasn't been resolved yet. Unless the shared PLT

Re: [patch 1/28] top-level: Use automake-1.11.6

On Wed, 6 May 2015, Michael Haubenwallner wrote: > Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > Patch for top-level files. I don't think this top-level patch is a good idea. These are *not* generated files,

Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)

On Wed, 6 May 2015, Marek Polacek wrote: > 2015-05-06 Marek Polacek > > PR c/47043 > * c-common.c (handle_deprecated_attribute): Allow CONST_DECL. Do all other attributes already reject CONST_DECL? I don't see any tests for unsupported attributes on enum values being properly di

Re: Fix compiler warnings

On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote: > Also, it would be nice to figure why gcc doesn't warn (for both meaningful > changes, in the first snippet I believe gcc just determines the static > function is noreturn and that is why it correctly doesn't warn). > I thought Marek h

Re: Fix compiler warnings

On Wed, May 06, 2015 at 06:18:23PM +0200, Marek Polacek wrote: > On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote: > > Also, it would be nice to figure why gcc doesn't warn (for both meaningful > > changes, in the first snippet I believe gcc just determines the static > > function is n

Re: Fix compiler warnings

On Wed, May 06, 2015 at 04:22:13PM +, Aditya K wrote: > Thanks Richard, Jakub and Trevor for the feedback. I have reformatted the > changelog, and modified the patch addressing your comments. > > -Aditya > > > 2015-05-06 Aditya Kumar > > * gcov-tool.c (do_merge): > * ipa

Re: [debug-early] fix problem with template parameter packs

On 05/05/2015 04:33 PM, Aldy Hernandez wrote: On 05/05/2015 02:08 PM, Jason Merrill wrote: On 05/04/2015 09:29 PM, Aldy Hernandez wrote: The code handling parameter DIEs needed a little tweaking for variable length template arguments. I've relaxed the original assert, but this may require twea

RE: Fix compiler warnings

Thanks! Updated patch. 2015-05-06  Aditya Kumar      * gcov-tool.c (do_merge): Refactored to remove int ret.     * ipa-icf.c (sem_item::hash_referenced_symbol_properties): Changed (!type == FUNC) to (type != FUNC).     * reload.h (struct target_reload): Changed to type of x_spill_

Re: Fix compiler warnings

On Wed, May 06, 2015 at 06:18:23PM +0200, Marek Polacek wrote: > On Wed, May 06, 2015 at 04:58:03PM +0200, Jakub Jelinek wrote: > > Also, it would be nice to figure why gcc doesn't warn (for both meaningful > > changes, in the first snippet I believe gcc just determines the static > > function is n

  1   2   >