Ping?
Michael Hudson-Doyle writes:
> Marcus Shawcroft writes:
>
>> On 3 October 2013 23:43, Michael Hudson-Doyle
>> wrote:
>>> Hi,
>>>
>>> As libatomic builds for and the tests pass on AArch64 (built on x86_64
>>> but tested on a foundation model, logs and summary:
>>>
>>> http://people.l
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
* include/tr
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
> > ;) 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.
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
> > > ;) But let's add Marek in CC.
> >
> > int work() {
> > }
> >
> > int main() {
> > int a =
On Wed, 2013-10-16 19:40:21 -0700, Xinliang David Li wrote:
> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> > On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam
> > wrote:
> > > I was unable to build a native powerpc compiler. I checked for
> > > build_target_node and build_optimizatio
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
sta
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
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.
>
Kenneth Zadeck 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 number always
>> ha
Kenneth Zadeck writes:
> On 10/15/2013 02:30 PM, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>>if (small_prec)
>>> ;
>>>else if (precision == xprecision)
>>> while (len >= 0 && val[len - 1] == -1)
>>>len--;
>> Err, len > 0 obviously.
> you
> -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,
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:
> > http://software.intel.com/sites/products/d
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Kenneth Zadeck 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, xprecis
> -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
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.
Pao
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 w
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
On Wed, 16 Oct 2013, Cong Hou wrote:
> On Wed, Oct 16, 2013 at 2:02 AM, Richard Biener 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 attache
On Wed, 16 Oct 2013, pins...@gmail.com wrote:
>
> > On Oct 15, 2013, at 5:32 AM, Jakub Jelinek 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 lo
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
* libatomic/configure.tgt (aarch64*): Remove code preventing
build.
* gcc/testsuite/lib/target-supports.exp
(check_effective_target_sync_long_long): AArch64
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 in
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
* sem_ch8.adb (Find_Direct_Name): Keep track of assignments for
renamings
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
* exp_ch3.adb (Ex
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
>>
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: "Req
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, for
On Wed, Oct 16, 2013 at 6:33 PM, Jeff Law 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 pa
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 i
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 Depends_I
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 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 they shouldn't be, du
Richard Biener writes:
> On Thu, 17 Oct 2013, Richard Sandiford wrote:
>
>> Kenneth Zadeck 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
On Thu, Oct 17, 2013 at 4:14 AM, Andrew Pinski wrote:
> On Wed, Oct 16, 2013 at 2:12 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> The patch enhances ifcombine pass to recover some non short circuit
>> branches. Basically, it will do the following transformation:
>>
>> Case 1:
>> if (cond1)
>> i
On Wed, 16 Oct 2013, Kenneth Zadeck wrote:
> On 10/15/2013 02:30 PM, Richard Sandiford wrote:
> > Richard Sandiford writes:
> > >if (small_prec)
> > > ;
> > >else if (precision == xprecision)
> > > while (len >= 0 && val[len - 1] == -1)
> > >len--;
>
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 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 perfectly safe pos
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> >> Kenneth Zadeck writes:
> >> >> As mentioned in my message yesterday, I thought your new way of
> >> >> canonising
> >> >> unsigned tree constants meant that there wa
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
> > > > 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 asserti
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 num
Richard Biener 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 the same.
>
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener 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 e
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 t
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener 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 0x80
On 10/17/2013 07:30 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant
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
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn 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 oversight and if th
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 you
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 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 writes:
> On Thu, 17 Oct 2013, Richard Sandiford wrote:
>
>> Richard Biener 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
Kenneth Zadeck 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 above should use
>>
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 va
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> >> The new tree representation can have a length greater than max_len
> >> >> for an unsigned tree constant that occupies a whole number o
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 hel
Richard Biener 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 use b
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 t
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. S
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
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
* config.gcc (sh-*): Add sh-mem.o to extra_obj.
* gcc/config/sh/t-sh (sh-m
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 ma
Hello,
On 17 Oct 13:14, Uros Bizjak wrote:
> On Thu, Oct 17, 2013 at 12:47 PM, 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_as
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener 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
> ===
> --- gcc/tes
Richard Biener 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 you talking
abou
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 writes:
The new tree representation can have a length greater than max_len
for an unsigned tre
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 wrote:
> > > Especially on i?86/x86_64 if-conversion pass seems to be often
> > > a pessimization, but the vectorization relies o
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
finishing
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 x86
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;
> >>! s
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 void
> 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
On Thu, Oct 17, 2013 at 12:35 AM, Marek Polacek 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;
>> + e
On 17 October 2013 10:43, Michael Hudson-Doyle
wrote:
> Resending as the previous attempt went missing...
>
> 2013-10-04 Michael Hudson-Doyle
>
> * libatomic/configure.tgt (aarch64*): Remove code preventing
> build.
>
> * gcc/testsuite/lib/target-supports
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 lookup_
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn 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/contr
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
* config/aarch64/arm_neon.h
On Thu, Oct 17, 2013 at 9:28 AM, 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 wrote:
>>
>> > How is Google going to change its patch commit policies to ensure that
>> > this does not happen again?
>>
>> There is n
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
attemp
On 17 October 2013 12:13, Kyrill Tkachov wrote:
> [gcc/]
> 2013-10-17 Kyrylo Tkachov
>
> * config/aarch64/aarch64.c (aarch64_print_operand): Handle 'c'.
>
> [gcc/testsuite]
> 2013-10-17 Kyrylo Tkachov
>
> * gcc.target/aarch64/c-output-template.c: New testcase.
> * gcc.target/aar
On 17 October 2013 17:27, James Greenhalgh 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,
> James
>
>
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 Edlinger
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occ
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 wrote:
> >
> > > How is Google going to change its patch commit policies to ensure that
> > > this does not happen again?
> >
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener 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
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 obv
On Thu, Oct 17, 2013 at 06:47:10PM +0200, Bernd Edlinger wrote:
> 2013-10-17 Bernd Edlinger
>
> 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?
T
On Mon, Oct 14, 2013 at 08:51:15PM -0400, David Edelsohn wrote:
> > [gcc]
> > 2013-10-11 Michael Meissner
> >
> > PR target/58673
> > * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Only
> > restrict TImode addresses to single indirect registers if both
> >
On Thu, 17 Oct 2013, DJ Delorie wrote:
> > It is as Sandra said, at least on ARM -fstrict-volatile-bitfields
> > does not function at all. And the C++11 memory model wins all the time.
>
> Are we talking about N2429? I read through the changes and it didn't
> preclude honoring the user's types.
1 - 100 of 168 matches
Mail list logo
