Backport mainline r179330 to ARM/embedded-4_6-branch
Committed.
2011-09-29 Joey Ye
Backport r179330 from mainline
2011-09-29 Jiangning Liu
* gcc/testsuite/gcc.dg/tree-ssa/predcom-1.c: Explicitly turn on
loop unroll and set max unroll times to 8.
* g
> Sorry what I meant is that it would be bad if -mtune=corei7(-avx)? was
> slower than generic.
For now, -mtune=corei7 is triggering use of generic cost-table (I'm
not sure about corei7-avx, but assume the same) - so it won't be
slower.
> Adding new tables shouldn't be very difficult, even if they
> Michael,
>Did you bootstrap with --enable-checking=yes? I am seeing the bootstrap
> failure...
I checked bootstrap, specs and 'make check' with the complete patch.
Separate patches for ME and BE were only tested for build (no
bootstrap) and 'make check'. I think it's better to apply the compl
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)
> -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
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):
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
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 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
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
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
[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
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
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
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 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
OK.
Jason
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
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
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
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
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
> 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
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.
/
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
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 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 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
-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.
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.
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
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
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
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: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: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: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 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.
>
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 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 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'
> gcc/testsuite/ChangeLog:
>
> 2011-09-28 Matthew Gretton-Dann
>
> * gcc.target/arm/pr42835.c: Add -fno-tree-tail-merge.
This is OK.
Ramana
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
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
> 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 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__
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,
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
> 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 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
> 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
--
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
> It appears that part 1 of the patch wasn't really attached.
Thanks, resending.
memfunc-mid.patch
Description: Binary data
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
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
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
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
> (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.
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
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/:
> > 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
> 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.
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
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
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
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
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
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, 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
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 implementations
tuned for vari
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
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
>
> Tested on arm-linux-gnueabi, and on benchmarks which should (and did)
> benefit from it. OK to install?
OK.
Ramana
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
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
> ===
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
>>
>>
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
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 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
> ===
> -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
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
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
> -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
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.
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
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
1 - 100 of 103 matches
Mail list logo
