Jakub, Richard,
I believe this patch is a good opportunity to improve the
vectorization capabilities.
I have the following question related to it: whether we plan to treat
the #pragma omp simd as a
directive to vectorize the underlying loop, hence dropping any
assessment regarding profitablity?
On Oct 15, 2013, at 5:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Especially on i?86/x86_64 if-conversion pass seems to be often
a pessimization, but the vectorization relies on it and without it we can't
vectorize a lot of the loops.
I think on many other targets it actually
Ping?
Michael Hudson-Doyle michael.hud...@linaro.org writes:
Marcus Shawcroft marcus.shawcr...@gmail.com writes:
On 3 October 2013 23:43, Michael Hudson-Doyle michael.hud...@linaro.org
wrote:
Hi,
As libatomic builds for and the tests pass on AArch64 (built on x86_64
but tested on a
This patch bootstraps and tests clean on x86-64-linux.
Truthfully, dynamic_bitset needs some more love wrt C++11 and a testsuite.
It got put in before it was baked really.
That will be later.
2013-10-16 Edward Smith-Rowland 3dw...@verizon.net
PR libstdc++/58729
*
On Wed, Oct 16, 2013 at 07:02:03PM -0400, Tim Shen wrote:
To be honest, I was thinking something much smaller than the whole regex
;) But let's add Marek in CC.
int work() {
}
int main() {
int a = work();
return a;
}
/* This is a smaller case to test the sanitizer. It
On Thu, Oct 17, 2013 at 09:12:41AM +0200, Marek Polacek wrote:
On Wed, Oct 16, 2013 at 07:02:03PM -0400, Tim Shen wrote:
To be honest, I was thinking something much smaller than the whole regex
;) But let's add Marek in CC.
int work() {
}
int main() {
int a = work();
On Wed, 2013-10-16 19:40:21 -0700, Xinliang David Li davi...@google.com wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam tmsri...@google.com
wrote:
I was unable to build a native powerpc compiler. I checked
On Wed, Oct 16, 2013 at 04:25:58PM -0700, Wei Mi wrote:
+/* Return true if target platform supports macro-fusion. */
+
+static bool
+ix86_macro_fusion_p ()
+{
+ if (TARGET_FUSE_CMP_AND_BRANCH)
+return true;
+ else
+return false;
+}
That looks weird, why not just
static bool
What about all the other targets you broke?
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
On Tue, 15 Oct 2013, Richard Biener wrote:
This is an alternate fix (see
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html for the other
one) for the various PRs that show that LIM exposes undefined
signed overflow on paths where it wasn't executed before LIM
ultimately leading to a
On Thu, Oct 17, 2013 at 09:56:31AM +0200, Richard Biener wrote:
off-noise (more than 5s difference) may be 462.libquantum and
459.GemsFDTD. I didn't include unpatched trunk in the comparison
(not fixing the bug isn't an option after all).
Conceptually I like the rewriting into unsigned
On Wed, 16 Oct 2013, Tobias Burnus wrote:
Frederic Riss wrote:
Just one question. You describe the pragma in the doco patch as:
+This pragma tells the compiler that the immediately following @code{for}
+loop can be executed in any loop index order without affecting the result.
+The
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant that there was always an upper zero bit.
Is that right?
i believe this is correct.
If so, xprecision precision is a no-op, because the
Kenneth Zadeck zad...@naturalbridge.com writes:
On 10/15/2013 02:30 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
if (small_prec)
;
else if (precision == xprecision)
while (len = 0 val[len - 1] == -1)
len--;
-Original Message-
From: Joey Ye [mailto:joey.ye...@gmail.com]
There is an issue on file system with symbolic link, like Linux ext2/3. It
could vitally change behavior of GCC. The issue is described as following.
Such a logic cannot be deduced simple from the name string, so
On Thu, Oct 17, 2013 at 10:07:43AM +0200, Richard Biener wrote:
Which suggests we use
#pragma GCC ivdep
to not collide with eventually different semantics in existing programs
that use variants of this pragma?
Yeah, perhaps.
Intel:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant that there was always an upper zero bit.
Is that right?
i believe this is correct.
If
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Mike Stump
Sent: 16 October 2013 23:06
To: Paulo J.Matos
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Teaching emacs about GCC coding conventions (was Re: [PATCH]
tree_code_name
On 10/17/2013 09:17 AM, Jakub Jelinek wrote:
Though, in the above case, the question is why people ignore warnings
from the compiler and need to have special runtime instrumentation to
remind them instead. I'm not objecting to that sanitization, only find
it weird.
I had the same thought.
Hi,
On 10/17/2013 09:04 AM, Ed Smith-Rowland wrote:
This patch bootstraps and tests clean on x86-64-linux.
Truthfully, dynamic_bitset needs some more love wrt C++11 and a
testsuite.
It got put in before it was baked really.
That will be later.
Patch is Ok with me. Before committing you may
Thank you for review. Please see inline
From: Joey Ye [mailto:joey.ye...@gmail.com]
Sent: Thursday, October 17, 2013 7:36 AM
The macro FILENAME_NORMALIZE doesn't look necessary. I would prefer use
filename_normalize directly, just as filename_cmp is used in GCC rather than
FILENAME_CMP
On Wed, 16 Oct 2013, Cong Hou wrote:
On Wed, Oct 16, 2013 at 2:02 AM, Richard Biener rguent...@suse.de wrote:
On Tue, 15 Oct 2013, Cong Hou wrote:
Thank you for your reminder, Jeff! I just noticed Richard's comment. I
have modified the patch according to that.
The new patch is
On Wed, 16 Oct 2013, pins...@gmail.com wrote:
On Oct 15, 2013, at 5:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Especially on i?86/x86_64 if-conversion pass seems to be often
a pessimization, but the vectorization relies on it and without it we can't
vectorize a lot of the
On Thu, 17 Oct 2013, Jakub Jelinek wrote:
On Thu, Oct 17, 2013 at 09:56:31AM +0200, Richard Biener wrote:
off-noise (more than 5s difference) may be 462.libquantum and
459.GemsFDTD. I didn't include unpatched trunk in the comparison
(not fixing the bug isn't an option after all).
Resending as the previous attempt went missing...
2013-10-04 Michael Hudson-Doyle michael.hud...@linaro.org
* libatomic/configure.tgt (aarch64*): Remove code preventing
build.
* gcc/testsuite/lib/target-supports.exp
On 19/09/13 18:21, Charles Baylis wrote:
Hi
Here is an updated version.
Changelog:
* gcc.dg/builtin-apply2.c: skip test on arm hardfloat ABI targets
* gcc.dg/tls/pr42894.c: Remove options, forcing -mthumb fails
with hardfloat, and test is not thumb-specific
*
1) Remove special expansion of NOT IN operator in SPARK verification
The special expansion for NOT IN operator in the SPARK formal verification
mode is not needed anymore. Now removed.
2) Document additional requirements on tree for SPARK verification
Formal verification of SPARK code is done
The generation of references for SPARK formal verification was missing some
write references through renamings. This is now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-10-17 Yannick Moy m...@adacore.com
* sem_ch8.adb (Find_Direct_Name): Keep track of assignments for
The use of a specific light expansion for SPARK verification has rendered
obsolete a number of special handling cases only triggered in the normal
full expansion. Remove these useless cases now.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-10-17 Yannick Moy m...@adacore.com
On 17/10/13 11:32, Richard Earnshaw wrote:
On 19/09/13 18:21, Charles Baylis wrote:
Hi
Here is an updated version.
Changelog:
* gcc.dg/builtin-apply2.c: skip test on arm hardfloat ABI targets
* gcc.dg/tls/pr42894.c: Remove options, forcing -mthumb fails
with hardfloat,
The warning switch -gnatw.y(.Y) activates(deactivates) a mode in which
information messages are given that show why a package spec requires a
body. This can be useful if you have a large package which unexpectedly
requires a body.
1. package ReqBody is
|
info:
On Thu, Oct 17, 2013 at 11:32:42AM +0100, Richard Earnshaw wrote:
On 19/09/13 18:21, Charles Baylis wrote:
Here is an updated version.
Changelog:
* gcc.dg/builtin-apply2.c: skip test on arm hardfloat ABI targets
* gcc.dg/tls/pr42894.c: Remove options, forcing -mthumb
On Wed, Oct 16, 2013 at 6:33 PM, Jeff Law l...@redhat.com wrote:
On 10/16/13 03:31, Richard Biener wrote:
I see two primary effects of type sinking.
Note it was called type demotion ;)
;) It's a mental block of mine; it's been called type hoisting/sinking in
various contexts and I see
Scalar_Storage_Order must be consistent between any component of a composite
type (array or record) and the composite type itself. We already enforced
this in the case where the enclosing type has a Scalar_Storage_Order
attribute definition, and the component type has none. We now also do so
also
This implements the rule in SPARK RM (6.1.5(4)): A global item shall
not denote a state abstraction whose refinement is visible (a state
abstraction cannot be named within its enclosing package's body other
than in its refinement).
The following is compiled with -gnatd.V
1. package
Hello,
On 16 Oct 09:59, Richard Henderson wrote:
On 10/16/2013 09:07 AM, Kirill Yukhin wrote:
I suspect gen_lowpart is bad turn when reload is completed, as
far as it can create new pseudo. gen_lowpart () may call
gen_reg_rtx (), which contain corresponging gcc_assert ().
False.
On Wed, Oct 16, 2013 at 7:53 PM, Bernd Schmidt ber...@codesourcery.com wrote:
The sequence of events here can be summarized as shrink-wrapping causes
the i386 backend to do something that confuses alias analysis. The
miscompilation is that two instructions are swapped by the scheduler
when
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant that there was always an upper zero bit.
Is that
On Thu, Oct 17, 2013 at 4:14 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Oct 16, 2013 at 2:12 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
Hi,
The patch enhances ifcombine pass to recover some non short circuit
branches. Basically, it will do the following transformation:
On Wed, 16 Oct 2013, Kenneth Zadeck wrote:
On 10/15/2013 02:30 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
if (small_prec)
;
else if (precision == xprecision)
while (len = 0 val[len - 1] == -1)
Hi all,
This patch implements the %c output template for inline asm. The code for it is
almost identical to the support in arm, so it's pretty straightforward. I've
added a few compile tests for it as well.
Tested aarch64-none-elf on a model.
Ok for trunk?
Thanks,
Kyrill
[gcc/]
2013-10-17
On Thu, Oct 17, 2013 at 12:47 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
I suspect gen_lowpart is bad turn when reload is completed, as
far as it can create new pseudo. gen_lowpart () may call
gen_reg_rtx (), which contain corresponging gcc_assert ().
False. gen_lowpart is
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way of
canonising
unsigned tree constants
Ping.
On 09 Oct 19:12, Ilya Tocar wrote:
Ping.
On 03 Oct 20:05, Ilya Tocar wrote:
On 26 Sep 21:21, Ilya Tocar wrote:
On 25 Sep 15:48, Richard Biener wrote:
On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar tocarip.in...@gmail.com
wrote:
On 24 Sep 11:02, Richard Biener wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious if we're directly using 128-bit numbers
in addr_wide_int. The justification for the
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious if we're directly using 128-bit numbers
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation of an unsigned 0x8000 is 0x00 0x80 0x00.
When extended to max_wide_int the representation is
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation of an unsigned 0x8000 is 0x00 0x80 0x00.
On 10/17/2013 07:49 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious
Hi Guys,
I would like to make a change to the way %* behaves in spec strings.
Currently whenever %* is encountered the text that was previously
matched is substituted, followed by a space. Thus %{foo=*:bar%*baz}
would match -foo=4 and insert 'bar4 baz'. I would like to change this
so
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation
On 10/17/2013 07:30 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
As mentioned in my message yesterday, I thought your new way of
On Wed, 16 Oct 2013 22:50:20, DJ Delorie wrote:
Not all of them can work, because they describe something that can't
be done in hardware. For example, the first test has an incomplete
bitfield - the fields do not completely describe an int so the
structure is smaller (one byte, according to
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen again?
There is nothing to change. Google follows
http://gcc.gnu.org/contribute.html, like everyone else. Sri just fixed
the
These two patches try to fix handling of zero-precision integer
types (created by struct { int : 0; };). Currently they get
assigned TYPE_MIN/MAX_VALUEs but clearly a zero-precision
integer type does not have a single valid value. Of course
for these nothing should look at TYPE_MIN/MAX_VALUE
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 07:30 AM, Richard Biener wrote:
Oh, so it was the tree rep that changed? _Why_ was it changed?
We still cannot use it directly from wide-int and the extra
word is redundant because we have access to TYPE_UNSIGNED (TREE_TYPE ()).
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation of
Kenneth Zadeck zad...@naturalbridge.com writes:
it avoids a 2nd copy though, which shows nicely what was rummaging in
my head for the last two days - that the int_trais abstraction
was somehow at the wrong level - it should have been traits that
are specific to the storage model? or the
To compute the range of values in the generic actual Index_Type for a
vector, there is a series of compile-time tests to determine which of
Index_Type or Count_Type to use for intermediate values.
In the case of an Index_Type comprising a range of values larger than
in Count_Type, the number of
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies
This patch modifies the logic in the analysis of aspect/pragma Refined_State
to catch a case where a visible variable is used as a constituent in a state
refinement.
-- Source --
-- pack.ads
package Pack
with Abstract_State = State
is
Var : Integer;
procedure
This change ensures that any finalization action required within an expression
that appears as the left operand of a short circuit operator remains
contained within the code fragment that evaluates that operand (and not
scattered after the evaluation of the complete Boolean expression). This
is
Richard Biener rguent...@suse.de writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not all constants are sign-extended. But we can
When generating code, subunits are inserted into the tree of the parent unit,
and their context is added to the context of the parent. This makes it hard
to determine whether any with_clause on the proper body is superfluous. This
patch adds circuitry to detect these superfluous with_clauses when
This patch modifies the analysis of package bodies to suppress an error message
prompting for state refinement when the body's SPARK mode is Off.
-- Source --
-- pack.ads
package Pack
with Abstract_State = State,
Initializes= State
is
procedure Proc
On the basis of further discussion, we decided not to implement the
rule saying that a package body must be required for some other
reason if an abstract state is declared. Now we just say a package
body is required if a non-null abstract state and that's it! This
change undoes the error message.
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
Hi, the last ping of the Nios II patches was:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01416.html
After assessing the state, we feel it would be better to post a
re-submission of the newest patches.
Since this hasn't attracted attention for
Hello,
This patch just reorganizes the SH code used for memory builtins into
its own file, in preparation of the RTL strcmp hoisting in the next part.
OK for trunk ?
Thanks
Christian
2013-10-17 Christian Bruel christian.br...@st.com
* config.gcc (sh-*): Add sh-mem.o to extra_obj.
*
Hello,
This patch adds support to inline an optimized version of strcmp when
not optimizing for size. The generated code makes use of the cmp/str
instruction to test 4 bytes at a time when correctly aligned.
note that a new pattern was added to match the cmp/str instruction, but
no attempt was
Hello,
On 17 Oct 13:14, Uros Bizjak wrote:
On Thu, Oct 17, 2013 at 12:47 PM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
I suspect gen_lowpart is bad turn when reload is completed, as
far as it can create new pseudo. gen_lowpart () may call
gen_reg_rtx (), which contain
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
These are nios2 patches for the gcc testsuite. Some new testcases were
added since the last posting.
Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c
===
---
Richard Biener rguent...@suse.de writes:
What I see is really bad code for the simple integer-cst predicates
in tree.c. I don't mind in what way we fix it, but avoiding the
copy on every tree integer constant read looks required to me.
But we got rid of the copy with yesterday's patch. Are
On 10/17/2013 09:16 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
On Thu, Oct 17, 2013 at 11:26:56AM +0200, Richard Biener wrote:
On Wed, 16 Oct 2013, pins...@gmail.com wrote:
On Oct 15, 2013, at 5:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Especially on i?86/x86_64 if-conversion pass seems to be often
a pessimization, but the vectorization
On Tue, Oct 15, 2013 at 10:46:43PM -0400, Andrew MacLeod wrote:
Bootstraps on 86_64-unknown-linux-gnu and no new regressions. OK?
Andrew
* tree-flow.h (struct omp_region): Move to omp-low.c
Missing dot at the end of line.
Remove omp_ prototypes and variables.
*
On 10/15/2013 05:21 PM, Adam Butcher wrote:
On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote:
1) Build up the type as normal and use tsubst to replace the non-pack
template parameter with a pack if needed.
The problem I've hit with this (and other hacks I've tried that involve
This patch fixes the Go frontend to not dereference an unknown type when
importing an anonymous field. This fixes a bug in a recent patch I
committed. I have a test case ready to commit to the master repository
after the Go 1.2 release is made. This patch bootstrapped and ran Go
testsuite on
On Thu, Oct 17, 2013 at 11:52:21AM -0400, Andrew MacLeod wrote:
On 10/17/2013 11:15 AM, Jakub Jelinek wrote:
*** struct omp_for_data
*** 135,141
static splay_tree all_contexts;
static int taskreg_nesting_level;
static int target_nesting_level;
! struct omp_region
I've merged revision 203772 from the GCC 4.8 branch to the gccgo branch.
Ian
On 10/17/2013 11:15 AM, Jakub Jelinek wrote:
*** struct omp_for_data
*** 135,141
static splay_tree all_contexts;
static int taskreg_nesting_level;
static int target_nesting_level;
! struct omp_region *root_omp_region;
static bitmap task_shared_vars;
static
where in the C standard did you read the requirement that every bit
field must be complete? (This is a serious question).
The spec doesn't say each field must be complete, but neither does it
say that the structure must be as big as the type used. If you
specify int foo:1 then the compile is
On Thu, Oct 17, 2013 at 12:35 AM, Marek Polacek pola...@redhat.com wrote:
On Wed, Oct 16, 2013 at 04:25:58PM -0700, Wei Mi wrote:
+/* Return true if target platform supports macro-fusion. */
+
+static bool
+ix86_macro_fusion_p ()
+{
+ if (TARGET_FUSE_CMP_AND_BRANCH)
+return true;
+
On 17 October 2013 10:43, Michael Hudson-Doyle
michael.hud...@linaro.org wrote:
Resending as the previous attempt went missing...
2013-10-04 Michael Hudson-Doyle michael.hud...@linaro.org
* libatomic/configure.tgt (aarch64*): Remove code preventing
build.
Hi,
in this ICE on valid, 4.8/4.9 Regression, the problem is that, for a
lambda in an NSDMI context, the early return of lambda_expr_this_capture:
/* In unevaluated context this isn't an odr-use, so just return the
nearest 'this'. */
if (cp_unevaluated_operand)
return
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen again?
There is nothing to change. Google follows
Hi,
I spotted that the types of arguments to these intrinsics are wrong,
which results in all sorts of fun issues!
Fixed thusly, regression tested with aarch64.exp on aarch64-none-elf
with no issues.
OK?
Thanks,
James
---
2013-10-17 James Greenhalgh james.greenha...@arm.com
*
On Thu, Oct 17, 2013 at 9:28 AM, Steve Ellcey sell...@mips.com wrote:
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen
OK.
Jason
Hi,
This patch addresses an issue in reload triggered by the
gfortran.dg/loc_2.f90 regression test at -O3 with LRA disabled.
The patch is based on work done by Ian Bolton here at ARM which I've
dusted down and submitted.
Following SFP elimination and under heavy register pressure, reload
On 17 October 2013 12:13, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
[gcc/]
2013-10-17 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/aarch64/aarch64.c (aarch64_print_operand): Handle 'c'.
[gcc/testsuite]
2013-10-17 Kyrylo Tkachov kyrylo.tkac...@arm.com
*
On 17 October 2013 17:27, James Greenhalgh james.greenha...@arm.com wrote:
Hi,
I spotted that the types of arguments to these intrinsics are wrong,
which results in all sorts of fun issues!
Fixed thusly, regression tested with aarch64.exp on aarch64-none-elf
with no issues.
OK?
Thanks,
Hello,
this is a simple test that makes the follwing test cases pass:
because the messages are translated to german,
which the test scripts compare against english messages.
Tested on german ubuntu 12.04.
OK for trunk?
Regards
Bernd.2013-10-17 Bernd
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
The new tree representation can have a length greater than max_len
for
On Thu, Oct 17, 2013 at 09:28:26AM -0700, Steve Ellcey wrote:
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not
On 10/17/13 05:03, Richard Biener wrote:
Is it OK for trunk?
I had a much simpler change which did basically the same from 4.7 (I
can update it if people think this is a better approach).
I like that more (note you can now use is_gimple_condexpr as predicate
for force_gimple_operand).
The
On Thu, Oct 17, 2013 at 06:47:10PM +0200, Bernd Edlinger wrote:
2013-10-17 Bernd Edlinger bernd.edlin...@hotmail.de
PR libmudflap/58230
* testsuite/lib/mfdg.exp: Set C Language.
s/Set C Language/Use C locale/.
Ok with that change.
Jakub
Hi all,
This patch adds the rtx costs table for the Cortex-A9 core.
An arm-none-eabi regression run tuned for A9 succeeded.
This costs tabled showed a slight improvement on some popular benchmarks and no
performance regressions on others against the old way of doing rtx costs.
Ok for trunk?
1 - 100 of 170 matches
Mail list logo
