2011/9/12 Georg-Johann Lay :
> This patch introduces patterns for multiply-add and multiply-sub.
>
> On the enhanced core, these operations can be performed with the product in
> R0;
> there is no need to MOVW it out of that register. The code is smaller and
> faster and has lower register pressu
Bernd Schmidt writes:
>>> +/* Return true if INSN requires the stack frame to be set up.
>>> + PROLOGUE_USED contains the hard registers used in the function
>>> + prologue. */
>>> +static bool
>>> +requires_stack_frame_p (rtx insn, HARD_REG_SET prologue_used)
>>> +{
>>> [...]
>>> + if (for_
Ayal Zaks writes:
> So instead of navigating directly from
> ps_insn->ddg_node->node_sched_params, we now use indices and lookup
> pointees in ddg_node and node_sched_params arrays. A bit of a
> nuisance, but it's ok with me.
Well, IMO, ps_insn->ddg_node->node_sched_params is the same amount
of i
Hi
2011/9/12 Dodji Seketeli :
> Romain Geissler a écrit:
>> When i recontributed the PLUGIN_FINISH_DECL patch from the original
>> Brian Hackett, i didn't exactly checked what may or may not trigger
>> this new event. I know for example that declaring a function triggers
>> this event, but defi
On 09/13/11 10:35, Richard Sandiford wrote:
>> Also, it turns out I need to pretend that trap_if requires the prologue
>> due to the testcase you also ran across, so a for_each_rtx walk is
>> required anyway.
>
> Why does TRAP_IF inherently need a prologue though? The CFA information
> should be
Bernd Schmidt writes:
> On 09/13/11 10:35, Richard Sandiford wrote:
>>> Also, it turns out I need to pretend that trap_if requires the prologue
>>> due to the testcase you also ran across, so a for_each_rtx walk is
>>> required anyway.
>>
>> Why does TRAP_IF inherently need a prologue though? Th
On 09/13/11 13:37, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> On 09/13/11 10:35, Richard Sandiford wrote:
Also, it turns out I need to pretend that trap_if requires the prologue
due to the testcase you also ran across, so a for_each_rtx walk is
required anyway.
>>>
>>> Why
Bernd Schmidt writes:
> On 09/13/11 13:37, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> On 09/13/11 10:35, Richard Sandiford wrote:
> Also, it turns out I need to pretend that trap_if requires the prologue
> due to the testcase you also ran across, so a for_each_rtx walk is
>
While working on an ARM backend patch, I tripped over a case in which
a subreg of a vector zero-extension was wrongly being optimised to zero.
This comes from the following code in simplify_subreg:
/* Optimize SUBREG truncations of zero and sign extended values. */
if ((GET_CODE (op) == ZERO_
Hello,
the unique caller of the function `make_return_insns' is not guarded by
[HAVE_return], causing a linker error if !HAVE_return.
Any comment?
Cheers,
Giuseppe
gcc/ChangeLog
2011-09-13 Giuseppe Scrivano
* reorg.c: Always define make_return_insns.
diff --git a/gcc/reorg.c b
2011/9/13 Richard Sandiford
>
> Ayal Zaks writes:
> > So instead of navigating directly from
> > ps_insn->ddg_node->node_sched_params, we now use indices and lookup
> > pointees in ddg_node and node_sched_params arrays. A bit of a
> > nuisance, but it's ok with me.
>
> Well, IMO, ps_insn->ddg_nod
Hi,
can_remove_node_now_p has two thikos in it that makes it to remove aliases of
comdats that eventually may lead to unresolved symbols.
Fixed thus.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- Chang
Hi,
this patch solves second problem seen on libreoffice build. Here cgraph
decides to output
alias, but because assemble_alias still contains the old alias pair path, it
ends up adding
the alias pair that is later discarded and alias not output.
This will be cleaned up once I turn weakrefs to
Giuseppe Scrivano writes:
> 2011-09-13 Giuseppe Scrivano
>
> * reorg.c: Always define make_return_insns.
Thanks, applied.
Richard
On 09/13/2011 10:35 AM, Ed Smith-Rowland wrote:
I need to build a TEMPLATE_ID_EXPR whenever I encounter 1234_suffix.
I need to construct a call
operator"" _suffix<'1','2','3','4'>();
Is make_char_string_pack (const char* str) in cp/parser.c right?
The TREE_TYPE of a NONTYPE_ARGUMENT_PACK is no
On 09/13/11 15:05, Richard Sandiford wrote:
> It just feels like checking for trap_if or turning off cross-jumping
> are working around problems in the representation of shrink-wrapped
> functions. There should be something in the IL to say that those
> two blocks cannot be merged for CFI reasons.
On Fri, 9 Sep 2011, Artem Shinkarov wrote:
> Hi, sorry for the delay, I had a lot of other stuff to do.
>
> In the attachment there is a new patch that fixes all the issues
> pointed by Joseph and almost all the issues pointed by Richard. The
> issues that are not fixed are explained further.
Th
Hello,
This patches fixes an ICE on an assert that performs a sanity check on
target_available field of expr_t, which is tri-state: LHS register is
available (1), not available (0) or unknown (-1).
The problem is, when merging expr data of separable exprs with differing
LHSes, we can't claim we k
This patch fixes inherited hidden methods which return a struct
containing hidden fields. This is a rather brute force approach which
just adds a flag saying that hidden fields are OK where needed.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r
As per the subject. Tested by making sure that there were no new
warnings building arm-linux-gnueabi, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/arm/arm.md: Use match_test rather than eq/ne symbol_ref
As per the subject. Tested by making sure that there were no new
warnings building bfin-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/bfin/bfin.md: Use match_test rather than eq/ne symbol_ref
through
As per the subject. Tested by making sure that there were no new
warnings building h8300-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/h8300/h8300.md: Use match_test rather than eq/ne symbol_ref
thro
Jan,
Any testcase do can add?
Graham
As per the subject. Tested by making sure that there were no new
warnings building ia64-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/ia64/itanium2.md: Use match_test rather than eq/ne symbol_ref
As per the subject. Tested by making sure that there were no new
warnings building iq2000-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/iq2000/iq2000.md: Use match_test rather than eq/ne symbol_ref
t
As per the subject. Tested by making sure that there were no new
warnings building m32r-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/m32r/m32r.md: Use match_test rather than eq/ne symbol_ref
through
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/11 11:50, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building h8300-elf, and that there were no changes in the
> assembly output for the C and C++ testsuite. OK to install?
>
> R
As per the subject. Tested by making sure that there were no new
warnings building m68k-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/m68k/m68k.md: Use match_test rather than eq/ne symbol_ref
t
As per the subject. Tested by making sure that there were no new
warnings building mep-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/mep/mep.md: Use match_test rather than eq/ne symbol_ref
throughout
As per the subject. Tested by making sure that there were no new
warnings building microblaze-elf, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/microblaze/microblaze.md: Use match_test rather than
eq/ne
As per the subject. Tested by making sure that there were no new
warnings building mn10300-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/mn10300/mn10300.md: Use match_test rather than eq/ne
symbol_re
As per the subject. Tested by making sure that there were no new
warnings building hppa64-hp-hpux11.23, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/pa/pa.md: Use match_test rather than eq/ne symbol_ref
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/11 11:56, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building m68k-linux-gnu, and that there were no changes in
> the assembly output for the C and C++ testsuite. OK to install?
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/11 11:59, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building mn10300-elf, and that there were no changes in
> the assembly output for the C and C++ testsuite. OK to install?
>
>
As per the subject. Tested by making sure that there were no new
warnings building powerpc-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/rs6000/rs6000.md: Use match_test rather than eq/ne symbol_ref
As per the subject. Tested by making sure that there were no new
warnings building s390-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/s390/s390.md: Use match_test rather than eq/ne symbol_ref
t
On 13 Sep 2011, at 18:48, "Richard Sandiford"
wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building arm-linux-gnueabi, and that there were no changes
> in the assembly output for the C and C++ testsuite. OK to install?
>
> Richard
>
>
> gcc/
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/11 12:01, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building hppa64-hp-hpux11.23, and that there were no
> changes in the assembly output for the C and C++ testsuite. OK to
> inst
As per the subject. Tested by making sure that there were no new
warnings building sh-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/sh/sh.md: Use match_test rather than eq/ne symbol_ref
through
As per the subject. Tested by making sure that there were no new
warnings building sparc-linux-gnu, and that there were no changes
in the assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/sparc/sparc.md: Use match_test rather than eq/ne symbol_ref
As per the subject. Tested by making sure that there were no new
warnings building v850-elf, and that there were no changes in the
assembly output for the C and C++ testsuite. OK to install?
Richard
gcc/
* config/v850/v850.md: Use match_test rather than eq/ne symbol_ref
through
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/11 12:07, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building v850-elf, and that there were no changes in the
> assembly output for the C and C++ testsuite. OK to install?
>
> Ri
Similar to the last patch, this fixes inherited hidden methods with
arguments of hidden types. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 4905b2cc2083 go/expressions.cc
--- a/go/expressions.cc Tue Sep 13 10:18:45 2011 -0700
+++ b/go/express
On 9/13/2011 2:04 PM, Jeff Law wrote:
Though I wonder if we could kill TARGET_PORTABLE_RUNTIME which would
simplify some of this stuff. I guess the pa-linux folks probably use
this stuff:(
I don't think it is used much if at all. There were a couple of parisc
portables (tadpole?)
that had some
From: Richard Sandiford
Date: Tue, 13 Sep 2011 19:06:20 +0100
> As per the subject. Tested by making sure that there were no new
> warnings building sparc-linux-gnu, and that there were no changes
> in the assembly output for the C and C++ testsuite. OK to install?
>
> Richard
>
>
> gcc/
>
A small tweak to clarify what we mean when the code reads 'if (pph_out_file)'.
For the next patch I'm writing, I'm using this, so I'm flushing it first.
Tested on x86_64. Applied.
Diego.
c-family/ChangeLog.pph
* c-opts.c (pph_reader_enabled_p): Rename from query_have_pph_map.
On 9/09/2011, at 6:54 AM, Bernd Schmidt wrote:
> On 09/06/11 23:56, Maxim Kuvyrkov wrote:
>> I agree. I would rather remove the entirety of haifa-sched.c:
>> check_cfg(); scheduler is not the right place for checking
>> consistency of CFG. Check_cfg() was useful for debugging scheduler
>> patche
On 09/13/11 19:49, Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building bfin-elf, and that there were no changes in the
> assembly output for the C and C++ testsuite. OK to install?
Sure!
Bernd
This script is the result of the discussion I started last week about
having the ability to ignore testsuite failures
(http://gcc.gnu.org/ml/gcc/2011-09/msg00044.html).
The script is contrib/testsuite-management/validate_failures.py. It
is meant to be executed from the top build directory.
When
On 9 September 2011 13:56, Richard Sandiford
wrote:
> Ping for this patch:
>> This is the NEON part of the patch to handle address register writeback
>> in the Cortex A8 and A9 schedulers. Although I can find no documentation
>> to say exactly how this is handled by the pipelines, a latency of 1
The Go frontend was carefully checking for a nil receiver in a value
method, and setting the value to zero in that case. This is wrong: a
nil receiver passed to a value method should crash. This patch fixes
this, by simply removing the unnecessary generated code. Bootstrapped
and ran Go testsuit
C6X has some rather nifty hardware support for modulo scheduling.
Consider the following loop:
.L13:
ldh .d1t1 *++A5[1], A7
|| add .s1 -1, A0, A0
ldh .d2t1 *B5++[1], A8
nop 1
[A0]b .s1 .L13
This makes haifa-sched capable of acting like a modulo-scheduler in
cooperation with a caller (expected to be in a port's md_reorg). As
explained in [0/4], most of the necessary code is already there in form
of the delay slot support that was added for C6X.
The main new entry point is set_modulo_p
This is just some code rearrangement to make it possible for c6x.c to
call schedule_ebbs_init, schedule_ebb and schedule_ebbs_finish.
Bernd
* sched-ebb.c (schedule_ebb): No longer static. Remove declaration.
New arg modulo_scheduling. All callers changed. Move note handling
This fixes an oversight that led to a compare-debug failure in the
testsuite with the other changes applied. We really don't care if a
DEBUG_INSN uses the iteration register or not.
Will commit soon as obvious.
Bernd
* hw-doloop.c (scan_loop): Compute register usage only for non-debug
NULL requires a MOLD argument if the mold cannot be determined from the
context:
a) print *, null() - was ICEing
b) call foo(null()) - [implicit interface] was accepted but no dummy is
available to get the type
c) call generic(null()) - need to reject it, if it would match several
specific f
This is the final piece that makes use of the new haifa-sched
functionality in c6x.c. It also makes use of the hw-doloop code which I
adapted from Blackfin a while ago.
After finding a candidate loop, the hwloop_optimize function unrolls it
to a suitable degree, then tries successive values for II
On Wed, Sep 14, 2011 at 12:01 AM, Bernd Schmidt wrote:
> This is just some code rearrangement to make it possible for c6x.c to
> call schedule_ebbs_init, schedule_ebb and schedule_ebbs_finish.
>
> +/* The one entry point in this file. */
> +
> +void
> +schedule_ebbs (void)
> +{
Might want to upd
This patch fixes two bugs which cause an internal compiler error in
annotalysis. The first change fixes a failure when a variable is
typecast from an unknown (forward-defined) type. The second change
fixes a case in which an assert was triggered, because subexpressions
were not canonicalized corr
On Wed, Sep 14, 2011 at 12:12:36AM +0200, Tobias Burnus wrote:
> NULL requires a MOLD argument if the mold cannot be determined from the
> context:
>
> a) print *, null() - was ICEing
> b) call foo(null()) - [implicit interface] was accepted but no dummy is
> available to get the type
> c) cal
Greetings,
The code to build scops (static control parts) for graphite first
rewrites loops into canonical loop-closed SSA form. PR50183 identifies
a scenario where the results do not fulfill all required invariants of
this form. In particular, a value defined inside a loop and used
outside that
On Tue, Sep 13, 2011 at 2:02 PM, Richard Sandiford
wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building powerpc-linux-gnu, and that there were no changes
> in the assembly output for the C and C++ testsuite. OK to install?
>
> Richard
>
>
> gcc/
>
On Sat, Sep 03, 2011 at 02:44:07PM +0200, Uros Bizjak wrote:
> On Wed, Aug 31, 2011 at 6:16 PM, Michael Matz wrote:
>
> > I'd like to have tighter control over the individual situations that
> > -mrecip handles, and I think the user might appreciate this too. Hence
> > I've introduced four new t
On Sat, Sep 03, 2011 at 11:11:37PM +0200, Uros Bizjak wrote:
> On Sat, Sep 3, 2011 at 5:42 PM, Michael Matz wrote:
>
> >> > I've decided to not use four new bits from target_flags, and instead
> >> > created a new mask (recip_mask). Four bits would have fit in target
> >> > bits right now, but
Richard Sandiford wrote:
> As per the subject. Tested by making sure that there were no new
> warnings building sh-linux-gnu, and that there were no changes
> in the assembly output for the C and C++ testsuite. OK to install?
OK. Thanks!
Regards,
kaz
Here comes a patch to change the case g++.dg/abi/local1.C to be expected
failure for ARM target.
In "C++ ABI for the ARM architecture", it says,
This runs contrary to §2.9.1 of [GC++ABI] which states:
It is intended that two type_info pointers point to equivalent ty
Since we're starting to come up on the end of stage 1, I'll go ahead and
review the current patch even though it isn't finished yet. Thanks for
all your work on this, it definitely seems to be coming together.
On 09/13/2011 10:35 AM, Ed Smith-Rowland wrote:
+#define CPP_N_USERDEF 0x100 /
Steve Kargl wrote:
I was wondering if we need to change the error message
in the following code to include procedure pointer?
+ gfc_error ("'%s' argument of '%s' intrinsic at %L must be a POINTER or "
+"ALLOCATABLE", gfc_current_intrinsic_arg[0]->name,
gfc_
68 matches
Mail list logo
