On 10/04/2011 01:00 AM, H.J. Lu wrote:
+ else
+{
+ /* Improve address combine in x32 mode. */
+ if (TARGET_X32
+ && code == PLUS
+ && !MEM_P (dst)
+ && !MEM_P (src1)
+ && MEM_P (src2) )
+ src2 = force_reg (mode, src2);
+}
Perhaps this is wor
Richard,
The following patch fixes a CFG consistency problem.
When early IPA optimizations (e.g., early SRA) create a version of a function
that no longer throws, versioning machinery deletes EH landings pads in
_callers_ of the function [*]. However, the EH cfg edges are not updated in
the c
Hi,
Michael pointed out this problem in
check_effective_target_vect_multiple_sizes and
check_effective_target_vect64 that I added lately.
Tested on powerpc64-suse-linux.
Committed as obvious.
Thanks,
Ira
testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_multip
Tested on SPARC/Solaris, applied on the mainline.
2011-10-04 Eric Botcazou
* config/sparc/sparc.c (sparc_fold_builtin): Use a sequence of tests.
--
Eric Botcazou
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c
On 10/01/2011 05:46 PM, Tom de Vries wrote:
> On 09/30/2011 03:29 PM, Richard Guenther wrote:
>> On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries wrote:
>>> On 09/28/2011 11:53 AM, Richard Guenther wrote:
On Wed, Sep 28, 2011 at 11:34 AM, Tom de Vries
wrote:
> Richard,
>
> I g
Ayal Zaks writes:
> On Wed, Sep 28, 2011 at 4:53 PM, Richard Sandiford
> wrote:
>> Ayal Zaks writes:
> Only request is to document that the register moves are
> placed/assigned-id's in a specific order.
I suppose this is the downside of splitting the patches up, sorry,
but t
On Tue, Oct 4, 2011 at 8:17 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 1:00 AM, H.J. Lu wrote:
>> This patch improves address combine for x32 by forcing the memory memory
>> operand of PLUS operation into register. Tested on Linux/x86-64 with
>> -mx32. OK for trunk?
>
> Does the patch fix
On Tue, Oct 4, 2011 at 10:06 AM, Uros Bizjak wrote:
>>> This patch improves address combine for x32 by forcing the memory memory
>>> operand of PLUS operation into register. Tested on Linux/x86-64 with
>>> -mx32. OK for trunk?
>>
>> Does the patch fix
>>
>> FAIL: gcc.target/i386/pr45670.c scan-a
On Fri, 30 Sep 2011, Rainer Orth wrote:
> It seems that the following three tests don't fail anymore anywhere for
> some time, so the following patch removes the three xfail's to avoid the
> noise from XPASSes.
>
> Tested with the approrpriate runtest invocation on i386-pc-solaris2.11.
>
> Ok fo
On Fri, 30 Sep 2011, Joseph S. Myers wrote:
> On Mon, 26 Sep 2011, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Adding Joseph and Jason to CC.
> >
> > On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > > Let's see what kind of fallout we get ;) For example, if the
> > > following
On Fri, 30 Sep 2011, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 10:57:25AM +0200, Richard Guenther wrote:
> > Definitely. Seeing a decl will enable better offset-based
> > disambiguation.
>
> Ok, here is an updated patch. Bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk
On Sun, 2 Oct 2011, David Miller wrote:
> We always use "Sparc" instead of "SPARC" for the cpu names output
> by the kernel in /proc/cpuinfo.
Ah, I see. Thanks for the explanation.
What confused me a bit is that a bit earlier in the same table
there is one (and just one) entry using "SPARC":
On Mon, 3 Oct 2011, H.J. Lu wrote:
> I checked it in.
Thanks, H.J.
This needed a small markup fix which I just applied; see below.
Gerald
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving r
On Mon, 3 Oct 2011, Jan Hubicka wrote:
> Hi,
> this patch makes us to stream out and stream in the order fields of cgraph
> correctly, so -fno-toplevel-reorder works within single compilation unit
> with -flto-partition=none.
>
> This is currently needed to build kernel with LTO and it is useful
PING 4: For review
Hi,
Can someone please review the patch:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01441.html
The previous discussion about the patch can be referred in the earlier
communication below.
Thanks,
Jayant Sonar
= Begin Message ==
-Original Message-
From: S
Artem Shinkarov schrieb:
> On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek wrote:
>> On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
>>> Most likely we can. The question is what do we really want to check
>>> with this test. My intention was to check that a programmer can
>>> stati
On Tue, Oct 04, 2011 at 11:01:27AM +0200, Richard Guenther wrote:
> > > > void foo (int *p)
> > > > {
> > > > int * __restrict p1 = p;
> > > > int * __restrict p2 = p + 32;
> > > > int *q;
> > > > int i;
> > > > for (i = 0; i < 32; ++i)
> > > > p1[i] = p2[i];
> > > > p = p1;
> >
On Tue, Oct 04, 2011 at 11:32:37AM +0200, Georg-Johann Lay wrote:
> The patch from
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg02060.html
> http://gcc.gnu.org/ml/gcc-patches/2011-09/txt00337.txt
> works for me.
>
> If it's ok from maintainer I can apply it for you.
It is fine with a suitab
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 11:01:27AM +0200, Richard Guenther wrote:
> > > > > void foo (int *p)
> > > > > {
> > > > > int * __restrict p1 = p;
> > > > > int * __restrict p2 = p + 32;
> > > > > int *q;
> > > > > int i;
> > > > > for (i = 0; i <
On Monday 03 October 2011 21:23:43, Joseph S. Myers wrote:
> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>
> > On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
> > > On Fri, 30 Sep 2011, Tristan Gingold wrote:
> > >
> > > > If you prefer a target hook, I'm fine with that. I will write such a
> > > > pat
Jakub Jelinek schrieb:
> On Tue, Oct 04, 2011 at 11:32:37AM +0200, Georg-Johann Lay wrote:
>> The patch from
>> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg02060.html
>> http://gcc.gnu.org/ml/gcc-patches/2011-09/txt00337.txt
>> works for me.
>>
>> If it's ok from maintainer I can apply it for
On Tue, Oct 04, 2011 at 11:55:17AM +0200, Richard Guenther wrote:
> > On Tue, Oct 04, 2011 at 11:01:27AM +0200, Richard Guenther wrote:
> > > > > > void foo (int *p)
> > > > > > {
> > > > > > int * __restrict p1 = p;
> > > > > > int * __restrict p2 = p + 32;
> > > > > > int *q;
> > > > >
On Oct 4, 2011, at 11:59 AM, Pedro Alves wrote:
> On Monday 03 October 2011 21:23:43, Joseph S. Myers wrote:
>> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>>
>>> On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
On Fri, 30 Sep 2011, Tristan Gingold wrote:
> If you prefer a target hook, I'
Hi everyone,
This patch fixes PR 50038 (redundant zero extensions) by modifying
implicit-zee pass
to also remove unneeded zero extensions from QImode to SImode.
There is 6% improvement in rgbyiqv test from EEMBC 2.0 benchmark on x86-64.
I am not sure if this is correct approach ( tom modify impl
On Tue, Oct 4, 2011 at 4:59 AM, Pedro Alves wrote:
> On Monday 03 October 2011 21:23:43, Joseph S. Myers wrote:
>> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>>
>> > On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
>> > > On Fri, 30 Sep 2011, Tristan Gingold wrote:
>> > >
>> > > > If you prefer a target
> From: Andi Kleen
>
> Currently when reading in LTO sections from ld -r files they can
> get randomly reordered based on hash tables and random IDs.
> This causes reordering later when the final code is generated and
> also makes crashes harder to reproduce.
>
> This patch maintains explicit li
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 11:55:17AM +0200, Richard Guenther wrote:
> > > On Tue, Oct 04, 2011 at 11:01:27AM +0200, Richard Guenther wrote:
> > > > > > > void foo (int *p)
> > > > > > > {
> > > > > > > int * __restrict p1 = p;
> > > > > > > int * __
On Tue, 4 Oct 2011, Jan Hubicka wrote:
> > From: Andi Kleen
> >
> > Currently when reading in LTO sections from ld -r files they can
> > get randomly reordered based on hash tables and random IDs.
> > This causes reordering later when the final code is generated and
> > also makes crashes harder
Hi,
the attached patch fixes the smul_ppmm and sdiv_qrnnd patterns for
zarch. Underscores were missing in local variables. DR referenced
the wrong operand and the source and result regs were swapped.
Tested on s390 with -mzarch.
Applied to 4.6 and mainline.
Bye,
-Andreas-
2011-10-04 Andre
On 09/25/11 19:16, Richard Sandiford wrote:
> The last bit is indirect, via a new HARD_REG_SET called operand_reg_set.
> And this set is the reason why I'm sending the patch now. The MIPS16 port
> has always had a problem with the HI and LO registers: they can only be
> set by multiplication and d
On Tuesday 04 October 2011 11:16:30, Gabriel Dos Reis wrote:
> > Do we need to consider ABIs that have calling conventions that
> > treat unprototyped and varargs functions differently? (is there any?)
>
> Could you elaborate on the equivalence of these declarations?
I expected that with:
ext
Hi!
The following testcase ICEs on the trunk, as strlen optimization was
assuming memcpy arguments will have expected type (size_type_node),
but they had ssizetype instead. The following patch fixes it
both in the builtins.c folders that create memcpy and also in the
strlen pass to no longer assu
2011/10/2 Jan Hubicka :
>> > Index: tree-sra.c
>> > ===
>> > *** tree-sra.c (revision 179423)
>> > --- tree-sra.c (working copy)
>> > *** modify_function (struct cgraph_node *nod
>> > *** 4622,4627
>> > --- 4622,4628
On Monday 03 October 2011 23:02:15 Janus Weil wrote:
> Hi all,
>
> here is a patch for a rather long-standing PR. It continues my ongoing
> campaign of improving the checks for "procedure characteristics" (cf.
> F08 chapter 12.3), which are relevant for dummy procedures, procedure
> pointer assign
Hi,
On Mon, 3 Oct 2011, Jakub Jelinek wrote:
> std::vector acts roughly as something having a restrict pointer field,
> i.e. two different std::vector objects will have the pointers pointing to
> a different array, unfortunately unlike e.g. std::valarray we have 3
> different pointers pointing in
Bernd Schmidt writes:
> On 09/25/11 19:16, Richard Sandiford wrote:
>> The last bit is indirect, via a new HARD_REG_SET called operand_reg_set.
>> And this set is the reason why I'm sending the patch now. The MIPS16 port
>> has always had a problem with the HI and LO registers: they can only be
>
Hello,
This patch (one of two) adds to tree-ssa-reassociation code for
expansion of packed
bitwise-binary operations - like (X | Y) == 0, etc.
Also it normalizes bitwise-not operations on bitwise-binary tree
chains - like ~(X | Y) -> ~X & ~Y.
ChangeLog
2011-10-04 Kai Tietz
* tree-ssa
Hello,
This patch (two of two) adds to tree-ssa-reassociation code for
repropagation of unpacked
bitwise-binary operations - like (X == 0) & (Y == 0), etc.
Also it denormalizes bitwise-not operations on bitwise-binary tree
chains - eg ~X & ~Y -> ~(X | Y).
ChangeLog
2011-10-04 Kai Tietz
On Tue, Oct 4, 2011 at 2:07 AM, Michael Meissner
wrote:
> On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
>> On Fri, 30 Sep 2011, Michael Meissner wrote:
>>
>> > Is this enough of a savings to continue on? I'm of two minds about it,
>> > one is
>>
>> The thing to measure is not
On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov wrote:
> Richard,
>
> The following patch fixes a CFG consistency problem.
>
> When early IPA optimizations (e.g., early SRA) create a version of a function
> that no longer throws, versioning machinery deletes EH landings pads in
> _callers_ of the
On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> int *x;
>
> > void foo (int *p)
> > {
> > int * __restrict p1 = p;
> > int * __restrict p2 = p + 32;
> > int *q;
> > int i;
> x = p2;
> > q = p + 32;
> q = q - 31;
> > for (i = 0; i < 32; ++i)
> > p[i] =
> Well, I'm not sure we should jump through too much hoops to make
> -flto work with -fno-toplevel-reorder. Simply because I think nothing
> defines any "toplevel order" for multiple object files. So, I think
In practice it seems to work because real programs rely on it.
I can just say with thi
On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
> On 10/01/2011 05:46 PM, Tom de Vries wrote:
>> On 09/30/2011 03:29 PM, Richard Guenther wrote:
>>> On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries
>>> wrote:
On 09/28/2011 11:53 AM, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 11:
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> > int *x;
> >
> > > void foo (int *p)
> > > {
> > > int * __restrict p1 = p;
> > > int * __restrict p2 = p + 32;
> > > int *q;
> > > int i;
> > x = p2;
> > > q = p + 32;
On Tue, 4 Oct 2011, Andi Kleen wrote:
> > Well, I'm not sure we should jump through too much hoops to make
> > -flto work with -fno-toplevel-reorder. Simply because I think nothing
> > defines any "toplevel order" for multiple object files. So, I think
>
> In practice it seems to work because r
On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
> Sure, the question is if "-flto" counts as magic and thus
> "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> (or 1to1) it would be reasonable to make -fno-toplevel-reorder work
> (and thus maybe -fno-toplevel-
On Tue, Oct 4, 2011 at 1:00 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, as strlen optimization was
> assuming memcpy arguments will have expected type (size_type_node),
> but they had ssizetype instead. The following patch fixes it
> both in the builtins.c folders
On Tue, Oct 4, 2011 at 1:55 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 3 Oct 2011, Jakub Jelinek wrote:
>
>> std::vector acts roughly as something having a restrict pointer field,
>> i.e. two different std::vector objects will have the pointers pointing to
>> a different array, unfortunately unlike
On Tue, Oct 04, 2011 at 01:55:27PM +0200, Michael Matz wrote:
> Ugh, that's stretching our fragile to unsafe restrict support quite much.
> IMO beyond what we can reasonably be confident to not cause
> miscompilations. Essentially what you're implicitely assuming is that the
> sources of restr
On Tue, 4 Oct 2011, Richard Guenther wrote:
> On Tue, 4 Oct 2011, Jakub Jelinek wrote:
>
> > On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> > > int *x;
> > >
> > > > void foo (int *p)
> > > > {
> > > > int * __restrict p1 = p;
> > > > int * __restrict p2 = p + 32;
> >
On Tue, 4 Oct 2011, Andi Kleen wrote:
> On Tue, Oct 04, 2011 at 03:08:02PM +0200, Richard Guenther wrote
>
> > Sure, the question is if "-flto" counts as magic and thus
> > "don't do it when it hurts" ;)) I suppose with -flto-partition=none
> > (or 1to1) it would be reasonable to make -fno-tople
Hi,
On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> If it causes miscompilations, then GCC is buggy and needs to be fixed.
That's not easy without effectively making the whole restrict support
ineffective.
> > Keep in mind that the whole current restrict-tag support was designed to
> > support for
On Tue, Oct 4, 2011 at 3:28 PM, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 01:55:27PM +0200, Michael Matz wrote:
>> Ugh, that's stretching our fragile to unsafe restrict support quite much.
>> IMO beyond what we can reasonably be confident to not cause
>> miscompilations. Essentially what you
On Tue, Oct 04, 2011 at 02:44:00PM +0200, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 2:07 AM, Michael Meissner
> wrote:
> > On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
> >> On Fri, 30 Sep 2011, Michael Meissner wrote:
> >>
> >> > Is this enough of a savings to continue o
From: Eric Botcazou
Date: Tue, 4 Oct 2011 09:37:01 +0200
> Tested on SPARC/Solaris, applied on the mainline.
>
>
> 2011-10-04 Eric Botcazou
>
> * config/sparc/sparc.c (sparc_fold_builtin): Use a sequence of tests.
Thanks for fixing this Eric.
From: Gerald Pfeifer
Date: Tue, 4 Oct 2011 11:25:11 +0200 (CEST)
> On Sun, 2 Oct 2011, David Miller wrote:
>> We always use "Sparc" instead of "SPARC" for the cpu names output
>> by the kernel in /proc/cpuinfo.
>
> Ah, I see. Thanks for the explanation.
>
> What confused me a bit is that a bit
Hi,
I checked in this patch to fix a typo.
--
H.J.
---
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.44
diff -u -p -r1.44 changes.html
--- changes.html4 Oct 2011 09:27
On Tue, Oct 4, 2011 at 1:19 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 10:06 AM, Uros Bizjak wrote:
This patch improves address combine for x32 by forcing the memory memory
operand of PLUS operation into register. Tested on Linux/x86-64 with
-mx32. OK for trunk?
>>>
>>> Does
On Tue, Oct 4, 2011 at 2:28 AM, Gerald Pfeifer wrote:
> On Mon, 3 Oct 2011, H.J. Lu wrote:
>> I checked it in.
>
> Thanks, H.J.
>
> This needed a small markup fix which I just applied; see below.
>
Thanks.
--
H.J.
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
This implements the clean up Gab suggested in
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01882.html
Tested on x86_64. Committed.
Diego.
* pph-streamer.h (pph_cache_find): New.
Replace pph_cache_select/pph_cache_get combinations with it.
diff --git a/gcc/cp/pph-streamer-in.c
On Wed, Sep 28, 2011 at 17:28, Gabriel Charette wrote:
> Very nice!
>
> I really like where this is heading :)!
>
> I think it would be great to instrument this to know how many times we
> need to use a PPH_RECORD_MREF, to avoid trashing the cache (i.e.
> potentially there are specific cases where
Ping.
Richard, the patch in the attachment should be submitted asap. The
other problem could wait for a while.
Thanks,
Artem.
On Tue, Oct 4, 2011 at 12:04 AM, Artem Shinkarov
wrote:
> On Mon, Oct 3, 2011 at 6:12 PM, Richard Henderson wrote:
>> On 10/03/2011 09:43 AM, Artem Shinkarov wrote:
>>>
Ramana Radhakrishnan wrote:
> On 26 September 2011 15:24, Ulrich Weigand wrote:
> > Is this sufficient, or should I test any other set of options as well?
>
> Could you run one set of tests with neon ?
Sorry for the delay, but I had to switch to my IGEP board for Neon
support, and that's a bit s
This fixes PR50609, we need to do something sensible for VECTOR_TYPE
constructors, which is not dispatch to fold_nonarray_ctor_reference.
Instead fold_array_ctor_reference can be conveniently re-used.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-10-04 Richard Guenth
On Mon, 3 Oct 2011, Michael Meissner wrote:
> On Sat, Oct 01, 2011 at 02:11:27PM +, Joseph S. Myers wrote:
> > On Fri, 30 Sep 2011, Michael Meissner wrote:
> >
> > > Is this enough of a savings to continue on? I'm of two minds about it,
> > > one is
> >
> > The thing to measure is not so m
On Tue, 4 Oct 2011, Ilya Tocar wrote:
> Hi everyone,
>
> This patch fixes PR 50038 (redundant zero extensions) by modifying
> implicit-zee pass
> to also remove unneeded zero extensions from QImode to SImode.
Hardcoding particular modes like this in the target-independent parts of
the compiler
On Tue, 4 Oct 2011, Jayant R. Sonar wrote:
> PING 4: For review
> Hi,
> Can someone please review the patch:
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01441.html
Could someone with general back-end expertise look at this? I don't have
the expertise to review whether the back end follow
On Tue, Oct 4, 2011 at 1:19 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 10:06 AM, Uros Bizjak wrote:
This patch improves address combine for x32 by forcing the memory memory
operand of PLUS operation into register. Tested on Linux/x86-64 with
-mx32. OK for trunk?
>>>
>>> Does
On 10/04/2011 03:03 PM, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries wrote:
>> On 10/01/2011 05:46 PM, Tom de Vries wrote:
>>> On 09/30/2011 03:29 PM, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries
wrote:
> On 09/28/2011 11:53 AM, Ri
On 10/04/2011 08:18 AM, Artem Shinkarov wrote:
> Ping.
>
> Richard, the patch in the attachment should be submitted asap. The
> other problem could wait for a while.
The patch in the attachment is wrong too. I've re-written the x86
backend support, adding TARGET_XOP in the process. I've also re
2011/10/3 Ozkan Sezer :
> On Mon, Oct 3, 2011 at 5:56 PM, Kai Tietz wrote:
>> 2011/10/3 Ozkan Sezer :
>>> PING?
>>>
>>> On Thu, Sep 22, 2011 at 2:28 PM, Ozkan Sezer wrote:
Hi:
Unless I'm missing something, the mingw CPP_SPEC changes introduced in
r171833 have a typo: -D_REENTR
Two patches, both in trunk for some time, which fix crashes on ARM.
Andrew.
2011-10-04 Andrew Haley
* src/arm/ffi.c (FFI_INIT_TRAMPOLINE): Clear icache.
Index: libffi/src/arm/ffi.c
===
--- libffi/src/arm/ffi.c(r
Hi Mikael,
>> here is a patch for a rather long-standing PR. It continues my ongoing
>> campaign of improving the checks for "procedure characteristics" (cf.
>> F08 chapter 12.3), which are relevant for dummy procedures, procedure
>> pointer assignments, overriding of type-bound procedures, etc.
>
On Tue, Oct 4, 2011 at 6:06 PM, H.J. Lu wrote:
>> OTOH, x86_64 and i686 targets can also benefit from this change. If
>> combine can't create more complex address (covered by lea), then it
>> will simply propagate memory operand back into the add insn. It looks
>> to me that we can't loose here,
From: Gerald Pfeifer
Date: Tue, 4 Oct 2011 11:25:11 +0200 (CEST)
> On Sun, 2 Oct 2011, David Miller wrote:
>> We always use "Sparc" instead of "SPARC" for the cpu names output
>> by the kernel in /proc/cpuinfo.
>
> Ah, I see. Thanks for the explanation.
>
> What confused me a bit is that a bit
On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
"unnamed variadic functions" sounds as if the function itself is
unnamed, so not good.
-funnamed-variadic-parameter
How about
-fvariadic-parameters-unnamed
there's already a -fvariadic-macros, so maybe putting variadic first is
more consistent?
This won't affect vectors that are passed by non-restrict reference,
correct? We don't want to break code that, say, takes the address of an
element and then uses it later unless we've made that invalid by marking
the vector as restrict.
Jason
On Tue, Oct 4, 2011 at 10:32 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 6:06 PM, H.J. Lu wrote:
>
>>> OTOH, x86_64 and i686 targets can also benefit from this change. If
>>> combine can't create more complex address (covered by lea), then it
>>> will simply propagate memory operand back into
On Tue, Oct 04, 2011 at 02:28:13PM -0400, Jason Merrill wrote:
> This won't affect vectors that are passed by non-restrict reference,
> correct? We don't want to break code that, say, takes the address
It will ATM also affect global std::vector variables, and std::vector
variables passed by invis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/11 08:43, Aldy Hernandez wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
So others have already mentioned the name "memmodel" as being
unsatisfactory... From the list, I liked simulate-thread (before
looking at your message w
On Tue, Oct 4, 2011 at 8:37 PM, H.J. Lu wrote:
OTOH, x86_64 and i686 targets can also benefit from this change. If
combine can't create more complex address (covered by lea), then it
will simply propagate memory operand back into the add insn. It looks
to me that we can't loos
I think I had a similar patch earlier that got forgotten, but I've made
some changes.
if (sizeof(atomic) > target_word_size) then defaulting to a load or
store with barriers will result in non-atomic code, which is bad.
instead, the default has now been changed.
Store will try an exchange,
On 10/04/2011 09:28 AM, Tom de Vries wrote:
> Well, that was the idea. But now I wonder, isn't it better to do this in
> expand_builtin_alloca:
> ...
>/* Compute the argument. */
>op0 = expand_normal (CALL_EXPR_ARG (exp, 0));
>
> + align =
> +(DECL_FUNCTION_CODE (get_callee_fndecl (e
>>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>>
>> The patch is basically OK.
> Otherwise I'll just start by committing the
> patch as posted ...
Just did so (r179520).
Cheers,
Janus
On Tue, Oct 4, 2011 at 11:51 AM, Uros Bizjak wrote:
> On Tue, Oct 4, 2011 at 8:37 PM, H.J. Lu wrote:
>
> OTOH, x86_64 and i686 targets can also benefit from this change. If
> combine can't create more complex address (covered by lea), then it
> will simply propagate memory operand bac
On Oct 4, 2011, at 6:03 AM, Andi Kleen wrote:
> Also as Honza pointed out it has other benefits, like making
> compiles more reproducible. For example if you have a memory corruption
> somewhere the random order currently will randomly move it from
> run to run and make it harder to debug.
I like
THe framework for invoking gdb and simulating other threads can run into
a problem when memmodel_other_thread() is written in a hostile manner.
memodel_other_thread ()
{
mem++; /* increment mem every instruction. */
}
and it is tested against something like a compare_and_swap loop
imple
On 10/04/2011 11:51 AM, Andrew MacLeod wrote:
> * optabs.c (expand_sync_mem_load): Don't expand into a default load if
> the type is larger than a word. Try a compare_and_swap with 0.
> (expand_sync_mem_store): Return const0_rtx if a store is generated. If
> type is larger t
On 5/10/2011, at 1:49 AM, Richard Guenther wrote:
> On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov wrote:
>> Richard,
>>
>> The following patch fixes a CFG consistency problem.
>>
>> When early IPA optimizations (e.g., early SRA) create a version of a
>> function that no longer throws, version
I've committed this, which documents the fix for
http://gcc.gnu.org/PR1773 in gcc-4.7/changes.html, and also replaces
some > characters with the > entity.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/04/11 05:00, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, as strlen optimization
> was assuming memcpy arguments will have expected type
> (size_type_node), but they had ssizetype instead. The following
> patch fixes
I want to commit the attached patch to install.texi, but have been
unable to test it successfully.
The problem is that the link for "x86_64-*-solaris2.1[0-9]*" in the
Host/Target Specific notes is
http://gcc.gnu.org/install/specific.html#x86-64-x-solaris210
but the corresponding anchor is:
Note
On 10/04/2011 08:42 AM, Joseph S. Myers wrote:
> On Tue, 4 Oct 2011, Ilya Tocar wrote:
>
>> Hi everyone,
>>
>> This patch fixes PR 50038 (redundant zero extensions) by modifying
>> implicit-zee pass
>> to also remove unneeded zero extensions from QImode to SImode.
>
> Hardcoding particular modes
On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
Good question. Is the below better?
+ if (linemap_location_from_macro_expansion_p (set, pre))
+pre = linemap_resolve_location (set, pre,
+ LRK_MACRO_EXPANSION_POINT, NULL);
+
+ if (linemap_location_from_macr
On 10/03/2011 04:08 PM, Dodji Seketeli wrote:
Jason Merrill writes:
-finish_declspecs (struct c_declspecs *specs)
+finish_declspecs (struct c_declspecs *specs,
+ location_t where)
I'm not sure the beginning of the declspecs is a better place for
these diagnostics than the begi
Richard Sandiford writes:
> Bernd Schmidt writes:
>> On 09/25/11 19:16, Richard Sandiford wrote:
>>> The last bit is indirect, via a new HARD_REG_SET called operand_reg_set.
>>> And this set is the reason why I'm sending the patch now. The MIPS16 port
>>> has always had a problem with the HI and
On 10/04/2011 08:51 PM, Richard Henderson wrote:
> On 10/04/2011 09:28 AM, Tom de Vries wrote:
>> Well, that was the idea. But now I wonder, isn't it better to do this in
>> expand_builtin_alloca:
>> ...
>>/* Compute the argument. */
>>op0 = expand_normal (CALL_EXPR_ARG (exp, 0));
>>
>> +
Jason Merrill writes:
> So then this change would make
>
> _Complex c;
>
> OK, but not
>
> static _Complex c;
>
> because the first declspec is not from a macro, right?
Yes.
>
>> I believe you noted this at some point and
>> agreed with me that ideally each declspec should come with its locatio
Jason Merrill writes:
> On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
>> Good question. Is the below better?
>
>> + if (linemap_location_from_macro_expansion_p (set, pre))
>> +pre = linemap_resolve_location (set, pre,
>> + LRK_MACRO_EXPANSION_POINT, NULL);
1 - 100 of 133 matches
Mail list logo
