[PATCH] Keep patch file permissions in mklog

2014-05-31 Thread Tom de Vries
Geoff, Currently, mklog resets the permissions on a patch file: ... $ touch tmp.patch $ ls -la tmp.patch -rw-rw-r-- 1 vries vries 0 mei 31 09:17 tmp.patch $ ./contrib/mklog tmp.patch $ ls -la tmp.patch -rw--- 1 vries vries 59 mei 31 09:17 tmp.patch $ ... This patch fixes that: ... $ rm tmp.p

[PATCH 0/5] Cache recog_op_alt by insn code, take 2

2014-05-31 Thread Richard Sandiford
Sorry Jeff, while working on the follow-on LRA patch I came across a couple of problems, so I need another round on this. First of all, I mentioned doing a follow-on patch to make LRA and recog use the same cache for operand_alternatives. I hadn't realised until I wrote that patch that there's a

[PATCH 1/5] Flatten recog_op_alt and reorder entries

2014-05-31 Thread Richard Sandiford
As described in the covering note, this patch converts recog_op_alt into a flat array and orders the entries in the same way as the LRA cache. Several places just want the information for alternative which_alternative, so I added a convenience function for that. Thanks, Richard gcc/ * r

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

2014-05-31 Thread Kai Tietz
Hmm, this might cause by allowing CONST-memory-addresses. This was doubtful from the beginning. It would be helpful to see here for the case a final rtl-dump. Could you try if following patch (it is incomplete as it disregards plus-expression) solves your bootstrap issue? Regards, Kai Index: p

[PATCH 2/5] Don't modify recog_op_alt after preprocess_constraints

2014-05-31 Thread Richard Sandiford
Since the aim of this series is to cache the result of preprocess_constraints, we need to make sure that passes don't modify the information afterwards. This patch deals with the places that did. Patch 4 will make the information properly const. Thanks, Richard gcc/ * recog.h (alternati

[PATCH 3/5] Make recog_op_alt consumers check the enabled attribute

2014-05-31 Thread Richard Sandiford
As described in the covering note, it seems better to put the onus of checking the enabled attribute on the passes that are walking each alternative, like LRA does for its internal subpasses. That leads to a nicer interface in patch 4 and would make it easier to precompute the information at build

[PATCH 4/5] Cache recog_op_alt by insn code: main patch

2014-05-31 Thread Richard Sandiford
This is the refreshed main patch. I've rearranged the preprocess_constraints code into three functions so that LRA can use it in patch 5. Thanks, Richard gcc/ * recog.h (operand_alternative): Convert reg_class, reject, matched and matches into bitfields. (preprocess_cons

[PATCH 5/5] Reuse recog_op_alt cache in LRA

2014-05-31 Thread Richard Sandiford
The operand_alternative cache was LRA's only per-subtarget state so a lot of this patch is removing the associated initialisation and target_globals stuff. I called the preprocess_constraints functions in lra_set_insn_recog_data rather than setup_operand_alternative because lra_set_insn_recog_data

Re: [Patch ARM] PR 61154 - Define TARGET_SUPPORTS_WIDE_INT.

2014-05-31 Thread Richard Sandiford
Ramana Radhakrishnan writes: > Hi, > > This is the simplest patch to fix PR61154 that came after the wide-int > merge. I've got a patch stack that tries to audit the use of GEN_INT vs > gen_int_mode and the use of CONST_DOUBLE with VOIDmode in the backend > but it's still not safe to go a

Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os

2014-05-31 Thread Richard Sandiford
Sandra Loosemore writes: > On 05/28/2014 01:09 PM, Richard Sandiford wrote: >> Sandra Loosemore writes: >> >>> On 05/19/2014 01:38 PM, Sandra Loosemore wrote: 2014-05-19 Iain Sandoe Catherine Moore Sandra Loosemore gcc/ * c

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

2014-05-31 Thread Kai Tietz
That patch won't help here. My tests showing here a different problem. For -O2 or above this issue happens. For -O2 the following code will be generated. movl28(%esp), %eax testl %eax, %eax je L16 movl%ebp, 64(%esp) addl$44, %esp

