Hi,
The linker should do endian swizzling at link-time according to "--be8"
option.
This patch modifies BE8_LINK_SPEC by adding cortex-m processors in the specs
string.
Since R-profile supports configurable big-endian instruction fetch, I didn't
include it here.
Is it ok? Thanks.
2011-09-15 Che
Hi,
Bug PR46934 exists on all thumb1 targets, for example cortex-m0.
This patch removes "-march=armv5te" option for testcase pr46934.c,
allowing the test to be run on all thumb1 targets, not just armv5te.
Is it ok? Thanks.
gcc/testsuite/ChangeLog:
2011-09-15 Cheng Bin
* gcc.targe
The GCC version we use internally to build 4.6 treats unused variable
warnings as errors. This was causing bootstraps to fail.
Tested on x86_64. Committed to gcc-4_6-branch.
* tree-vect-stmts.c (vect_transform_stmt): Remove unused
local variable ORIG_SCALAR_STMT.
Index: tree-
While testing the altest iteration of shrink-wrapping on mips-elf, a new
failure showed up in gcc.dg/pr43139.c. When restoring floating-point
registers, we attach REG_CFA_RESTORE notes for DFmode registers, but the
dwarf2cfi code only records a single regno for such a multiword hard reg.
Fixed wit
On 09/13/2011 08:36 AM, Bernd Schmidt wrote:
> 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 th
The Go frontend was mishandling structs with embedded builtin types, as
in
struct {
int
}
This is because builtin type names are not packed with the package name,
whereas field names are. Rather than try to sort out that confusion, I
just added another hack around it. Bootstrapped and r
On 09/14/2011 04:50 AM, Dodji Seketeli wrote:
To comply with this invariant, the initial patch of Tom was cloning T
into T', and was using T'->src_loc to track the virtual location of T.
Which is close to what you are proposing, while respecting the
invariant.
Yes, that's what I had in mind. I
On 09/13/2011 04:27 PM, Michael Meissner wrote:
> This patch touches a bunch of files, but most of the changes are fairly
> mechanical. What this does is change the infrastructure of how machine
> independent builtin functions are handled. At this point, there is no change
> to the compiler from
On 09/13/2011 10:14 PM, Paolo Carlini wrote:
Hi,
To rebase would have forced me to delay the patch of one day which I try to
avoid... without success. Here it is again.
Sorry about that, I was annoyed seeing a bit of - surely, trivial - work I had
done on the orig patch nullified. Thanks
> Would a testcase from PR50226 suffice?
Sure, fell free to commit it!
Honza
The Go defer/panic/recover handling works through a little dance that
includes comparing return addresses to see if a particular call to
recover should pick up a particular call to panic. This dance only
works if the appropriate functions are not inlined. I messed up the
condition for whether the
Patrick Marlier writes:
> Here the error when gcc compiles libitm:
>
> ../../../transactional-memory/libitm/aatree.h: In constructor
> ‘GTM::aa_node_base::aa_node_base(GTM::aa_node_base::level_type)’:
> ../../../transactional-memory/libitm/aatree.h:53:16: error:
> list-initializer for non-class t
Would a testcase from PR50226 suffice?
Since v3.82, make issued some strange warning on duplicated targets. It
turns out that those were due to a leading space hidden in CUMULMD5
variable, leading to target breakage.
---
gcc/ChangeLog.MELT |4
gcc/melt-build.mk | 18 +-
gcc/melt-build.tpl |2 +-
3 files
Hi,
> The attached patch fixes PR50322.
>
> The test-case is supposed to succeed if the loop counter data-type has the
> same
> size as a pointer. The patch defines TYPE to be an int datatype of the same
> size
> as a pointer, and uses it. After this fix, there's no need for the avr xfails
> an
On 09/14/2011 05:44 PM, Richard Sandiford wrote:
> A SUBREG may not be REG nor CONSTANT. Don't you need
> to check REG_P/CONSTANT_P on SUBREG?
Yeah, good point. There should be a "&& REG_P (SUBREG_REG (new_rtx))"
in there. Probably also worth checking for non-paradoxical subregs.
I was g
On Wed, Sep 14, 2011 at 02:33:12PM +, Joseph S. Myers wrote:
> On Tue, 13 Sep 2011, Michael Meissner wrote:
>
> > implicit_built_in_decls to the new macros/functions, and poison
> > the old names. Make sure 0 is not a legitimate builtin index.
>
> I think the poisoning belongs in syst
On Tue, Sep 13, 2011 at 18:27, Delesley Hutchins wrote:
> 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
Added myself to MAINTAINERS (write after approval).
Thanks,
- Tom
2011-09-14 Tom de Vries
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 178804)
+++ MAINTAINERS (working
"H.J. Lu" writes:
> On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
> wrote:
>> At the moment, fwprop will propagate constants and registers
>> even if no further rtl simplifications are possible:
>>
>> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
>> flags |= PR_CAN_APPEAR;
>>
>> What do y
OK.
Jason
On 09/13/2011 10:58 AM, Richard Sandiford wrote:
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?
OK.
--
Michael Eagerea...@eagercon.com
19
On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
wrote:
> At the moment, fwprop will propagate constants and registers
> even if no further rtl simplifications are possible:
>
> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
> flags |= PR_CAN_APPEAR;
>
> What do you think about extending this
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags |= PR_CAN_APPEAR;
What do you think about extending this to subregs? The reason for
asking is that on NEON, vector loads like
On Wed, 14 Sep 2011, Jiangning Liu wrote:
> +// { dg-do run { xfail { arm*-*-eabi* } } }
That's specific to bare-metal targets rather than all ARM EABI (such as
arm-none-linux-gnueabi or arm-none-symbianelf), is that your intent? If
you wanted to cover all ARM EABI targets you'd use the arm_ea
On Tue, 13 Sep 2011, Michael Meissner wrote:
> implicit_built_in_decls to the new macros/functions, and poison
> the old names. Make sure 0 is not a legitimate builtin index.
I think the poisoning belongs in system.h; direct dependencies on the host
compiler (such as GCC_VERSION and
On Fri, 6 May 2011 14:13:32 +0100
Julian Brown wrote:
> Hi,
>
> This is the second of two patches to add unaligned-access support to
> the ARM backend. It builds on the first patch to provide support for
> unaligned accesses when expanding block moves (i.e. for builtin memcpy
> operations). It m
Since v3.82, make issued some strange warning on duplicated targets. It
turns out that those were due to a leading space hidden in CUMULMD5
variable, leading to target breakage.
---
gcc/ChangeLog.MELT |4
gcc/melt-build.mk | 18 +-
gcc/melt-build.tpl |2 +-
3 files
Hi,
here I'm just avoiding calling build_exception_variant when specs is an
error_mark_node.
Tested x86_64-linux. Ok for mainline?
Thanks,
Paolo.
/
/cp
2011-09-14 Paolo Carlini
PR c++/50391
* pt.c (regenerate_decl_from_template): Don't pass an error_ma
neon_vget_high and neon_vget_low extract one half of a vector.
The patterns look like:
(define_insn "neon_vget_highv16qi"
[(set (match_operand:V8QI 0 "s_register_operand" "=w")
(vec_select:V8QI (match_operand:V16QI 1 "s_register_operand" "w")
(parallel [(const_in
Eric Botcazou writes:
>> Tested on arm-linux-gnueabi and x86_64-linux-gnu. Although I suppose
>> I could self-approve this, I'd appreciate it if someone would double-check.
>>
>> Richard
>>
>>
>> gcc/
>> * simplify-rtx.c (simplify_subreg): Check that the inner mode is
>> a scalar intege
Hi,
This patch makes data-refs analysis to not fail if simple_iv returns
false in basic block SLP.
Bootstrapped and tested on powerpc64-suse-linux.
OK for mainline?
Thanks,
Ira
ChangeLog:
* tree-data-ref.c (dr_analyze_innermost): Rename to...
(dr_analyze_innermost_1): ... this. Add
Mike,
Zdenek,
The attached patch fixes PR50322.
The test-case is supposed to succeed if the loop counter data-type has the same
size as a pointer. The patch defines TYPE to be an int datatype of the same size
as a pointer, and uses it. After this fix, there's no need for the avr xfails
anymore.
On Tue, 13 Sep 2011 21:44:54 +0100
Ramana Radhakrishnan wrote:
> On 9 September 2011 13:56, Richard Sandiford
> wrote:
> > Ping for this patch:
>
> I do have a one nit on the ml bit though I must say I'm not an ML
> expert which is why I resisted for a while. The one comment that I
> have and I
On 09/14/11 11:03, Richard Sandiford wrote:
> ...I didn't see from an admittedly quick read of the patch how you
> handle memory disambiguation between iterations. If a loop includes:
>
> lb $3,($4)
> sb $5,1($4)
>
> then the two instructions can be reordered by normal ebb scheduling,
On Wed, Sep 14, 2011 at 10:20 AM, Tom de Vries wrote:
this patch fixes PR50251, which was caused by r178353.
The patch was bootstrapped and reg-tested on i686 and x86_64.
On i686, the test-cases reported failing in PR50251 pass again.
The patch selects the DRAP type
Bernd Schmidt writes:
> I have added support for this to haifa-sched.c. I expect the question
> "why not use SMS" to come up; there were a number of reasons why I felt
> that code is unsuitable:
Fully agree that SMS is unsuitable here FWIW, but...
> There are (or were, when I started) some glari
> Jan,
>
> Any testcase do can add?
Sadly not really - in both cases (openoffice and mozilla) the modules involved
are too large for testsuite.
I tried to delta it but didn't get anything useful (about 100k of C++)
Honza
>
> Graham
Hi,
I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
The followings does not currently trigger the PLUGIN_FINISH_DECL
(or not in all cases), but should them ?
- function parameters (in the function prototype)
- definition (with a function body) of a top-level function (whil
Iain,
> So is the following OK for trunk?
> (no Ada regressions on *-darwin9, x86_64-darwin10).
>
> cheers
> Iain
>
> ada:
>
> * gcc-interface/Makefile.in (darwin): Do not issue the
> '-flat_namespace' linker flag during Ada build.
>* mlib-tgt-specific-darwin.adb: Remove 'f
> gcc/
> * config/s390/s390.md: Use match_test rather than eq/ne symbol_ref
> throughout file.
This is ok. Thanks!
-Andreas-
> Tested on arm-linux-gnueabi and x86_64-linux-gnu. Although I suppose
> I could self-approve this, I'd appreciate it if someone would double-check.
>
> Richard
>
>
> gcc/
> * simplify-rtx.c (simplify_subreg): Check that the inner mode is
> a scalar integer before applying integer-only
On 14 September 2011 08:47, Richard Sandiford
wrote:
> Ramana Radhakrishnan writes:
>> I do have a one nit on the ml bit though I must say I'm not an ML
>> expert which is why I resisted for a while. The one comment that I
>> have and I should have realized earlier was that the file had been
>> p
On 09/04/2011 03:44 PM, Tom de Vries wrote:
> On 09/04/2011 11:10 AM, Richard Guenther wrote:
>> On Sun, Sep 4, 2011 at 11:00 AM, Tom de Vries wrote:
>>> Hi,
>>>
>>> this patch fixes PR50251, which was caused by r178353.
>>>
>>> The patch was bootstrapped and reg-tested on i686 and x86_64.
>>> On
Eric, this is a preliminary version of the FMA patch I've been
working on. Just so you can see what I'm doing.
First, ignore the fact that there are two configure tests for the
presence of support for these instructions. I'm busy normalizing the
-xarch options which binutils supports so that th
Ramana Radhakrishnan writes:
> I do have a one nit on the ml bit though I must say I'm not an ML
> expert which is why I resisted for a while. The one comment that I
> have and I should have realized earlier was that the file had been
> parameterized by the core in quite a few places and I would l
46 matches
Mail list logo
