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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> I resend patch within new thread. ...
This patch fixes pr61377. Could it be committed ASAP?
TIA,
Dominique
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
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
> > >
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
> 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
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
23 matches
Mail list logo