On 23/06/11 17:26, Richard Guenther wrote:
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs wrote:
There are many cases where the widening_mult pass does not recognise
widening multiply-and-accumulate cases simply because there is a type
conversion step between the multiply and add statements.
T
Hi,
This patch adds a builtin macro __ARM_FEATURE_DSP which is defined
when the ARMv5E DSP multiplication extensions are available for use.
Thanks,
James Greenhalgh
2011-06-22 James Greenhalgh
* TARGET_CPU_CPP_BUILTINS: Add __ARM_FEATURE_DSP.
diff --git gcc/config/arm/arm.h gcc/confi
On Thu, Jun 23, 2011 at 8:23 PM, Hans-Peter Nilsson
wrote:
> Here's the patch I tested for 4.6, native
> x86_64-unknown-linux-gnu, cross to cris-axis-elf, both with old
> and new ("breaking") newlib.
>
> Ok for 4.6 and after testing, earlier branches?
Ok for 4.6.2 and 4.5.
Thanks,
Richard.
>
>
On Thu, Jun 23, 2011 at 9:53 PM, Martin Jambor wrote:
> Hi,
>
> When SRA tries to modify an assignment where on one side it should put
> a new scalar replacement but the other is actually an aggregate with
> a number of replacements for it, it will generate MEM-REFs into the
> former replacement w
Apologies, I sent an incomplete ChangeLog entry.
Thanks,
James Greenahlgh
2011-06-22 James Greenhalgh
* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Add
__ARM_FEATURE_DSP.
> Hi,
>
> This patch adds a builtin macro __ARM_FEATURE_DSP which is defined
> when the ARMv5E DSP mult
On Thu, Jun 23, 2011 at 11:47 PM, Easwaran Raman wrote:
> On Thu, Jun 23, 2011 at 12:16 PM, Jakub Jelinek wrote:
>> On Thu, Jun 23, 2011 at 12:02:35PM -0700, Easwaran Raman wrote:
>>> + if (y_expr)
>>> + mark_addressable (y_expr);
>>
>> Please watch formatting, a tab should be used in
On Fri, Jun 24, 2011 at 10:05 AM, Andrew Stubbs
wrote:
> On 23/06/11 17:26, Richard Guenther wrote:
>>
>> On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs
>> wrote:
>>>
>>> There are many cases where the widening_mult pass does not recognise
>>> widening multiply-and-accumulate cases simply because
> I just don't see how nonzero_bits1 can assume if pointers extend unsigned
> and this is an addition or subtraction to a pointer in Pmode, all the bits
> bove ptr_mode are known to be zero. We never run into it before x32
> since x32 is the first such target.
I agree that this is overly optimist
Hi, Ramana and Joseph,
Thank you for your reviewing! Sorry for the late response.
Before I submit the new modified patch, I want to make something more specific.
> The -mwmmxt option is not acceptable as it stands today. IIRC the msimd
> option was the plan long term when we talked about this
On 18/06/11 20:02, Richard Henderson wrote:
> I couldn't find anything terribly tricky about the conversion.
>
> The existing push_mult pattern would service thumb1 with just
> a tweak or two to the memory predicate and the length.
>
> The existing emit_multi_reg_push wasn't set up to handle a
>
On Thu, 23 Jun 2011, Janis Johnson wrote:
> Tests target/arm/vfp-ldm*.c and vfp-sdm*.c add -mfloat-abi=softfp but
> fail if multilib flags override that option. This patch skips the test
> for multilibs that specify a different value for -mfloat-abi.
While they need to be skipped for -mfloat-abi
On 06/24/2011 12:07 AM, Janis Johnson wrote:
> On 06/23/2011 02:56 PM, Ramana Radhakrishnan wrote:
>> On 23 June 2011 22:36, Janis Johnson wrote:
>>> Tests gcc.target/arm/ivopts*.c add -mthumb but fail on targets without
>>> thumb support; skip those targets. The tests save temporary files and
>>
Hi,
I also tested the attached variant that simply disable the builtins streaming.
It fixes the testcase, too, bootstraps/regtestes x86_64 with and without plugin
and builds mozilla. It also solves the decl sharing problems that leads to
debug info confussion.
However it breaks memops-asm.c testcas
Hello,
This patch completes the pragma support in MELT. Now, a plugin can
register several pragmas (with different name) in the following format
(for GCC > 4.6):
#pragma MELT (,...).
This pragma can be easily handle in a MELT function, giving the operator
and the list of arguments as para
On Fri, Jun 24, 2011 at 02:04:20PM +0200, Pierre Vittet wrote:
> Hello,
>
> This patch completes the pragma support in MELT. Now, a plugin can
> register several pragmas (with different name) in the following
> format (for GCC > 4.6):
>
> #pragma MELT (,...).
>
> This pragma can be easily hand
Hi,
this is yet another variant of the fix. This time we stream builtins decls as
usually, but at fixup time we copy the assembler names (if set) into the
builtin decls used by folders. Not sure if it is any better than breaking
memops-asm, but I can imagine that things like glibc actually rename
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.6.0.de.po', has just
On Thu, Jun 23, 2011 at 22:10, Jason Merrill wrote:
> Per DR 115, if the context of a template-id doesn't give enough type
> information to resolve it and the template-id fully resolves exactly one
> specialization, we should use that one. The code in
> resolve_overloaded_unification was trying t
On Thu, Jun 23, 2011 at 22:02, Jason Merrill wrote:
> OK.
>
> Jason
Applied to trunk rev. 175373.
Diego.
On Tue, Jun 21, 2011 at 14:36, Alexandre Oliva wrote:
> On Jun 10, 2011, dnovi...@google.com (Diego Novillo) wrote:
>
>> I'm thinking that this script is better written in python, but that
>> may make it less generic and I don't know whether we accept python in
>> gcc/contrib. Alex?
>
> I guess a
On 24/06/11 01:40, Janis Johnson wrote:
Test gcc.target/arm/pr42093.c, added by Ramana, requires support for
arm_thumb2 but fails for those targets. The patch for which it was
added modified support for thumb1. Should the test instead require
arm_thumb1_ok, as in this patch?
No this is for a
On 24 June 2011 09:20, James Greenhalgh wrote:
> Apologies, I sent an incomplete ChangeLog entry.
This is OK.
cheers
Ramana
On Fri, Jun 24, 2011 at 1:58 AM, Eric Botcazou wrote:
>> I just don't see how nonzero_bits1 can assume if pointers extend unsigned
>> and this is an addition or subtraction to a pointer in Pmode, all the bits
>> bove ptr_mode are known to be zero. We never run into it before x32
>> since x32 is t
On 24/06/11 09:28, Richard Guenther wrote:
>> > To be clear, it only skips past NOP_EXPR. Is it not the case that what
>> > you're describing would need a CONVERT_EXPR?
> NOP_EXPR is the same as CONVERT_EXPR.
Are you sure?
I thought this was safe because the internals manual says:
NOP_EXPR
Hi
This is a ping of
(http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01226.html).
Repeating my request.
I would like to have a stack check for threads with small amount of
stack space per thread.
(I'm using a ARM Cortex-M3 microcontroller with a stack size of a 1
KByte per Thread.)
Each threa
> I compared x32 glibc built with the old x32 gcc against x32 glibc built
> with this patch and
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00913.html
>
> reverted, the new glibc is little smaller:
>
> New:
>
> [hjl@gnu-33 build-x86_64-linux]$ size libc.so
>text data bss d
I committed this patch to remove an entry from gcc/go/ChangeLog. The
file in question is part of the gofrontend which lives in a separate
repository. ChangeLog patches do not themselves get ChangeLog entries.
Ian
Index: ChangeLog
=
On Fri, Jun 24, 2011 at 7:07 AM, Eric Botcazou wrote:
>> I compared x32 glibc built with the old x32 gcc against x32 glibc built
>> with this patch and
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00913.html
>>
>> reverted, the new glibc is little smaller:
>>
>> New:
>>
>> [hjl@gnu-33 build-
Hi!
This patch introduces a new extension, to hint the compiler
that a pointer is guaranteed to be somehow aligned (or misaligned).
It is designed as a pass-thru builtin which just returns its first
argument, so that it is more obvious where we can assume how it is aligned.
Otherwise it is similar
This patch fixes PR 49169, where GCC is incorrectly optimising away
a test for whether a function is Thumb rather than ARM. The patch
was posted by Richard in the PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169
See the PR for a discussion about whether a target hook is better
(or not,
Hi!
On the huge testcase in the PR we ICE, because GC needs too deep recursion.
I've noticed that part of the problem is deep recursion through
TYPE_NEXT_VARIANT pointers.
As TREE_CHAIN on types is TYPE_STUB_DECL, therefore should point
to a different kind of tree and thus isn't really a pointer t
The following patch fixes compilation abort of SPECFP2000 mesa on ppc64.
The patch was successfully bootstrapped on x86-64, ppc64, and ia64.
2011-06-24 Vladimir Makarov
* lra-constraints.c (lra_constraints): Check subreg for equiv init
insn.
Index: lra-constraints.c
===
On 06/24/2011 03:29 AM, Joseph S. Myers wrote:
> On Thu, 23 Jun 2011, Janis Johnson wrote:
>
>> Tests target/arm/vfp-ldm*.c and vfp-sdm*.c add -mfloat-abi=softfp but
>> fail if multilib flags override that option. This patch skips the test
>> for multilibs that specify a different value for -mflo
On 06/24/2011 03:29 AM, Tom de Vries wrote:
> On 06/24/2011 12:07 AM, Janis Johnson wrote:
>> On 06/23/2011 02:56 PM, Ramana Radhakrishnan wrote:
>>> On 23 June 2011 22:36, Janis Johnson wrote:
Tests gcc.target/arm/ivopts*.c add -mthumb but fail on targets without
thumb support; skip tho
>> I introduced 2 new arm-related effective targets to accomplish this.
>> - arm_thumb2: Tests if we're compiling for thumb2.
>> - arm_nothumb: Tests if we're not compiling for any thumb.
>> I don't know how to get the same effect with the existing arm-related
>> effective
>> targets.
>
> That loo
On 06/24/2011 08:03 AM, Ramana Radhakrishnan wrote:
>>> I introduced 2 new arm-related effective targets to accomplish this.
>>> - arm_thumb2: Tests if we're compiling for thumb2.
>>> - arm_nothumb: Tests if we're not compiling for any thumb.
>>> I don't know how to get the same effect with the exi
I backported contrib/repro_fail to google/gcc-4_6. The other
google branches will get it when they start tracking trunk.
* repro_fail: New.
diff --git a/contrib/repro_fail b/contrib/repro_fail
new file mode 100755
index 000..8100456
--- /dev/null
+++ b/contrib/repro_fail
@@ -0,0 +1,8
On Fri, Jun 24, 2011 at 7:17 AM, H.J. Lu wrote:
> On Fri, Jun 24, 2011 at 7:07 AM, Eric Botcazou wrote:
>>> I compared x32 glibc built with the old x32 gcc against x32 glibc built
>>> with this patch and
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00913.html
>>>
>>> reverted, the new gli
On Fri, Jun 24, 2011 at 3:46 PM, Stubbs, Andrew
wrote:
> On 24/06/11 09:28, Richard Guenther wrote:
>>> > To be clear, it only skips past NOP_EXPR. Is it not the case that what
>>> > you're describing would need a CONVERT_EXPR?
>> NOP_EXPR is the same as CONVERT_EXPR.
>
> Are you sure?
Yes, def
On Fri, Jun 24, 2011 at 4:42 PM, Richard Sandiford
wrote:
> This patch fixes PR 49169, where GCC is incorrectly optimising away
> a test for whether a function is Thumb rather than ARM. The patch
> was posted by Richard in the PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169
>
> See t
Hello,
The function meltgc_read_from_val (in melt-runtime.c) takes two
arguments, a string value and a second one which is a location.
In the comments, it is written that we can pass a NULL pointer if we
have no location (it is a direct string). However, this conduct MELT to
crash because it d
On 24/06/11 16:47, Richard Guenther wrote:
>> > I can certainly add checks to make sure that the skipped operations
>> > actually don't make any important changes to the value, but do I need to?
> Yes.
Ok, I'll go away and do that then.
BTW, I see useless_type_conversion_p, but that's not quite
This was commited to trunk. Diego can you commit this patch to pph as well?
Thanks,
Gab
On Thu, Jun 23, 2011 at 4:07 AM, Diego Novillo wrote:
> On Wed, Jun 22, 2011 at 20:17, Gabriel Dos Reis
> wrote:
>> On Wed, Jun 22, 2011 at 7:05 PM, Gabriel Charette wrote:
>>> And it looks like this wasn't
The following patch fixes compilation abort of SPEC2000 crafty on ppc64.
The patch was successfully bootstrapped on x86-64, ppc64, and ia64.
2011-06-24 Vladimir Makarov
* lra-constraints.c (curr_insn_transform): Process operator
duplications.
Index: lra-constraints.c
On Fri, 24 Jun 2011, Jakub Jelinek wrote:
> * c-decl.c (union lang_tree_node): Use TYPE_NEXT_VARIANT
> instead of TYPE_CHAIN for chain_next for types.
The C changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 2011/06/24 17:35:51, Gabriel Charette wrote:
This was commited to trunk. Diego can you commit this patch to pph as
well?
Done. r175387.
Diego.
http://codereview.appspot.com/4634071/
On 06/20/2011 05:18 PM, Joseph S. Myers wrote:
> On Mon, 20 Jun 2011, Matthias Klose wrote:
>
>> - PR45078; vxworks-dummy.h is included for cpu_type in arm,
>>i386, mips, sh and sparc but only installed when it's i386; copy it
>>manually anytime.
>
> I don't think you should list particu
On Fri, 24 Jun 2011, Matthias Klose wrote:
> On 06/20/2011 05:18 PM, Joseph S. Myers wrote:
> > On Mon, 20 Jun 2011, Matthias Klose wrote:
> >
> >> - PR45078; vxworks-dummy.h is included for cpu_type in arm,
> >>i386, mips, sh and sparc but only installed when it's i386; copy it
> >>manu
On 06/24/2011 08:33 AM, Diego Novillo wrote:
Patch missing.
Oopt.
commit 124387ceea38a3c0204c9f91d17bbfa68063d42e
Author: Jason Merrill
Date: Wed Jun 22 16:07:10 2011 -0400
PR c++/35255
* pt.c (resolve_overloaded_unification): Fix DR 115 handling.
diff --git a/gcc/cp/pt.c b/gcc/c
OK.
Jason
On 06/24/2011 07:43 AM, Jakub Jelinek wrote:
> + chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic),
> TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT (&%h.generic))
> : CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) ? ((union
> lang_tree_node *) TREE_CHAIN
We were only streaming the first field of every struct. Struct fields have a
chain link to the next field, thus we need to stream the DECL_CHAIN of every
field as well recursively.
I limited this to VAR_DECL and FUNCTION_DECL for now (which fixes all of our
current bugs in regards to the struct
Fixes two pph BOGUS bugs which now result in an asm diff.
Tested with bootstrap build and pph regression testing.
http://codereview.appspot.com/4631072/
Hi,
I have no preference in tune feature coding. But I agree with you it's better
to
put similar things together. I modified the code following your suggestion.
Is it OK to commit this modified patch?
Thanks,
Changpeng
From: Jan Hubicka [hubi...@ucw
The following patch solves a bug which results in a wrong code
generation of Maeno's algorithm of matrix multiplications on x86.
The patch was successfully bootstrapped on x86, ppc64, ia64.
2011-06-24 Vladimir Makarov
* lra-constraints.c (extract_loc_address_regs): Add an argument.
Hello All,
When cc1 report timing, the timing variable name has a too short width for df
reg dead/unused notes:
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1089 kB ( 1%) ggc
trivially dead code : 0.02 ( 1%) usr 0.00 ( 0%) sys
56 matches
Mail list logo
