On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
> In fact, I would suggest that anyone with a pending patch from prior
> to stage1 close that hasn't gotten feedback by midnight Tuesday ping
> their patch. I'd like to have a sense of everything that is
> outstanding sooner rather than lat
Done.
Sergos
On Tue, Nov 26, 2013 at 1:46 PM, Jakub Jelinek wrote:
> On Tue, Nov 26, 2013 at 10:43:32AM +0100, Richard Biener wrote:
>> 2013-11-25 sergey.y.ostanevich
>
> Please use your name with capital letters and spaces rather than
> all lowercase plus dots.
>
> Jakub
2013-11-25
On Wed, Nov 27, 2013 at 10:36:41AM +0400, Yury Gribov wrote:
> > This patch is supposed to fix PR59063
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
> >
> > The original bug results from libasan providing clock_gettime
> wrapper and then trying to call the "real" clock_gettime.
> > The "re
On Tue, Nov 26, 2013 at 9:34 PM, Jeff Law wrote:
> On 11/26/13 12:33, Wei Mi wrote:
>>
>> On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
>>>
>>>
Doing the cleanup at the end of BB could ensure all the groups
inserted for macrofusion will be cleaned. For groups not at the end of
>
> Hopefully someone from AMD will provide tests that are mysteriously missing
> from XOP testsuite.
As pointed out by Marc, I added myself to the bug later.
I was bit confused about the "internal insn representation" with "user-visible
function".
So, couldn't add test then and there. I could ha
> This patch is supposed to fix PR59063
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
>
> The original bug results from libasan providing clock_gettime wrapper
and then trying to call the "real" clock_gettime.
> The "real" symbol is supposed to come from librt.so which was not
necessaril
On 11/26/13 14:10, Tom de Vries wrote:
On 26-11-13 11:12, Richard Biener wrote:
On Tue, Nov 26, 2013 at 8:57 AM, Tom de Vries
wrote:
Jason,
This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3
locations.
It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
simplify_bitfi
On 11/22/13 15:24, Eric Botcazou wrote:
Well, the baseline is:
eric@polaris:~/build/gcc/native> gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc/configure --build=x86_64-suse-linux --
prefix=/home/eric/install/gcc --enable-langu
On 11/25/13 17:29, Kugan wrote:
On 24/11/13 02:14, Ian Lance Taylor wrote:
Kugan writes:
This RFC patch series implements a simple align divisor shift dividend
method.
Regression tested on arm-none-linux-gnueabi with no issues.
OK?
Thanks,
Kugan
+2013-11-22 Kugan Vivekanandarajah
+
+
On 11/26/13 12:33, Wei Mi wrote:
On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
Doing the cleanup at the end of BB could ensure all the groups
inserted for macrofusion will be cleaned. For groups not at the end of
a block, no matter whether they are cleaned up or not, nothing will
happen b
On 27/11/13 02:07, Richard Earnshaw wrote:
> On 23/11/13 01:54, Kugan wrote:
[snip]
>> +2013-11-22 Kugan Vivekanandarajah
>> +
>> +* libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DIVIDE): Define for
>
> It's bpabi-lib.h
Thanks for the review.
>> +__ARM_ARCH_7_A__.
>> +
>>
>>
>
> No, th
Hi,
This patch back ported trunk fix at r205391 to arm/embedded-4_8-branch.
BR,
Terry
gcc/ChangeLog.arm
2013-11-27 Terry Guo
Backport mainline r205391
2013-11-26 Terry Guo
* config/arm/arm.c (require_pic_register): Handle high pic base
register for thumb-1
Ok.
David
On Tue, Nov 26, 2013 at 6:44 PM, Sriraman Tallam wrote:
> Google ref b/11631232
>
> With AutoFDO, the .gnu.callgraph sections are not emitted with option
> -freorder-functions=callgraph. This simple patch fixes it.
>
> Index: final.c
> ==
Google ref b/11631232
With AutoFDO, the .gnu.callgraph sections are not emitted with option
-freorder-functions=callgraph. This simple patch fixes it.
Index: final.c
===
--- final.c (revision 205418)
+++ final.c (working copy)
@@ -44
On Tue, Nov 26, 2013 at 8:37 PM, Alan Modra wrote:
>> I find this whole thread a rather sad and pathetic bikeshed
>> discussion. Regardless of the formal policy, the basic concept is to
>> use common sense. Common sense about the context of the code being
>> changed, common sense about the patch
On Mon, 2013-11-25 at 12:34 -0700, Jeff Law wrote:
> On 11/25/13 08:35, David Malcolm wrote:
> >
> > I'm not a fan of these "_layout" names, but I'm not sure what better to
> > call them. Perhaps:
> > GSS_OMP_PARALLEL_LAYOUT -> GSS_OMP_WITH_CLAUSES_CHILD_FN_DATA_ARG
> > GSS_OMP_SINGLE_L
I've merged revision 205426 from GCC mainline to the gccgo branch.
Ian
> The thing about written policy is that it sets the tone for a project.
> A restrictive policy tends to authoritarian rule by maintainers, it
> seems to me.
And a too little restrictive policy runs the risk of creating a
feeling that the rules aren't necessarily to be taken too seriously.
Neithe
On Tue, Nov 26, 2013 at 04:56:26PM -0500, Robert Dewar wrote:
> To me the issue is not what is written down about
> the policy, but whether the policy works in practice,
> and it seems like it does, so what's the problem?
>
> This just seems to be making a problem where
> none exists.
I gave some
On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw wrote:
> 2013-11-24 Jan-Benedict Glaw
>
> * config-list.mk (host_options): Allow to override it.
> (LIST): Change "=" to "EQUAL".
> (list): New target listing all configurations.
> ($(LIST)): Substitute "EQUAL" back t
On Tue, Nov 26, 2013 at 04:30:50PM -0500, David Edelsohn wrote:
> >> Sorry to pick on you here Steven, but this doesn't meet gcc's
> >> definition of an obvious patch. Don't believe me?
>
> > No. I don't, let me quote from the policy:
>
> I find this whole thread a rather sad and pathetic bikes
We will of course measure it but the only thing that is different because of
the conversion is that timode integers are packaged differently
> On Nov 26, 2013, at 6:17 PM, David Edelsohn wrote:
>
>> On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump wrote:
>>
>> Ok?
>
> The revised version of the
This patch updates libgo to the current Go library sources, which will
almost certainly be the Go library included in the Go 1.2 release.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 827fb5004620 libgo/MERGE
--- a/libgo/MERGE Tue Nov 26 15:22:1
On 11/26/2013 03:47 AM, Marc Glisse wrote:
On Tue, 26 Nov 2013, Tom de Vries wrote:
* g++.dg/pr59032.C: New testcase.
* gcc.dg/pr59032.c: Same.
I didn't check very carefully, but they look similar. If they are indeed
the same, could it move to c-c++-common?
OK with that change.
Jas
On Tue, Nov 26, 2013 at 5:46 PM, Mike Stump wrote:
> Ok?
The revised version of the patch looks okay from a technical
perspective, but I still am concerned about the compile-time impact. I
thought that I saw a comment on IRC that wide-int seems to have a 3-5%
compile time impact, which is a conc
On Wed, Nov 27, 2013 at 12:31:18AM +0100, Jakub Jelinek wrote:
> Please use here:
> int z = 2;
> if (z & 1)
> or similar instead, to make sure it is only early
> GIMPLE optimization passes that optimize it away, if already the
> front end knows it isn't needed, perhaps in the future it could
>
On Wed, Nov 27, 2013 at 12:26:08AM +0100, Marek Polacek wrote:
> Ran the testsuite on x86_64-linux. Ok for trunk?
Ok, with a minor nit.
> --- gcc/testsuite/c-c++-common/ubsan/undefined-1.c.mp32013-11-26
> 23:56:42.151624262 +0100
> +++ gcc/testsuite/c-c++-common/ubsan/undefined-1.c2
This patch to libgo fixes the handling of surrogate pairs when
converting a []rune value to string. Invalid surrogate pair values
should become the replacement character in the string, as otherwise the
string will not be valid UTF-8. I have a patch ready for the master Go
testsuite after the 1.2
This patch does two things:
1) The hash table should consume VAR_DECLs rather than ADDR_EXPRs; the
latter allegedly cannot be shared between different locations.
2) Sometimes it can happen that some earlier instrumentation (e.g.
-fsanitize=shift) creates an .Lubsan_type, but later on
varp
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> Thanks for doing this conversion work. A few questions and comments:
>
> 1) Because rs6000 is one of the few ports that was completely
> converted to wide-int instead of simply accommodating wide-int, what
> is the compile-time performance im
On 11/26/13 02:26, Richard Biener wrote:
But only necessary if this threading returned true, no?
Correct. Fix for that spinning overnight.
Also
how "likely" did it scramble the loop? I see that thread_block_1
already cancels loops in some cases so I wonder what case
it misses so that you n
On Nov 26, 2013, at 3:58 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
>>> 3) altivec_resolve_overloaded_builtin, both hunks should be converted
>>> the same way, using tree_fits_uhwi_p
>>>
>>> - && TREE_CODE (arg2) == INTEGER_CST
>>
> On 11/26/13 13:20, Jakub Jelinek wrote:
> >Hi!
> >
> >As the testcase in the patch shows, if exact memcpy or memset count
> >is unknown, but max_size is smaller than epilogue_size_needed,
> >ix86_expand_set_or_movmem can ICE.
> >
> >The following patch fixes that, bootstrapped/regtested on x86_64
To me the issue is not what is written down about
the policy, but whether the policy works in practice,
and it seems like it does, so what's the problem?
This just seems to be making a problem where
none exists.
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> 2) non_logical_cint_operand changed const_double to const_wide_int, it
> did not add the additional CODE. Mike explained why in a private
> conversation, but the ChangeLog should be corrected.
Index: gcc/ChangeLog.wide-int
On 11/26/13 02:58, Richard Biener wrote:
What is the rationale behind one for over the other? Or is it arbitrary? I
can easily make a case for either form based on what we're trying to
optimize. In general, it seems to me that
When (Type) is a widening cast then you have to worry to not
On Nov 25, 2013, at 12:03 PM, David Edelsohn wrote:
> 5) rs6000_aggregate_candidate, is this change correct for Ada and
> non-constant type size?
No. It was merely an oversight in converting the code.
I've analyzed it, and think that we can speed up Ada and VLAs by keeping all
the checks for t
>> Sorry to pick on you here Steven, but this doesn't meet gcc's
>> definition of an obvious patch. Don't believe me?
> No. I don't, let me quote from the policy:
I find this whole thread a rather sad and pathetic bikeshed
discussion. Regardless of the formal policy, the basic concept is to
use
Hi Jakub,
Did you get a chance to look at this patch? Is it Ok to install?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Tuesday, November 19, 2013 5:09 PM
> To: Jakub Jelinek
> Cc: Joseph S. Myers; gcc-patches@gcc.gnu.org; Aldy Hernandez
> (al...@re
On 11/26/13 13:14, Jakub Jelinek wrote:
Hi!
The problem here is that ubsan_create_data was called
with location_t that includes both location and BLOCK, and that
location was sticked into an ADDR_EXPR in a static var's constructor.
As the BLOCk wasn't live in any of the functions, it was removed
On 11/26/13 13:25, Jakub Jelinek wrote:
Hi!
The problem on this testcase is that we have
(debug_insn 30 29 31 7 (var_location:HI D#1 (subreg:HI (reg/v:SI 93 [ p ]) 0))
pr59166.c:20 -1
(nil))
and split_live_ranges_for_shrink_wrap decides to replace
SImode pseudo 93 with some other SImode p
On 11/26/13 13:20, Jakub Jelinek wrote:
Hi!
As the testcase in the patch shows, if exact memcpy or memset count
is unknown, but max_size is smaller than epilogue_size_needed,
ix86_expand_set_or_movmem can ICE.
The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux
On 11/26/13 13:33, Jakub Jelinek wrote:
Hi!
Given:
_6 = (_Bool) a.1_5;
_7 = _4 | _6;
if (_7 != 0)
goto ;
else
goto ;
where a.1_5 has int type and _6/_4/_7 are _Bool, register_edge_assert_for_1
happily inserts:
:
a.1_14 = ASSERT_EXPR ;
assertion, which is wrong, the fa
On 26-11-13 11:12, Richard Biener wrote:
On Tue, Nov 26, 2013 at 8:57 AM, Tom de Vries wrote:
Jason,
This patch prevents creating out-of-bounds BIT_FIELD_REFs in 3 locations.
It fixes a SIGSEGV (triggered by gimple_fold_indirect_ref_1) in
simplify_bitfield_ref. I've added an assert to detect
On Nov 26, 2013, at 11:39 AM, Uros Bizjak wrote:
>* gcc.dg/gomp/openmp-simd-1.c: Cleanup original tree dump.
Thanks.
On Nov 25, 2013, at 9:17 PM, Alan Modra wrote:
> Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR
> On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
>> This patch is obvious and it fixes breakage. Please go ahead and commit it.
>
> Sorry to pick on you here Steven,
On 11/26/13 13:34, Steven Bosscher wrote:
On Tue, Nov 26, 2013 at 9:25 PM, Jakub Jelinek wrote:
\> PR rtl-optimization/59166
* ira.c (find_moveable_pseudos): Use DF_REF_REAL_LOC instead of
DF_REF_LOC in validate_change call.
(split_live_ranges_for_shrink_wrap):
Hi!
The problem on this testcase was that
start_preparsed_function called maybe_begin_member_template_processing
but finish_function wasn't called with matching flag and thus
didn't call maybe_end_member_template_processing and we ended up with
processing_template_decl even when it shouldn't be se
Hi!
The problem here is that lower_rec_input_clauses for privatized reference
vars in clauses adds u = &u.1; statements, which is usually the right thing,
but if this is a reduction in simd loop for which we are going to handle
using simd arrays, then we want to set DECL_VALUE_EXPR of the var to
s
Hi!
If collapse_bb != NULL, then cont_bb isn't a latch of schedule(static,C)
collapse(N) omp for loops, and the latch for simd loops was only correct
if the loop contained just two basic blocks and not more.
Fixed thusly, bootstrapped/regtested on x86_64-linux, committed to trunk.
2013-11-26 Ja
On Tue, Nov 26, 2013 at 9:34 PM, Steven Bosscher wrote:
> On Tue, Nov 26, 2013 at 9:25 PM, Jakub Jelinek wrote:
> \> PR rtl-optimization/59166
>> * ira.c (find_moveable_pseudos): Use DF_REF_REAL_LOC instead of
>> DF_REF_LOC in validate_change call.
>> (split_live_ran
On Tue, Nov 26, 2013 at 9:25 PM, Jakub Jelinek wrote:
\> PR rtl-optimization/59166
> * ira.c (find_moveable_pseudos): Use DF_REF_REAL_LOC instead of
> DF_REF_LOC in validate_change call.
> (split_live_ranges_for_shrink_wrap): Likewise.
>
> * gcc.dg/torture/pr
Hi!
Given:
_6 = (_Bool) a.1_5;
_7 = _4 | _6;
if (_7 != 0)
goto ;
else
goto ;
where a.1_5 has int type and _6/_4/_7 are _Bool, register_edge_assert_for_1
happily inserts:
:
a.1_14 = ASSERT_EXPR ;
assertion, which is wrong, the fact that _6 is known to be 0 doesn't
imply that a.1
Jakub Jelinek wrote:
>Hi!
>
>Uros has reported my optimize_vector_constructor optimization causes
>problems on Alpha which for some vector modes supports only moves, but
>not
>arithmetics. The following patch fixed that in a cross compiler,
>and has been bootstrapped/regtested on x86_64-linux and
Hi!
The problem on this testcase is that we have
(debug_insn 30 29 31 7 (var_location:HI D#1 (subreg:HI (reg/v:SI 93 [ p ]) 0))
pr59166.c:20 -1
(nil))
and split_live_ranges_for_shrink_wrap decides to replace
SImode pseudo 93 with some other SImode pseudo. But it
uses DF_REF_LOC, which is ad
Hi!
As the testcase in the patch shows, if exact memcpy or memset count
is unknown, but max_size is smaller than epilogue_size_needed,
ix86_expand_set_or_movmem can ICE.
The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
Though, the resulting cod
Hi!
Uros has reported my optimize_vector_constructor optimization causes
problems on Alpha which for some vector modes supports only moves, but not
arithmetics. The following patch fixed that in a cross compiler,
and has been bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for trunk?
Hi!
The problem here is that ubsan_create_data was called
with location_t that includes both location and BLOCK, and that
location was sticked into an ADDR_EXPR in a static var's constructor.
As the BLOCk wasn't live in any of the functions, it was removed as unused
and the GCmemory was reused for
Hello!
2013-11-26 Uros Bizjak
* gcc.dg/gomp/openmp-simd-1.c: Cleanup original tree dump.
* gcc.dg/gomp/openmp-simd-2.c: Ditto.
* g++.dg/gomp/openmp-simd-1.C: Ditto.
* g++.dg/gomp/openmp-simd-2.C: Ditto.
* gfortran.dg/c_loc_test_22.f90: Ditto.
* gcc.dg/tree-ssa/attr-alia
On Tue, Nov 26, 2013 at 9:52 AM, Matthew Leach wrote:
> Hi,
>
> When unwinding the stack, the unwind code checks for two opcodes that
> denote a registrations of a signal handler. This is broken on BE as
> the opcodes will be in the wrong byte-order as insns are always LE.
>
> Add the correct chec
On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
>
>>
>> Doing the cleanup at the end of BB could ensure all the groups
>> inserted for macrofusion will be cleaned. For groups not at the end of
>> a block, no matter whether they are cleaned up or not, nothing will
>> happen because other passes wi
On 11/26/2013 11:43 AM, Paolo Carlini wrote:
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your convenience - which trigger the assert !really_overloaded_fn
(t) ... What do you suggest?
Aha. Well, in that case we really can't get a constant value, so I'd
assert
On 11/26/13 05:59, Alexander Ivchenko wrote:
Hi,
The patch addresses the issue Jan-Benedict's buildrobot found:
http://gcc.gnu.org/ml/gcc/2013-11/msg00507.html
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7704433..da9a3e2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+201
This patch changes the Go frontend so that if a type is defined in terms
of another named type, the hash and equality functions are simply
forwarded to that other type. Without this, programs could fail to link
if the other named type is defined in some other package and uses
unexported types defi
This patch from Michael Hudson-Doyle fixes the value of
SizeofSockaddrAny in the syscall package. I'm not sure where the
incorrect value came from. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.8 branch.
Ian
diff -r 8f2a489c6452 -r bcd0cf1ac784 libg
> I had not realized that you were into self abuse like that. you are
> going to have a bad time. I tried this as a way to test the wide-int
> branch because if we made hwi be 32bits, then it would trigger the long
> version of the implementation wide-int routines. What a disaster
> richar
Hi,
When unwinding the stack, the unwind code checks for two opcodes that
denote a registrations of a signal handler. This is broken on BE as
the opcodes will be in the wrong byte-order as insns are always LE.
Add the correct checks when compiling for AArch64 big endian.
This has been tested wit
On Tue, Nov 26, 2013 at 12:40 PM, Iyer, Balaji V
wrote:
>
>
>> -Original Message-
>> From: Eric Botcazou [mailto:ebotca...@adacore.com]
>> Sent: Tuesday, November 26, 2013 12:33 PM
>> To: Iyer, Balaji V
>> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher
>> Subject: Re
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Tuesday, November 26, 2013 12:33 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher
> Subject: Re: gcc's obvious patch policy
>
> > Can I make a suggestion that
On 26/11/13 17:14, Iyer, Balaji V wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Jeff Law
>> Sent: Tuesday, November 26, 2013 11:31 AM
>> To: Diego Novillo; Steven Bosscher; gcc-patches
>> Subject: Re: gcc's
> Can I make a suggestion that if someone is making an "obvious" change (with
> the exception of changing non-working code (comments, things inside #if 0,
> etc)), have a patch on the mailing list for 12-24 hrs. before putting it
> in? Maybe they could say something like, I will check this in by X
On Tue, Nov 26, 2013 at 05:14:22PM +, Iyer, Balaji V wrote:
>
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Jeff Law
> > Sent: Tuesday, November 26, 2013 11:31 AM
> > To: Diego Novillo; Steven Bosscher; gcc-pa
Hi Jeff et al.,
Did you get a chance to look at my _Cilk_for patch for C?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, November 18, 2013 4:51 PM
> To: Aldy Hernandez
> Cc: gcc-patches@gcc.gnu.org; Jeff Law; Jason Merrill (ja...@redhat.com);
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, November 26, 2013 11:31 AM
> To: Diego Novillo; Steven Bosscher; gcc-patches
> Subject: Re: gcc's obvious patch policy
>
> On 11/26/13 08:21, Diego
Hi,
On 11/26/2013 04:30 PM, Jason Merrill wrote:
A BASELINK isn't useful as a constant, either; I was thinking of the
FUNCTION_DECL itself. Perhaps
gcc_checking_assert (!really_overloaded_fn
return get_first_fn
We have got a bunch of testcases, for example constexpr-ex4.C - attached
for your
Richi,
patch ping
also two more pieces of information.With further testing, this seems
to fix
Tests that now work, but didn't before:
===
ext/random/hypergeometric_distribution/operators/values.cc (test for
excess errors)
New tests that PASS:
ext/random/hypergeometric_dist
On 11/26/13 08:21, Diego Novillo wrote:
On Tue, Nov 26, 2013 at 12:17 AM, Alan Modra wrote:
Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR
On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
This patch is obvious and it fixes breakage. Please go ahead and commit
On 11/26/2013 05:40 AM, Paolo Carlini wrote:
Hi,
On 11/23/2013 11:35 PM, Jason Merrill wrote:
On 10/20/2013 12:07 PM, Paolo Carlini wrote:
case COMPONENT_REF:
+ if (is_overloaded_fn (TREE_OPERAND (t, 1)))
+return t;
Hmm, I'd be inclined to strip the COMPONENT_REF in this case t
Hi,
this patch fixes a reported issue for windows targets in winnt.c.
This is a classical C++ related warning issue.
ChangeLog
2013-11-26 Kai Tietz
* config/i386/winnt.c (i386_pe_section_type_flags): Use const
pointer cast.
I will apply soon, if there are no objections.
Reg
On 11/26/2013 09:16 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu wrote:
On Tue, Nov 26, 2013 at 6:03 AM, wrote:
On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
wrote:
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw
Hi,
On Wed, 20 Nov 2013, Jeff Law wrote:
> > There are three places the patch doesn't touch:
> >
> > (A) cfgbuild.c (make_edges) has this comment:
> >/* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb
> > block
> > is always the entry. */
> > where the meaning wasn't
On 11/26/2013 09:12 AM, Richard Biener wrote:
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
wrote:
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but
On Tue, Nov 26, 2013 at 12:17 AM, Alan Modra wrote:
> Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR
> On Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
>> This patch is obvious and it fixes breakage. Please go ahead and commit it.
>
> Sorry to pick on you here Ste
On 23/11/13 01:54, Kugan wrote:
> Hi All,
>
> This RFC patch enables new divide algorithm for ARMV7-A
>
> Regression tested on arm-none-linux-gnueabi with no issues.
>
> OK?
>
> Thanks,
> Kugan
>
> +2013-11-22 Kugan Vivekanandarajah
> +
> + * libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DI
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhang wrote:
Hi Bill,
On 11/13/13 20:54, Bill Schmidt wrote:
Hi Yufeng,
The second version of your original patch is ok with me with the
following changes. Sorry for the little side adventure into the
next-i
On 26/11/13 14:49, Kyrill Tkachov wrote:
> Hi all,
>
> In the spirit of stage3, this patch fixes a regression in
> gcc.target/arm/negdi-2.c when compiling for big-endian with the new rtx costs
> for the Cortex-A9. We ended up generating an extra mov because combine
> generates
> a zero-extend
On 26/11/13 14:16, Venkataramanan Kumar wrote:
> Index: gcc/testsuite/gcc.dg/fstack-protector-strong.c
> ===
> --- gcc/testsuite/gcc.dg/fstack-protector-strong.c(revision 205378)
> +++ gcc/testsuite/gcc.dg/fstack-protector-strong.c
On Mon, Nov 25, 2013 at 4:29 PM, Kugan
wrote:
>
> +2013-11-26 Kugan Vivekanandarajah
> +
> + * libgcc/libgcc2.c (__udivmoddi4): Define new implementation when
> + TARGET_HAS_NO_HW_DIVIDE is defined, for processors without any divide
> + instructions.
> +
>
>
> +2013-11-26 Kug
Hi all,
In the spirit of stage3, this patch fixes a regression in
gcc.target/arm/negdi-2.c when compiling for big-endian with the new rtx costs
for the Cortex-A9. We ended up generating an extra mov because combine generates
a zero-extend operation that would later get split into two moves (ve
Hi Joseph/Jakub,
Attached is Version 2 patch that adds machine descriptions for stack
protection in Aarch64. I have removed the incorrect test case changes
from the previous patch.
To make GCC compatible with glibc, I have added a test for aarch64 in
"GCC/configure".
This tests for the glibc vers
On Tue, Nov 26, 2013 at 3:15 PM, H.J. Lu wrote:
> On Tue, Nov 26, 2013 at 6:03 AM, wrote:
>>
>>
>>> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>>>
>>> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
>>> wrote:
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
> On 26/11/13
On Tue, Nov 26, 2013 at 6:03 AM, wrote:
>
>
>> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>>
>> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
>> wrote:
>>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
>> you are correct - this w
On Tue, Nov 26, 2013 at 3:00 PM, Kenneth Zadeck
wrote:
>
> On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
>>
>> On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but it is impossible to test it
> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>
> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
> wrote:
>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
>>> On 26/11/13 09:18, Eric Botcazou wrote:
> you are correct - this was an incorrect change. I believe that the
>
On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
wrote:
> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
>> On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but it is impossible to test it
On 11/26/2013 08:44 AM, Richard Earnshaw wrote:
On 26/11/13 09:18, Eric Botcazou wrote:
you are correct - this was an incorrect change. I believe that the
patch below would be correct, but it is impossible to test it because (i
believe) that gcc no longer works if the host_bits_per_wide_int i
On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
> On 26/11/13 09:18, Eric Botcazou wrote:
>>> you are correct - this was an incorrect change. I believe that the
>>> patch below would be correct, but it is impossible to test it because (i
>>> believe) that gcc no longer works if the host
This fixes PR59288 - re-analyzing via SCEV after performing some
loop transform is fragile - we have STMT_VINFO_LOOP_PHI_EVOLUTION_PART
to avoid doing this. The following applies this also to induction.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-11-26 Richard
On 26/11/13 12:29, Yufeng Zhang wrote:
> Hi,
>
> arm_legitimize_address forces immediates in PLUS to be in REG for no
> good reason. This patch changes it not to do this.
>
> With the immediate constants directly available in the RTL, it helps the
> expand more effectively to fold and re-assoc
This fixes PR59245 by more carefully dropping TREE_OVERFLOW
inside VRP (where formerly we only dropped TREE_OVERFLOW from
infinities). It also adds checking ...
Bootstrapped on x86_64-unknown-linux-gnu, 2nd version in
testing (if that doesn't succeed I'm going to remove the new
checking again).
1 - 100 of 154 matches
Mail list logo