Re: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

2014-05-31 Thread Dominique Dhumieres
Hi Joost, Why do you want -fno-math-errno to be the default for gfortran? AFAICT such default is not documented and the flag works (checked on your test gfortran.dg/errnocheck_1.f90). For -fassociative-math, the manual says For Fortran the option is automatically enabled when both -fno-signed-ze

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

2014-05-31 Thread Kai Tietz
Hello, recent fallout about sibcall was caused by using 'm' constraint for sibcalls. By this wrongly combines happened on reload-pass. ChangeLog 2014-05-31 Kai Tietz * constrains.md (define_constrain): New 'B' constraint. * i386.md (sibcall_insn_operand): Use B instead of m constrai

[PATCH] m68k: add missing early clobber in beq0_di, bne0_di patterns

2014-05-31 Thread Andreas Schwab
This is a wrong code bug that appeared in netcdf when compiling with gcc 4.8. Due to difference in register allocation this doesn't trigger in 4.9 or trunk, but it is obvious that the bug is only dormant. The issue is that if the first operand matches "o" it may contain the same register as opera

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

2014-05-31 Thread Kai Tietz
In testcase a NULL escaped ... ChangeLog testsuite 2014-05-31 Kai Tietz * gcc.target/i386/sibcall-6.c: New test. Index: gcc.target/i386/sibcall-6.c === --- gcc.target/i386/sibcall-6.c(Revision 0) +++ gcc.target/i386/sibc

[patch i386]: Fix sibcall failures caused by allowing constant memories

2014-05-31 Thread Kai Tietz
Hello, I resend patch within new thread. Recent fallout about sibcall was caused by using 'm' constraint for sibcalls. By this wrongly combines happened on reload-pass. That patch introduces new constraint 'B' for sibcall_memory_operand. ChangeLog 2014-05-31 Kai Tietz * constrains.md (d

Re: ipa-visibility TLC 2/n

2014-05-31 Thread David Edelsohn
This leads to bootstrap errors like: In file included from /tmp/20140531/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/backward/strstream:54:0, from /nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/strstream.cc:44: /tmp/20140531/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/istream

Re: [patch i386]: Fix sibcall failures caused by allowing constant memories

2014-05-31 Thread Dominique Dhumieres
> I resend patch within new thread. ... This patch fixes pr61377. Could it be committed ASAP? TIA, Dominique

Re: Eliminate write-only variables

2014-05-31 Thread Sandra Loosemore
On 05/20/2014 04:56 AM, Richard Biener wrote: On Tue, May 20, 2014 at 6:29 AM, Jan Hubicka wrote: On 05/18/2014 08:45 PM, Sandra Loosemore wrote: On 05/18/2014 02:59 PM, Jan Hubicka wrote: For cases like local-statics-7 your approach can be "saved" by adding simple IPA analysis to look for st

Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux*

2014-05-31 Thread Peter Bergner
On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote: > On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote: > > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: > > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: > > > > This is being discussed in the thread at > > >

Re: [patch i386]: Fix sibcall failures caused by allowing constant memories

2014-05-31 Thread Jeff Law
On 05/31/14 06:27, Kai Tietz wrote: Hello, I resend patch within new thread. Recent fallout about sibcall was caused by using 'm' constraint for sibcalls. By this wrongly combines happened on reload-pass. That patch introduces new constraint 'B' for sibcall_memory_operand. ChangeLog 2014-05-3

Re: [PATCH, PR 61160] IPA-CP and edges leading to thunks of clones

2014-05-31 Thread Jan Hubicka
> Hi, > > PR 61160 is actually two problems, this patch deals with the one > reported in comment one. The underlying cause is that an IPA-CP test > whether an edge is already leading to a clone does not look through > thunks, which caused it to double count and doubly-redirect them. > > Bootstra

Re: ipa-visibility TLC 2/n

2014-05-31 Thread Richard Sandiford
David Edelsohn writes: > Honza, > > With the patch, I cannot bootstrap. I think it was meant to be: place_block_symbol (target); rather than: place_block_symbol (symbol); I.e. we need to place "target" before copying its offset. Thanks, Richard