On Wed, Sep 28, 2011 at 8:42 AM, Jiangning Liu wrote:
> Just realized ChangeLog needs to be changed as well.
>
> ChangeLog:
>
> * config/i386/i386.c (ix86_using_red_zone): Remove inline.
> (TARGET_STACK_USING_RED_ZONE): New.
> * config/rs6000/rs6000.c (rs6000_stack_using_red_z
On 28 September 2011 04:22, Michael Spertus wrote:
> Benjamin,
> I think tuple is wrong both for performance reasons (I believe these are
> likely to be serious enough to depress use due to inordinately long compiles)
> and because it prematurely locks us into a rigid choice of how our typelists
On Tue, Sep 27, 2011 at 11:30 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> I had some trouble with random build failures in a large LTO project
> and it turned out to be random seed collisions in a highly parallel build
> (thanks to Honza for suggesting that)
>
> There were multiple problems:
> -
On Wed, Sep 28, 2011 at 3:49 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, September 27, 2011 3:41 PM
>> To: Jiangning Liu
>> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack re
2011-09-28 Joey Ye
* gcc.target/arm/pr42575.c: Remove architecture option.
Index: gcc/testsuite/gcc.target/arm/pr42575.c
===
--- gcc/testsuite/gcc.target/arm/pr42575.c (revision 179308)
+++ gcc/testsuite/gcc.target/ar
Committed as obvious.
Thanks,
- Tom
2011-09-28 Tom de Vries
PR testsuite/50485
* gcc.target/i386/sse4_1-blendps.c: Include .
(TEST): Initialize src3 with random floats.
* gcc.target/i386/sse4_1-blendps-2.c (sse4_1_test): Remove field i from
union src3.
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, September 28, 2011 4:39 PM
> To: Jiangning Liu
> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Wed, Sep 28, 2011 at 3:49 AM, Ji
On Wed, Sep 28, 2011 at 11:10 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, September 28, 2011 4:39 PM
>> To: Jiangning Liu
>> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack
Richard,
I got a patch for PR50527.
The patch prevents the alignment of vla-related allocas to be set to
BIGGEST_ALIGNMENT in ccp. The alignment may turn out smaller after folding
the alloca.
Bootstrapped and regtested on x86_64.
OK for trunk?
Thanks,
- Tom
2011-09-27 Tom de Vries
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, September 28, 2011 5:20 PM
> To: Jiangning Liu
> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Wed, Sep 28, 2011 at 11:10 AM, J
On 28 September 2011 09:48, Joey Ye wrote:
> 2011-09-28 Joey Ye
>
> * gcc.target/arm/pr42575.c: Remove architecture option.
What happens if this test is run with a multilib of march=armv5te ?
Ramana
>
> Index: gcc/testsuite/gcc.target/arm/pr42575.c
> ===
On Wed, Sep 28, 2011 at 11:34 AM, Tom de Vries wrote:
> Richard,
>
> I got a patch for PR50527.
>
> The patch prevents the alignment of vla-related allocas to be set to
> BIGGEST_ALIGNMENT in ccp. The alignment may turn out smaller after folding
> the alloca.
>
> Bootstrapped and regtested on x86_
On Wed, Sep 28, 2011 at 11:40 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, September 28, 2011 5:20 PM
>> To: Jiangning Liu
>> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> Solaris 8 and 9 suffer from the same problem. The following patch
>> allowed the bootstrap to complete. An IRIX bootstrap is currently
>> running, but will take some time to complete.
>>
>> Rainer
>>
>>
>> 2011-09-23 Rainer Orth
>>
>>
Jan Hubicka writes:
> the problem is sign overflow in time computation. Time should be
> capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE *
> 2. This happens to be >2^31 & <2^32 so we overflow here because of use
> of signed arithmetics.
>
> Index: ipa-inline-analysis.c
> ===
Attached is a part 1 of patch that enables use of vector-instructions
in memset and memcopy (middle-end part).
The main part of the changes is in functions
move_by_pieces/set_by_pieces. In new version algorithm of move-mode
selection was changed – now it checks if alignment is known at compile
time
>
> Tested on arm-linux-gnueabi, and on benchmarks which should (and did)
> benefit from it. OK to install?
OK.
Ramana
Michael Zolotukhin writes:
>
> Build and 'make check' was tested.
Could you expand a bit on the performance benefits? Where does it help?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Don't worry, I'm not suggesting including boost::mpl at all, just
leaving the return type of the bases trait unspecified. IMO, your
example illustrates my point that without performance tuning, compiling
metaprograms can be prohibitively expensive, so I want to avoid running
the tuple metaprogr
On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
> Michael Zolotukhin writes:
> >
> > Build and 'make check' was tested.
>
> Could you expand a bit on the performance benefits? Where does it help?
Especially when glibc these days has very well optimized implementations
tuned for vari
Hi,
this patch adds support for V2 plugin API (thanks, Cary) that adds
LDPR_PREVAILING_DEF_IRONLY_EXP.
The reoslution is like LDPR_PREVAILING_DEF_IRONLY but the symbol is exported
out of DSO. It is up to the compiler to optimize it out or keep it based on
the knowledge whether the symbol can be op
> On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
> > Michael Zolotukhin writes:
> > >
> > > Build and 'make check' was tested.
> >
> > Could you expand a bit on the performance benefits? Where does it help?
>
> Especially when glibc these days has very well optimized implementation
This expanding only works on relatively small sizes (up to 4k), where
overhead of library call could be quite significant. In some cases new
implementation gives 5x acceleration (especially on small sizes - less
than ~256 bytes). Almost on all sizes from 16 to 4096 bytes there is a
some gain, in av
On Wed, 28 Sep 2011, Jan Hubicka wrote:
> Hi,
> this patch adds support for V2 plugin API (thanks, Cary) that adds
> LDPR_PREVAILING_DEF_IRONLY_EXP.
> The reoslution is like LDPR_PREVAILING_DEF_IRONLY but the symbol is exported
> out of DSO. It is up to the compiler to optimize it out or keep it
I addressed all review comments, clarified some code.
The random seed generation in gcc.c is now fixed too and toplev.c
detects this case and doesn't rerun the CRC.
Repasses bootstrap and testsuite on x86_64-linux.
Since the previous version was approved I will commit in 24h,
unless there are new
From: Andi Kleen
When available use /dev/urandom to get the random seem. This will lower the
probability
of collisions.
On other systems it will fallback to the old methods.
Passes bootstrap + testsuite on x86_64. Ok?
gcc/:
* 2011-09-26 Andi Kleen
* toplev.c (init_local_tick): Tr
From: Andi Kleen
gcc also takes generates a random number in some special circumstances,
so teach it about /dev/urandom too.
gcc/:
2011-09-27 Andi Kleen
* gcc.c (get_local_tick). Rename to get_random_number. Read from
/dev/urandom.
Add getpid call.
(compare_debug_d
From: Andi Kleen
I had some trouble with random build failures in a large LTO project
and it turned out to be random seed collisions in a highly parallel build
(thanks to Honza for suggesting that)
There were multiple problems:
- The way to generate the random seed is not very random (millisecon
> Do you know glibc version numbers when
> the optimized string functions was introduced?
Afaik, it's 2.13.
I also compared my implementation to 2.13.
> > Do you know glibc version numbers when
> > the optimized string functions was introduced?
>
> Afaik, it's 2.13.
> I also compared my implementation to 2.13.
I wonder if we can assume that most of GCC 4.7 based systems will be glibc 2.13
based, too. I would tend to say that yes and thus would
On Wed, Sep 28, 2011 at 2:49 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> When available use /dev/urandom to get the random seem. This will lower the
> probability
> of collisions.
>
> On other systems it will fallback to the old methods.
>
> Passes bootstrap + testsuite on x86_64. Ok?
>
> gcc/:
On Thu, Sep 15, 2011 at 8:05 PM, Richard Henderson wrote:
>> +The elements of the input vectors are numbered from left to right across
>> +one or both of the vectors. Each element in the mask specifies a number
>> +of element from the input vector(s). Consider the following example.
>
> It would b
> (I worry about the tables in i386.c deciding what strategy to use for block of
> given size. This is more or less unrelated to the actual patch)
Yep, the threshold values I mentioned above are the values in these
tables. Even with fast glibs there are some cases when inlining is
profitable (e.g.
Rainer Orth writes:
> Thanks, I'd missed that. It turned out that IRIX 6 needs one more
> change to return to bootstrap land: only defines
> TIOCNOTTY if !_XOPEN_SOURCE, which we need for other stuff
> (cf. configure.ac). I've cheated and use instead, which
> doesn't have this check. With th
OK. Here are some simple benchmarks. I simulated heavy use of reflection
with 1000 classes that each had about a thousand base classes. I also
created a super-simple typelist class
template struct typelist {}; // Variadic templates rock
If bases returns a typelist, the program takes about 4 se
On Wed, Sep 28, 2011 at 02:56:30PM +0400, Michael Zolotukhin wrote:
> Attached is a part 1 of patch that enables use of vector-instructions
> in memset and memcopy (middle-end part).
> The main part of the changes is in functions
> move_by_pieces/set_by_pieces. In new version algorithm of move-mode
On 6 May 2011 14:13, 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 makes some effor
> It appears that part 1 of the patch wasn't really attached.
Thanks, resending.
memfunc-mid.patch
Description: Binary data
This extends try_move_mult_to_index folding to be less picky about
the outermost array reference and handles a component-ref of an
array the same as if that were wrapped with an array-ref with
minimum index.
This consolidates array-ref reconstruction to the frontend-closest
position we have right
On Wed, Aug 10, 2011 at 7:44 AM, Richard Guenther
wrote:
>
> On Tue, Aug 9, 2011 at 10:23 PM, Artem Shinkarov
> wrote:
> > Sorry, I didn't attach the patch itself.
> > Here we go, in the attachment.
>
> I have committed the patch after re-bootstrapping and testing it
> on x86_64-unknown-linux-gnu
Hi Guys,
I am applying the patch below to fix a couple of problems building
libgcc for the RX target. The first is that when 32-bit doubles are
enabled we need to make sure that we never try to construct a 64-bit
double type. This is done in rx-lib.h, but it was only being enabled
when
Hi Tom
What's the behavior of your patch to the following case
typedef int int_unaligned __attribute__((aligned(1)));
int foo (int_unaligned *p)
{
return *p;
}
thanks
Carrot
On Tue, Sep 20, 2011 at 7:13 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch for PR43814. It introduces an op
On 09/27/2011 08:03 PM, Dodji Seketeli wrote:
Jason Merrill writes:
Yes, I was suggesting that you change that, since it's only used by
_get_location, which can get the location from the pointer instead.
Done.
And then you should be able to drop the track_macro_exp_p field from
macro_arg_
On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
wrote:
> On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
> wrote:
>> On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers
>> wrote:
>>> This looks like it has the same issue with maybe needing to use
>>> TYPE_MAIN_VARIANT in type comparisons as the
Ian
I can try to put a description in the document. I am not sure that I
have rights to commit to the svn, but at least I can try to write the
text.
There are also pending patches for vector-comparison (almost
submitted) and vector shuffling (still under discussion), but I hope
to finish both of
This patch makes the GCC extension __float128 (_Complex) available in
the C bindings via C_FLOAT128 and C_FLOAT128_COMPLEX.
Additionally, I have improved the diagnostic for explicitly use
associating -std= versioned symbols. And I have finally added the
iso*.def files to the makefile dependenc
Hi Guys,
I am going to apply the patch below to the RX backend to add support
for generating MIN and MAX instructions for HI and QI modes.
Cheers
Nick
gcc/ChangeLog
2011-09-28 Nick Clifton
* config/rx/predicates.md (rx_minmax_operand): New predicate.
Accepts immediates
On 09/28/2011 05:59 AM, Artem Shinkarov wrote:
> I don't really understand this. As far as I know, expand_normal
> "converts" tree to rtx. All my computations are happening at the level
> of rtx and force_reg is needed just to bring an rtx expression to the
> register of the correct mode. If I am m
Artem Shinkarov writes:
> I can try to put a description in the document. I am not sure that I
> have rights to commit to the svn, but at least I can try to write the
> text.
>
> There are also pending patches for vector-comparison (almost
> submitted) and vector shuffling (still under discussion
Ayal Zaks writes:
>> >> + /* The cyclic lifetime of move->new_reg starts and ends at move->def
>> >> + (the instruction that defines move->old_reg).
>> >
>> > So instruction I_REG_MOVE (new_reg=reg) must be scheduled before the
>> > next I_MUST_FOLLOW move/original-def (due to anti-dependence
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 the ids are only ordered for the throw-away loop:
>>
>> FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_in
On Wed, Sep 28, 2011 at 02:54:34PM +0200, Jan Hubicka wrote:
> > > Do you know glibc version numbers when
> > > the optimized string functions was introduced?
> >
> > Afaik, it's 2.13.
> > I also compared my implementation to 2.13.
>
> I wonder if we can assume that most of GCC 4.7 based systems
> I suppose we might get interrupted before anything is read and
> read can return with -1 (I suppose partial reads are quite unlikely
> though)? Thus, don't we need the usual EINTR loop?
When we get interrupted gcc will die. I don't think gcc handles any
asynchronous signals, right?
-Andi
--
This is a tentative patch for better support of logging information for avr BE
developers.
There are situations where it is more convenient to let the compiler produce
information than to debug into the compiler. One example are -da dumps.
This patch proposes a better support to print information
> You could add a check to configure and generate based on that?
Do you mean check if glibc is newer than 2.13?
I think that when new glibc version is released, the tables should be
re-examined anyway - we shouldn't just stop inlining, or stop
generating libcalls.
> BTW I know that the tables need
This supercedes http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01004.html
and http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01593.html, fixing
the two regressions introduced by those patches. The first patch is
unchanged except to leave all the out-of-line restore functions using
"return" rather than
Hi!
This patch generates Thumb2 epilogues in RTL form.
The work involves defining new functions, predicates and patterns along with
few changes in existing code:
* The load_multiple_operation predicate was found to be too restrictive for
integer loads as it required consecutive destination regs,
On 09/28/2011 03:57 PM, Carrot Wei wrote:
> Hi Tom
>
> What's the behavior of your patch to the following case
>
> typedef int int_unaligned __attribute__((aligned(1)));
> int foo (int_unaligned *p)
> {
> return *p;
> }
>
I modified the example slightly:
test.c:
...
typedef int __attribute__
> There is no separate cost-table for Nehalem or SandyBridge - however,
> I tuned generic32 and generic64 tables, that should improve
> performance on modern processors. In old version REP-MOV was used - it
The recommended heuristics have changed in Nehalem and Sandy-Bridge
over earlier Intel CPUs
On Wed, Sep 28, 2011 at 06:27:11PM +0200, Andi Kleen wrote:
> > There is no separate cost-table for Nehalem or SandyBridge - however,
> > I tuned generic32 and generic64 tables, that should improve
> > performance on modern processors. In old version REP-MOV was used - it
>
> The recommended heuri
All,
gcc.target/arm/pr42835.c started failing as a result of the following
change which add tree-tail merging:
http://gcc.gnu.org/viewcvs?view=revision&revision=179275
The behaviour of the testcase with tree-tail merging is correct, but not
what is expected.
The attached patch adds -fno-tre
> gcc/testsuite/ChangeLog:
>
> 2011-09-28 Matthew Gretton-Dann
>
> * gcc.target/arm/pr42835.c: Add -fno-tree-tail-merge.
This is OK.
Ramana
On Wed, 28 Sep 2011 16:56:32 +0200
Andi Kleen wrote:
> > I suppose we might get interrupted before anything is read and
> > read can return with -1 (I suppose partial reads are quite unlikely
> > though)? Thus, don't we need the usual EINTR loop?
>
> When we get interrupted gcc will die. I don'
On Mon, Sep 19, 2011 at 5:52 PM, Doug Evans wrote:
>
> 2011-09-19 Doug Evans
>
> include/
> * timeval-utils.h: New file.
>
> libiberty/
> * timeval-utils.c: New file.
> * Makefile.in (CFILES): Add it.
> (REQUIRED_OFILES): Add timeval-utils.$(objext).
>
On Tue, Sep 20, 2011 at 11:23 AM, Doug Evans wrote:
>
> 2011-09-20 Doug Evans
>
> include/
> * libiberty.h (countargv): Declare.
>
> libiberty/
> * argv.c (countargv): New function.
> + for (argc = 0; argv[argc] != NULL; argc++);
Please write the semicolon on the
On 24/09/2011, at 9:40 PM, Jakub Jelinek wrote:
> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
>> In the end I'd probably say the patch is ok without the option (thus
>> turned on by default), but if LC_GLOBAL_LOCALE is part of the
>> glibc ABI then we clearly can't do this.
>
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:29:12 +1300
> GLIBC patch to fix locale_t definition is attached.
Isn't this going to result in byte loads being used to dereference
all locale_t pointers on targets like sparc and mips?
On 29/09/2011, at 7:35 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:29:12 +1300
>
>> GLIBC patch to fix locale_t definition is attached.
>
> Isn't this going to result in byte loads being used to dereference
> all locale_t pointers on targets like sparc and mips?
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:40:55 +1300
> On 29/09/2011, at 7:35 AM, David Miller wrote:
>
>> From: Maxim Kuvyrkov
>> Date: Thu, 29 Sep 2011 07:29:12 +1300
>>
>>> GLIBC patch to fix locale_t definition is attached.
>>
>> Isn't this going to result in byte loads being used t
On 29/09/2011, at 7:41 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:40:55 +1300
>
>> On 29/09/2011, at 7:35 AM, David Miller wrote:
>>
>>> From: Maxim Kuvyrkov
>>> Date: Thu, 29 Sep 2011 07:29:12 +1300
>>>
GLIBC patch to fix locale_t definition is attached.
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:45:17 +1300
> OK. Do you have an alternative suggestion that would fix non-portable use of
> locale_t?
Don't optimize something that is invalidated by a quite common practice?
What about people who encode invalid pointers with "0xdeadbeef", do we
David,
To summarize, your opinion seems to be to not enable the optimization by
default, correct?
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
On 29/09/2011, at 7:48 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:45:17 +1300
>
>> OK. Do you have
Hi
In the attachment there is a patch with the changes. I don't have
rights to commit to the cvs.
If we write about vector-related stuff, may be it would make sense to
mention that from now on we can make vector shifts and we can index
vector. These are changes from 4.6 (I guess), but they were n
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:58:01 +1300
> To summarize, your opinion seems to be to not enable the
> optimization by default, correct?
Yes, and I don't think we ever could do so.
BTW, another common paradigm is using the "always clear" bits of a
pointer to encode state bits.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/28/11 13:00, David Miller wrote:
> From: Maxim Kuvyrkov Date: Thu, 29 Sep
> 2011 07:58:01 +1300
>
>> To summarize, your opinion seems to be to not enable the
>> optimization by default, correct?
>
> Yes, and I don't think we ever could do so.
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:58:01 +1300
>
> > To summarize, your opinion seems to be to not enable the
> > optimization by default, correct?
>
> Yes, and I don't think we ever could do so.
>
> BTW, another comm
On Wed, Sep 28, 2011 at 9:13 PM, Jakub Jelinek wrote:
> On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
>> From: Maxim Kuvyrkov
>> Date: Thu, 29 Sep 2011 07:58:01 +1300
>>
>> > To summarize, your opinion seems to be to not enable the
>> > optimization by default, correct?
>>
>> Yes,
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
> There is nothing like "very likely aligned" ;) Note that what is new is
On non-strict aligned targets there is no reason not to have something like
"very likely aligned". You would expand stores/loads as if it was aligned
in tha
On 09/28/2011 03:15 PM, Dodji Seketeli wrote:
+set_arg_token (macro_arg *arg, const cpp_token *token,
+ source_location location, size_t index,
+ enum macro_arg_token_kind kind,
+ bool track_macro_exp_p)
+{
+ const cpp_token **token_ptr;
+ source_location
Hi,
here submitter remarks that, inconsistently with the documentation, with
-Wextra the C++ front-end doesn't warn for ordered comparison of pointer
with integer zero. Thus I simply adapted the warning in the C front-end.
Is the patch Ok?
Tested x86_64-linux.
Paolo.
/
> That depends upon the signal. If we got SIGCHLD or SIGWINCH, the call to read
> probably
> gets EINTR, but the signal is ignored unless explicitly handled.
ignored signals do not cause EINTR no.
And I don't think either gcc.c nor toplev.c can get SIGCHLD at this point.
-Andi
On 09/28/2011 11:02 PM, Paolo Carlini wrote:
Hi,
here submitter remarks that, inconsistently with the documentation,
with -Wextra the C++ front-end doesn't warn for ordered comparison of
pointer with integer zero. Thus I simply adapted the warning in the C
front-end. Is the patch Ok?
Better
More comments to come on [3/3], for now just a single comment below on
this specific patch:
> diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
> index 0bd4d64..b267833 100644
> --- a/gcc/cp/pph-streamer-in.c
> +++ b/gcc/cp/pph-streamer-in.c
> @@ -439,7 +439,10 @@ pph_in_cxx_binding
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 only a small field's value
changes and pickling the entire tree aga
On Wed, Sep 28, 2011 at 17:23, Gabriel Charette wrote:
> More comments to come on [3/3], for now just a single comment below on
> this specific patch:
>
>> diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
>> index 0bd4d64..b267833 100644
>> --- a/gcc/cp/pph-streamer-in.c
>> +++ b/g
Oleg Endo wrote:
> The attached patch and ChangeLog below should fix it.
> I have also added a test case for SI mode abs.
Thanks! I've applied your patch as revision 179320.
Regards,
kaz
OK.
Jason
On Wed, Sep 28, 2011 at 05:33:23PM +0400, Michael Zolotukhin wrote:
> > It appears that part 1 of the patch wasn't really attached.
> Thanks, resending.
Michael,
Did you bootstrap with --enable-checking=yes? I am seeing the bootstrap
failure...
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir
Hi there,
Ping. I'm seeking approval for this fix on trunk and 4_6-branch.
Thanks!
Bill
On Tue, 2011-09-13 at 17:55 -0500, William J. Schmidt wrote:
> Greetings,
>
> The code to build scops (static control parts) for graphite first
> rewrites loops into canonical loop-closed SSA form. PR50183
On Sep 20, 2011, at 4:13 AM, Tom de Vries wrote:
> I have a patch for PR43814. It introduces an option that assumes that function
> arguments of pointer type are aligned, and uses that information in
> tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
I'm not a huge fan of an opt
On 09/24/2011 11:31 AM, Richard Guenther wrote:
> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries wrote:
>> Hi Richard,
>>
>> I have a patch for PR43814. It introduces an option that assumes that
>> function
>> arguments of pointer type are aligned, and uses that information in
>> tree-ssa-ccp. Thi
[Vlad, if you have a few minutes, would you mind having a look at the couple of
questions at the end of the message? Thanks in advance].
> No problem.
Here are the results of the investigation. Pseudo 116 needs to be assigned a
hard register. It is used mostly in vector instructions so we wo
From: Mike Stump
Date: Wed, 28 Sep 2011 15:19:10 -0700
> If Android is safe in this respect, then, they can just turn it on,
> and then force anyone porting software to their platform to `fix'
> their code.
They'd have to then know to turn this option off when building the kernel,
which does use
On Wed, Sep 28, 2011 at 5:31 PM, Diego Novillo wrote:
> On Wed, Sep 28, 2011 at 17:23, Gabriel Charette wrote:
>> More comments to come on [3/3], for now just a single comment below on
>> this specific patch:
>>
>>> diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
>>> index 0bd4d6
On Wed, Sep 28, 2011 at 06:43:04PM -0400, David Miller wrote:
> From: Mike Stump
> Date: Wed, 28 Sep 2011 15:19:10 -0700
>
> > If Android is safe in this respect, then, they can just turn it on,
> > and then force anyone porting software to their platform to `fix'
> > their code.
>
> They'd have
Hi,
tested x86_64-linux, committed.
Paolo.
//
2011-09-28 Paolo Carlini
PR c++/40145
* g++.dg/ext/visibility/warn5.C: New.
Index: g++.dg/ext/visibility/warn5.C
===
--- g++.dg/ext/visibility/warn5
On 09/27/2011 01:52 PM, Dodji Seketeli wrote:
+ Remember we are at the expansion point of MACRO. Each xI is the
+ location of the Ith token of the replacement-list. Now it gets
+ confusing. the xI is the location of the Ith token of the
+ replacement-list at the macro *definition
Committed to ARM/embedded-4_6-branch.
2011-09-28 Jiangning Liu
PR rtl-optimization/38644
* config/i386/i386.c (ix86_stack_using_red_zone): Change inline
to be extern.
(TARGET_STACK_USING_RED_ZONE): New.
* config/rs6000/rs6000.c (rs6000_stack_using_red_zone):
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, September 28, 2011 5:56 PM
> To: Jiangning Liu
> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
> On Wed, Sep 28, 2011 at 11:40 AM, J
This is heavily inspired by a proof-of-concept patch David
Bremner sent to me the other week.
Committed to trunk.
gcc/
* config/sparc/sparc.md (UNSPEC_FCMPLE, UNSPEC_FCMPNE,
UNSPEC_FCMPGT, UNSPEC_FCMPEQ): Delete and reduce to...
(UNSPEC_FCMP): New unspec.
(gcond)
1 - 100 of 103 matches
Mail list logo
