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
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
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
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
> 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
> gcc/
> * config/s390/s390.md: Use match_test rather than eq/ne symbol_ref
> throughout file.
This is ok. Thanks!
-Andreas-
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
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
> 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
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
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
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 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
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.
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
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
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
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
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
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
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 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
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, 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
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
OK.
Jason
"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
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
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
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 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
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
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
Would a testcase from PR50226 suffice?
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
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
> Would a testcase from PR50226 suffice?
Sure, fell free to commit it!
Honza
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
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/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
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/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
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
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-
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
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
46 matches
Mail list logo
