This is okay
On Mon, Sep 26, 2011 at 6:14 PM, Guozhi Wei car...@google.com wrote:
Hi
This patch removes the XPASS of test case 20040204-1.c on arm.
Tested by
on arm: make check-gcc
RUNTESTFLAGS=--target_board=arm-sim/thumb/arch=armv7-a
tree-ssa.exp=20040204-1.c
on x86_64: make
-static inline bool
+extern bool
static bool
ix86_using_red_zone (void)
{
return TARGET_RED_ZONE !TARGET_64BIT_MS_ABI;
@@ -35958,6 +35958,9 @@ ix86_autovectorize_vector_sizes (void)
#define TARGET_STACK_PROTECT_FAIL ix86_stack_protect_fail
#endif
...
+/* Return
Backport mainline r173371 to ARM/embedded-4_6-branch.
Committed.
2011-09-28 Terry Guo terry@arm.com
Backport r173371 from mainline
2011-05-04 Andreas Krebbel andreas.kreb...@de.ibm.com
* calls.c (emit_library_call_value_1): Invoke
promote_function_mode
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_zone): New.
(TARGET_STACK_USING_RED_ZONE): New.
Ramana Radhakrishnan ramana.radhakrish...@linaro.org writes:
On 14 September 2011 13:30, Richard Sandiford
richard.sandif...@linaro.org wrote:
neon_vget_high and neon_vget_low extract one half of a vector.
The patterns look like:
(define_insn neon_vget_highv16qi
[(set (match_operand:V8QI 0
On Wed, Sep 28, 2011 at 8:42 AM, Jiangning Liu jiangning@arm.com 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
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 a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
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)
On Wed, Sep 28, 2011 at 3:49 AM, Jiangning Liu jiangning@arm.com 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
2011-09-28 Joey Ye joey...@arm.com
* 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)
+++
Committed as obvious.
Thanks,
- Tom
2011-09-28 Tom de Vries t...@codesourcery.com
PR testsuite/50485
* gcc.target/i386/sse4_1-blendps.c: Include stdlib.h.
(TEST): Initialize src3 with random floats.
* gcc.target/i386/sse4_1-blendps-2.c (sse4_1_test): Remove
-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, Jiangning
On Wed, Sep 28, 2011 at 11:10 AM, Jiangning Liu jiangning@arm.com 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]
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,
On 28 September 2011 09:48, Joey Ye joey...@arm.com wrote:
2011-09-28 Joey Ye joey...@arm.com
* 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 tom_devr...@mentor.com 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
On Wed, Sep 28, 2011 at 11:40 AM, Jiangning Liu jiangning@arm.com 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]
Ian Lance Taylor i...@google.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de 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
Jan Hubicka hubi...@ucw.cz 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
Tested on arm-linux-gnueabi, and on benchmarks which should (and did)
benefit from it. OK to install?
OK.
Ramana
Michael Zolotukhin michael.v.zolotuk...@gmail.com 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
On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
Michael Zolotukhin michael.v.zolotuk...@gmail.com 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
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
On Wed, Sep 28, 2011 at 04:41:47AM -0700, Andi Kleen wrote:
Michael Zolotukhin michael.v.zolotuk...@gmail.com 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
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
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
From: Andi Kleen a...@linux.intel.com
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 a...@linux.intel.com
From: Andi Kleen a...@linux.intel.com
gcc also takes generates a random number in some special circumstances,
so teach it about /dev/urandom too.
gcc/:
2011-09-27 Andi Kleen a...@linux.intel.com
* gcc.c (get_local_tick). Rename to get_random_number. Read from
/dev/urandom.
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 a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
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 +
On Thu, Sep 15, 2011 at 8:05 PM, Richard Henderson r...@redhat.com 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
(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 r...@cebitec.uni-bielefeld.de writes:
Thanks, I'd missed that. It turned out that IRIX 6 needs one more
change to return to bootstrap land: sys/termios.h only defines
TIOCNOTTY if !_XOPEN_SOURCE, which we need for other stuff
(cf. configure.ac). I've cheated and use sys/ttold.h
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
templatetypename... T struct typelist {}; // Variadic templates rock
If bases returns a typelist, the program
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 jul...@codesourcery.com 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 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
On Wed, Aug 10, 2011 at 7:44 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Aug 9, 2011 at 10:23 PM, Artem Shinkarov
artyom.shinkar...@gmail.com wrote:
Sorry, I didn't attach the patch itself.
Here we go, in the attachment.
I have committed the patch after re-bootstrapping
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
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 vr...@codesourcery.com wrote:
Hi Richard,
I have a patch for PR43814.
On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers jos...@codesourcery.com
wrote:
This looks like it has the same issue with
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
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 ni...@redhat.com
* config/rx/predicates.md (rx_minmax_operand): New predicate.
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
Artem Shinkarov artyom.shinkar...@gmail.com 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
Ayal Zaks ayal.z...@gmail.com 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
Ayal Zaks ayal.z...@gmail.com 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
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 will be glibc
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
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
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 heuristics
On Wed, 28 Sep 2011 16:56:32 +0200
Andi Kleen a...@firstfloor.org 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
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.
Yes,
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
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
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:40:55 +1300
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:29:12 +1300
GLIBC patch to fix locale_t definition is attached.
Isn't this going to
On 29/09/2011, at 7:41 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:40:55 +1300
On 29/09/2011, at 7:35 AM, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:29:12 +1300
GLIBC patch to fix locale_t
From: Maxim Kuvyrkov ma...@codesourcery.com
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
From: Maxim Kuvyrkov ma...@codesourcery.com
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
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
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,
On Wed, Sep 28, 2011 at 9:13 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Thu, 29 Sep 2011 07:58:01 +1300
To summarize, your opinion seems to be to not enable the
optimization by
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 that
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.
/
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_1
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
On Wed, Sep 28, 2011 at 17:23, Gabriel Charette gcharet...@gmail.com 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
---
Oleg Endo oleg.e...@t-online.de 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
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
On 09/24/2011 11:31 AM, Richard Guenther wrote:
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries vr...@codesourcery.com 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
[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
From: Mike Stump mikest...@comcast.net
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
On Wed, Sep 28, 2011 at 5:31 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Sep 28, 2011 at 17:23, Gabriel Charette gcharet...@gmail.com 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
On Wed, Sep 28, 2011 at 06:43:04PM -0400, David Miller wrote:
From: Mike Stump mikest...@comcast.net
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.
Hi,
tested x86_64-linux, committed.
Paolo.
//
2011-09-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/40145
* g++.dg/ext/visibility/warn5.C: New.
Index: g++.dg/ext/visibility/warn5.C
===
---
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
Committed to ARM/embedded-4_6-branch.
2011-09-28 Jiangning Liu jiangning@arm.com
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
-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,
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.
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
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
93 matches
Mail list logo
