On 03/04/2016 12:30 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping a texinfo fix for __builtin_alloca*:
http://gcc.gnu.org/ml/gcc-patches/2016-02/msg01842.html
OK.
jeff
On 03/02/2016 02:05 PM, Dominik Vogt wrote:
> gcc/testsuite/ChangeLog
>
> * go.test/go-test.exp: S/390: Set GOARCH to the current target when
> testing multiarch.
Applied. Thanks!
-Andreas-
Hi!
I'd like to ping a texinfo fix for __builtin_alloca*:
http://gcc.gnu.org/ml/gcc-patches/2016-02/msg01842.html
Jakub
On 03/03/2016 05:35 AM, Richard Biener wrote:
The following patch adjusts strict_aliasing_warning to use
proper alias_set_subset_of instead of relying on alias_sets_conflict_p
as after the PR66110 fix aggregates with a char[] member do not
automatically behave like having alias-set zero. As a s
On Fri, Mar 04, 2016 at 12:10:26AM -0700, Jeff Law wrote:
> On 03/03/2016 07:35 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >I'd like to ping fix for P1 PR69947:
> >https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html
> So essentially this is just marking more things so that we don't prune them
> awa
On 03/03/2016 08:21 AM, David Malcolm wrote:
Comment #1 of PR c/68187 identified another overzealous warning
from -Wmisleading-indentation, with OpenSSL 1.0.1, on this poorly
indented code:
115if (locked)
116i = CRYPTO_add(&e->struct_ref, -1, CRYPTO_LOCK_ENGINE);
117else
118
On 03/03/2016 08:21 AM, David Malcolm wrote:
PR c/68187 covers two cases involving poor indentation where
the indentation is arguably not misleading, but for which
-Wmisleading-indentation emits a warning.
The two cases appear to be different in nature; one in comment #0
and the other in comment
On 03/03/2016 07:35 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping fix for P1 PR69947:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html
So essentially this is just marking more things so that we don't prune
them away, right?
It's similar conceptually to one of Pierre-Marie's patches wh
On Thu, Mar 03, 2016 at 11:31:08PM -0700, Jeff Law wrote:
> >2016-03-03 Marek Polacek
> >
> > PR c/69798
> > * c-parser.c (c_parser_postfix_expression): Call
> > c_parser_cast_expression instead of c_parser_postfix_expression.
> >
> > * gcc.dg/cilk-plus/pr69798-1.c: New test.
> >
On 03/03/2016 09:15 AM, Marek Polacek wrote:
On Thu, Mar 03, 2016 at 03:28:01PM +0100, Jakub Jelinek wrote:
On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
_Cilk_spawn (void) is invalid. The function
On Thu, Mar 03, 2016 at 10:52:20PM -0700, Jeff Law wrote:
> On 03/03/2016 07:28 AM, Jakub Jelinek wrote:
> >On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
> >>This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so
> >>e.g.
> >>_Cilk_spawn (void) is invalid. The
On 03/03/2016 07:28 AM, Jakub Jelinek wrote:
On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
_Cilk_spawn (void) is invalid. The function call after the cilk_spawn keyword
is parsed using recursive cal
On 03/03/2016 07:15 AM, Marek Polacek wrote:
This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
_Cilk_spawn (void) is invalid. The function call after the cilk_spawn keyword
is parsed using recursive call in c_parser_postfix_expression (case
RID_CILK_SPAWN). Now, c_
On 4 Mar 2016, at 1:43 AM, Bernd Schmidt wrote:
>
> On 03/03/2016 04:18 PM, Mike Stump wrote:
>> On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote:
>>> I have revised the patch and removed the limits.
>>
>> I looked at the patch, I can find no more unreasonable limits! Wonderful.
>> Hope someon
One thing I overlooked in my implementation of C++14 constexpr is that
it changed operator= to be potentially constexpr.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 445b5c0054f338e6c1904ae4ff09fa0761222fd3
Author: Jason Merrill
Date: Tue Mar 1 23:06:54 2016 -0500
* method.c (s
In this testcase, instantiating the return type doesn't work before
we've instantiated the declaration of the operator(). Furthermore,
instantiating the operator() declaration necessarily instantiates the
return type, so we can wait and look it up from there.
Tested x86_64-pc-linux-gnu, apply
When we instantiate an element of a pack expansion, we replace the
argument pack in the template argument vec with an ARGUMENT_PACK_SELECT
which indicates the desired element of the vec. If the args have been
used to instantiate other templates as well, the args of those instances
get modified
On 02/16/16 14:56, Evandro Menezes wrote:
On 12/08/15 15:35, Evandro Menezes wrote:
Emit square root using the Newton series
2015-12-03 Evandro Menezes
gcc/
* config/aarch64/aarch64-protos.h (aarch64_emit_swsqrt):
Declare new
function.
* config/a
On Feb 25, 2016, at 12:15 PM, Thomas Schwinge wrote:
> On Thu, 25 Feb 2016 11:45:06 -0800, Mike Stump wrote:
>> On Feb 25, 2016, at 11:10 AM, Thomas Schwinge
>> wrote:
>>> +set lines [libffi_target_compile $src /dev/null assembly “"]
>>
>> Does this work on a dos box, or windows or other r
This was missing a use of NSDMI when considering list-initialization via
aggregate initialization in overload resolution.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit c2a038bbd3c2a82cc6f6679e5a70705f48571e07
Author: Jason Merrill
Date: Wed Mar 2 17:24:27 2016 -0500
* cal
On 12/14/2011 12:14 AM, Jason Merrill wrote:
The code for casting to rvalue ref was assuming that no base adjustment
would be necessary. This patch delegates to the normal lvalue binding
code, and then changes the result to be an rvalue reference.
The test for DECL_P isn't sufficient to catch
On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
wrote:
>
> On 18/02/16 13:22, Bernd Schmidt wrote:
>>
>> On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
>>>
>>> Here is the reformatted patch:
>>
>>
>> This will probably have to wait until stage1.
>>
>>> + const int code = GET_COD
On 02/25/2016 09:08 AM, Jason Merrill wrote:
We don't bother evaluating a store to an empty class member, and we
shouldn't complain about accesses either.
This needs to use really_empty_class, since that's what
expand_aggr_init_1 uses.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
c
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting
> This works though, ok for trunk?
>
> 2016-03-03 Jakub Jelinek
>
> PR ada/70017
> * gcc.dg/pr70017.c (foo): Store 0 to first element of each array.
Sure, thanks.
--
Eric Botcazou
On 03/03/2016 07:59 AM, Paul Richard Thomas wrote:
> Dear All,
>
> What started out as a provisional kludge, when first working on OOP,
> has come back to bite us after 7 years. A collision in derived type
> has values has been reported on clf. In principle, as pointed out in
> the clf thread, thi
On Thu, Mar 03, 2016 at 01:08:41PM +0100, Jakub Jelinek wrote:
> Fixed thusly, unfortunately I don't have access to avx512f (and not even to
> avx512dq) hw, so while I will bootstrap/regtest it on Haswell-E, can't test
> the tests if they now work at runtime (they link and the assembly of the foo
>
Hi!
Before my recent decide_alg change, *dynamic_check == -1 was indeed
guaranteed, because any_alg_usable_p doesn't depend on the arguments of
decide_alg that might change during recursive call, so we'd only recurse if
it wouldn't set *dynamic_check. But, if we give up because we'd otherwise
rec
On 2 March 2016 at 10:49, Christophe Lyon wrote:
> On 2 March 2016 at 10:16, James Greenhalgh wrote:
>> On Tue, Mar 01, 2016 at 05:56:30PM +0100, Christophe Lyon wrote:
>>> On 1 March 2016 at 10:51, James Greenhalgh wrote:
>>> > On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote:
>>>
On Thu, Mar 3, 2016 at 7:05 PM, Kumar, Venkataramanan
wrote:
> Hi Maintainers,
>
> The below patch corrects the type attribute for "sseimul" type reservations
> in znver1.md.
>
> (snip)
> diff --git a/gcc/config/i386/znver1.md b/gcc/config/i386/znver1.md
> index 3db3bed..feeccd7 100644
> --- a/g
On Thu, Mar 03, 2016 at 12:31:52PM +0100, Eric Botcazou wrote:
> > Anyway, looking at pro_and_epilogue dumps, with additional
> > -fstack-protector-strong we decrease sp only by 4176, while without it by
> > 8224 (on x86_64; the testcase fails on all targets I've tried so far
> > ({x86_64,i686,powe
On Thursday 03 March 2016 15:32:27 Thomas Preudhomme wrote:
> On Thursday 03 March 2016 09:44:31 Ramana Radhakrishnan wrote:
> > On Thu, Mar 3, 2016 at 9:40 AM, Thomas Preudhomme
> >
> > wrote:
> > > On Friday 15 January 2016 12:45:04 Ramana Radhakrishnan wrote:
> > >> On Wed, Dec 16, 2015 at 9:1
Hi Maintainers,
The below patch corrects the type attribute for "sseimul" type reservations in
znver1.md.
(snip)
diff --git a/gcc/config/i386/znver1.md b/gcc/config/i386/znver1.md
index 3db3bed..feeccd7 100644
--- a/gcc/config/i386/znver1.md
+++ b/gcc/config/i386/znver1.md
@@ -913,28 +913,28 @@
Hi Richard,
On 03/03/16 12:47, Richard Biener wrote:
On Thu, Mar 3, 2016 at 1:07 PM, Renlin Li wrote:
Hi Richard,
On 03/03/16 10:13, Richard Biener wrote:
On Wed, Mar 2, 2016 at 5:12 PM, Renlin Li wrote:
Hi Richard,
On 02/03/16 13:35, Richard Biener wrote:
On Tue, Mar 1, 2016 at 4:56 P
On 03/02/2016 10:53 PM, Vladimir Makarov wrote:
2. update_costs_from_allocno records a cost update not just for the
initial allocno, but for each of the visited ones. I can sort of see
an argument for doing that (let's say if you assign an allocno in the
middle of a copy chain you'd want the tail
On 03/03/2016 04:18 PM, Mike Stump wrote:
On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote:
I have revised the patch and removed the limits.
I looked at the patch, I can find no more unreasonable limits! Wonderful.
Hope someone will finish off the review and approve.
Marcel, if you haven't
On Thu, Mar 3, 2016 at 10:21 AM, David Malcolm wrote:
> Comment #1 of PR c/68187 identified another overzealous warning
> from -Wmisleading-indentation, with OpenSSL 1.0.1, on this poorly
> indented code:
>
> 115if (locked)
> 116i = CRYPTO_add(&e->struct_ref, -1, CRYPTO_LOCK_ENGINE);
>
On 03/03/2016 01:55 AM, Richard Biener wrote:
Thanks for doing this. I suppose this is also upstream now?
I'm re-syncing with upstream now. I did just find that upstream's soname is
already 6.4.0, so I may come back and bump both sonames to 7 instead of 5.
r~
On 03/03/2016 05:35 AM, Rainer Orth wrote:
Hi Richard,
Unfortunately, even with this fixed, all Solaris/x86 tests now fail to
link:
FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
Undefined first referenced
symbol
On Thu, Mar 3, 2016 at 10:56 AM, David Malcolm wrote:
> On Thu, 2016-03-03 at 10:24 -0500, Patrick Palka wrote:
>> On Thu, Mar 3, 2016 at 10:21 AM, David Malcolm
>> wrote:
>> > PR c/68187 covers two cases involving poor indentation where
>> > the indentation is arguably not misleading, but for wh
On Thu, Mar 03, 2016 at 09:24:36AM -0700, Jeff Law wrote:
> >2016-03-03 Marek Polacek
> >
> > PR c/69798
> > * c-parser.c (c_parser_postfix_expression): Call
> > c_parser_cast_expression instead of c_parser_postfix_expression.
> >
> > * gcc.dg/cilk-plus/pr69798-1.c: New test.
> >
On Thu, Mar 03, 2016 at 09:24:36AM -0700, Jeff Law wrote:
> I'd wait for gcc-7. There's actually further Cilk+ fixes queued up from
> Ryan. I wanted to get those into gcc-6, but just flat ran out of time.
> Perhaps ask for an exception to address the queued up Cilk+ stuff in a minor
> release?
On 03/03/2016 09:15 AM, Marek Polacek wrote:
On Thu, Mar 03, 2016 at 03:28:01PM +0100, Jakub Jelinek wrote:
On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
_Cilk_spawn (void) is invalid. The function
On Thu, Mar 03, 2016 at 03:28:01PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
> > This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so
> > e.g.
> > _Cilk_spawn (void) is invalid. The function call after the cilk_spawn
> > ke
On 3 March 2016 at 15:39, Patrick Palka wrote:
> On Thu, Mar 3, 2016 at 10:22 AM, Manuel López-Ibáñez
> wrote:
>> It would be an overall improvement if it was neither a TREE_LIST, nor a
>> TREE_VECTOR: https://gcc.gnu.org/wiki/Speedup_areas#Trees
>>
>> Those kinds of cleanups are always welcome e
Dear All,
What started out as a provisional kludge, when first working on OOP,
has come back to bite us after 7 years. A collision in derived type
has values has been reported on clf. In principle, as pointed out in
the clf thread, this could mean that existing code might be quietly
confusing dyna
On Thu, 2016-03-03 at 10:24 -0500, Patrick Palka wrote:
> On Thu, Mar 3, 2016 at 10:21 AM, David Malcolm
> wrote:
> > PR c/68187 covers two cases involving poor indentation where
> > the indentation is arguably not misleading, but for which
> > -Wmisleading-indentation emits a warning.
> >
> > Th
On 03/03/16 14:21, Bernd Schmidt wrote:
On 03/02/2016 06:22 PM, Mike Stump wrote:
So, check for overflow, or better use unsigned values that are large
enough to never overflow. With no possibility for overflow, you can
then retest the bug and see if there are any other failure modes and
fix th
On Thu, Mar 3, 2016 at 10:22 AM, Manuel López-Ibáñez
wrote:
> On 03/03/16 14:49, Patrick Palka wrote:
>>
>> I think the slowness of this function is mostly due to the pointer
>> chasing performed in the function store_bindings, where we iterate
>> over all the names in each non-global scope to fig
On Wed, 2016-02-24 at 18:35 +, Jonathan Wakely wrote:
> This adds a new function to libsupc++ which will free the memory still
> in use by the pool used for allocating exceptions when malloc fails.
>
> This is similar to glibc's __libc_freeres, which valgrind (and other
> tools?) use to tell g
On Thursday 03 March 2016 09:44:31 Ramana Radhakrishnan wrote:
> On Thu, Mar 3, 2016 at 9:40 AM, Thomas Preudhomme
>
> wrote:
> > On Friday 15 January 2016 12:45:04 Ramana Radhakrishnan wrote:
> >> On Wed, Dec 16, 2015 at 9:11 AM, Thomas Preud'homme
> >>
> >> wrote:
> >> > During reorg pass, th
On Thu, Mar 3, 2016 at 10:21 AM, David Malcolm wrote:
> PR c/68187 covers two cases involving poor indentation where
> the indentation is arguably not misleading, but for which
> -Wmisleading-indentation emits a warning.
>
> The two cases appear to be different in nature; one in comment #0
> and t
On 03/03/16 14:49, Patrick Palka wrote:
I think the slowness of this function is mostly due to the pointer
chasing performed in the function store_bindings, where we iterate
over all the names in each non-global scope to figure out whether to
preserve them. It would probably improve performance
On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote:
> I have revised the patch and removed the limits.
I looked at the patch, I can find no more unreasonable limits! Wonderful.
Hope someone will finish off the review and approve.
Hi Jakub,
On 03 Mar 13:08, Jakub Jelinek wrote:
> routine has changed and looks good to me). Can somebody test this please
> on real hw or emulator?
I'll run testing on the simulator.
--
Thanks, K
On Mar 3, 2016, at 6:21 AM, Bernd Schmidt wrote:
> What C standard can we assume for libiberty? I was looking at patching this
> and discovered that SIZE_MAX is defined only for C99, so I'm leaning towards
> retaining the ints and using INT_MAX.
As long as you don’t need a constant… you can al
PR c/68187 covers two cases involving poor indentation where
the indentation is arguably not misleading, but for which
-Wmisleading-indentation emits a warning.
The two cases appear to be different in nature; one in comment #0
and the other in comment #1. Richi marked the bug as a whole as
a P1 r
Comment #1 of PR c/68187 identified another overzealous warning
from -Wmisleading-indentation, with OpenSSL 1.0.1, on this poorly
indented code:
115if (locked)
116i = CRYPTO_add(&e->struct_ref, -1, CRYPTO_LOCK_ENGINE);
117else
118i = --e->struct_ref;
119engine_ref_debug
Thanks Mike. I have revised the patch and removed the limits.
While perhaps less security critical, without the limits on the loop count (r)
the test cases will still consume all your memory and effectively freeze GDB.
* Before any realloc, check for overflow.
* string_need now returns 1 if the
On Thu, Mar 3, 2016 at 9:22 AM, Markus Trippelsdorf
wrote:
> On 2016.03.03 at 09:16 -0500, Patrick Palka wrote:
>> push_to_top_level gets called fairly frequently in template-heavy code
>> that performs a lot of instantiations, and we currently "leak" a lot of
>> GC memory when compiling such code
Hi!
I'd like to ping fix for P1 PR69947:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html
Jakub
On 2 March 2016 at 21:47, H.J. Lu wrote:
> On Wed, Mar 2, 2016 at 12:18 PM, Manuel López-Ibáñez
> wrote:
>> Pre-approved by Jeff here:
>> https://gcc.gnu.org/ml/gcc-help/2016-03/msg6.html
>>
>> Committed as revision 233914.
>
> I checked in this missing patch.
Thanks H.J.!
On Thu, Mar 03, 2016 at 03:15:41PM +0100, Marek Polacek wrote:
> This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so
> e.g.
> _Cilk_spawn (void) is invalid. The function call after the cilk_spawn keyword
> is parsed using recursive call in c_parser_postfix_expression (case
On 2016.03.03 at 09:16 -0500, Patrick Palka wrote:
> push_to_top_level gets called fairly frequently in template-heavy code
> that performs a lot of instantiations, and we currently "leak" a lot of
> GC memory when compiling such code since [push|pop]_to_top_level() do
> not bother reusing or even
On 03/02/2016 06:22 PM, Mike Stump wrote:
So, check for overflow, or better use unsigned values that are large
enough to never overflow. With no possibility for overflow, you can
then retest the bug and see if there are any other failure modes and
fix those.
What C standard can we assume for
push_to_top_level gets called fairly frequently in template-heavy code
that performs a lot of instantiations, and we currently "leak" a lot of
GC memory when compiling such code since [push|pop]_to_top_level() do
not bother reusing or even freeing each saved_scope structure it
allocates.
This patc
This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so e.g.
_Cilk_spawn (void) is invalid. The function call after the cilk_spawn keyword
is parsed using recursive call in c_parser_postfix_expression (case
RID_CILK_SPAWN). Now, c_parser_postfix_expression sees '(' followed by
On 03/03/16 12:11, Bernd Schmidt wrote:
> On 03/03/2016 11:45 AM, Andre Vieira (lists) wrote:
>> On 29/02/16 10:47, Andre Vieira (lists) wrote:
>>> On 15/02/16 10:33, Andre Vieira (lists) wrote:
On 18/01/16 11:04, Andre Vieira (lists) wrote:
> Hi there,
>
> Can we have the "#pragma
On 03/03/16 07:23, Michael Collison wrote:
> I have attached a new patch which hopefully address Richard's concerns.
> I modified the predicate on operand 1 to to "arm_rhs_operand" to be
> consistent with the constraints. I retained the split into two patterns;
> one for arm and another for thumb2.
Hi Richard,
> Unfortunately, even with this fixed, all Solaris/x86 tests now fail to
> link:
>
> FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess
> errors)
> Excess errors:
> Undefined first referenced
> symbol in file
> f
On Wed, 2 Mar 2016, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes two issues:
> 1) reverts part of https://gcc.gnu.org/ml/gcc-patches/2011-06/msg02183.html
>changes, my understanding is that we don't emit or support what has been
>mentioned as rationale for that, now that we can stick m
On Thu, Mar 03, 2016 at 01:56:05PM +0100, Marc Glisse wrote:
> On Thu, 3 Mar 2016, Marek Polacek wrote:
>
> >We crashed on the attached testcase because we were trying to apply the
> >X % -Y -> X % Y transformation even on vectors. That doesn't go well with
> >the
> >check for !TYPE_UNSIGNED. S
On Thu, Mar 03, 2016 at 01:56:05PM +0100, Marc Glisse wrote:
> On Thu, 3 Mar 2016, Marek Polacek wrote:
>
> >We crashed on the attached testcase because we were trying to apply the
> >X % -Y -> X % Y transformation even on vectors. That doesn't go well with
> >the
> >check for !TYPE_UNSIGNED. S
On Thu, 3 Mar 2016, Marek Polacek wrote:
We crashed on the attached testcase because we were trying to apply the
X % -Y -> X % Y transformation even on vectors. That doesn't go well with the
check for !TYPE_UNSIGNED. So I think let's limit the pattern to only work on
integral types.
I certai
On Thu, Mar 3, 2016 at 1:07 PM, Renlin Li wrote:
> Hi Richard,
>
>
> On 03/03/16 10:13, Richard Biener wrote:
>>
>> On Wed, Mar 2, 2016 at 5:12 PM, Renlin Li wrote:
>>>
>>> Hi Richard,
>>>
>>>
>>> On 02/03/16 13:35, Richard Biener wrote:
On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li
w
The following patch adjusts strict_aliasing_warning to use
proper alias_set_subset_of instead of relying on alias_sets_conflict_p
as after the PR66110 fix aggregates with a char[] member do not
automatically behave like having alias-set zero. As a side-effect
the test will be somewhat stricter as
On 03/03/2016 11:45 AM, Andre Vieira (lists) wrote:
On 29/02/16 10:47, Andre Vieira (lists) wrote:
On 15/02/16 10:33, Andre Vieira (lists) wrote:
On 18/01/16 11:04, Andre Vieira (lists) wrote:
Hi there,
Can we have the "#pragma GCC pop_options" fix backported to GCC-5?
Patch found in https:/
Hi!
Unlike the older vec_set_hi 256-bit patterns, which are correctly
using the VEC_SELECT as the first operand of VEC_CONCAT and
match_operand as second, because that is what the instruction does,
picks up low part from operand 1 and puts the operand 2 as the high part
of the result, the 512-bit
Hi Richard,
On 03/03/16 10:13, Richard Biener wrote:
On Wed, Mar 2, 2016 at 5:12 PM, Renlin Li wrote:
Hi Richard,
On 02/03/16 13:35, Richard Biener wrote:
On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li wrote:
Hi Richard,
On 01/03/16 09:16, Richard Biener wrote:
On Mon, Feb 29, 2016 at 5:13
Hello Nathan,
On Wed, 9 Sep 2015, Nathan Sidwell wrote:
> I've applied this patch to port some cleanups, mainly formatting and loop
> idioms from the gomp4 branch.
This patch that you committed to trunk in September 2015 forcefully disables
generation of line number information, undoing a part of
Hi all,
This patch fixes the ICE that was introduced by my earlier patch to
aarch64_set_current_function:
FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
And it also fixes a bug that I was working on separately relating to popping
On Thu, Mar 03, 2016 at 12:04:31PM +0100, Marek Polacek wrote:
> We crashed on the attached testcase because we were trying to apply the
> X % -Y -> X % Y transformation even on vectors. That doesn't go well with the
> check for !TYPE_UNSIGNED. So I think let's limit the pattern to only work on
>
On 03/03/16 11:31, Kyrill Tkachov wrote:
On 03/03/16 11:28, Kyrill Tkachov wrote:
Hi Andre,
On 02/03/16 12:20, Andre Vieira (lists) wrote:
gcc/ChangeLog:
2016-03-02 Andre Vieira
* config/arm/arm-cores.def (cortex-r8): New.
* config/arm/arm-tables.opt (cortex-r8): New.
*
> Anyway, looking at pro_and_epilogue dumps, with additional
> -fstack-protector-strong we decrease sp only by 4176, while without it by
> 8224 (on x86_64; the testcase fails on all targets I've tried so far
> ({x86_64,i686,powerpc64{,le},s390{,x},aarch64,armv7hl}-linux).
Yeah, the threshold is ar
On 03/03/16 11:28, Kyrill Tkachov wrote:
Hi Andre,
On 02/03/16 12:20, Andre Vieira (lists) wrote:
gcc/ChangeLog:
2016-03-02 Andre Vieira
* config/arm/arm-cores.def (cortex-r8): New.
* config/arm/arm-tables.opt (cortex-r8): New.
* config/arm/arm-tune.md: Regenerate.
Hi Andre,
On 02/03/16 12:21, Andre Vieira (lists) wrote:
Hi,
Tests used to check for "r8" which will not work because cortex-r8
string is now included in the assembly. Fixed by checking for "[^\-]r8".
Is this Ok?
Cheers,
Andre
gcc/testsuite/ChangeLog:
2016-03-02 Andre Vieira
* gcc
Hi Andre,
On 02/03/16 12:20, Andre Vieira (lists) wrote:
gcc/ChangeLog:
2016-03-02 Andre Vieira
* config/arm/arm-cores.def (cortex-r8): New.
* config/arm/arm-tables.opt (cortex-r8): New.
* config/arm/arm-tune.md: Regenerate.
* gcc/doc/invoke.texi: Add cortex-r8 to li
On 03/03/16 11:14, Gerald Pfeifer wrote:
On Thu, 3 Mar 2016, Kyrill Tkachov wrote:
Ok to commit?
Richi already approved, so this is only for future cases:
Please do consider changes like this either as trivial (and go ahead, just
posting the patch) or pre-approved by me (and go ahead, just p
On Thu, 3 Mar 2016, Kyrill Tkachov wrote:
Ok to commit?
Richi already approved, so this is only for future cases:
Please do consider changes like this either as trivial (and go
ahead, just posting the patch) or pre-approved by me (and go
ahead, just posting the patch). As you prefer. ;-)
We crashed on the attached testcase because we were trying to apply the
X % -Y -> X % Y transformation even on vectors. That doesn't go well with the
check for !TYPE_UNSIGNED. So I think let's limit the pattern to only work on
integral types.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
On 29/02/16 10:47, Andre Vieira (lists) wrote:
> On 15/02/16 10:33, Andre Vieira (lists) wrote:
>> On 18/01/16 11:04, Andre Vieira (lists) wrote:
>>> Hi there,
>>>
>>> Can we have the "#pragma GCC pop_options" fix backported to GCC-5?
>>>
>>> Patch found in https://gcc.gnu.org/ml/gcc-patches/2015-1
Hi Richard,
> As discussed in the PR, let's take the opportunity while bumping the soname
> to add symbol versioning.
great idea: I'd already suggested this back in 2010 when doing the bulk
of the Solaris symbol versioning work
http://gcc.gnu.org/ml/gcc/2010-02/msg00339.html
http
On 25/02/16 18:00, Alan Lawrence wrote:
On 22/02/16 12:03, Jakub Jelinek wrote:
(f) A global command-line option, which we check alongside DECL_COMMON and
further tests (basically, we want only DECL_COMMON decls that either have
ARRAY_TYPE, or some other aggregate type with flexible array member
On Wed, Mar 2, 2016 at 7:39 PM, Bernd Schmidt wrote:
> On 02/24/2016 11:01 PM, Jeff Law wrote:
>>
>> As Vlad noted, the test is definitely a pathological case. I think
>> Bernd's patch is a very reasonable approach to address the current
>> problem. Namely that LRA can be making progress on a pa
On Wed, Mar 2, 2016 at 5:12 PM, Renlin Li wrote:
> Hi Richard,
>
>
> On 02/03/16 13:35, Richard Biener wrote:
>>
>> On Tue, Mar 1, 2016 at 4:56 PM, Renlin Li wrote:
>>>
>>> Hi Richard,
>>>
>>>
>>> On 01/03/16 09:16, Richard Biener wrote:
On Mon, Feb 29, 2016 at 5:13 PM, Renlin Li
On Thu, Mar 3, 2016 at 10:49 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> I noticed that changes.html for GCC 5 has an entry for GCC 5.3 saying
> (Pending) and linking to the fixed PRs.
> 5.3 has already been released, so this patch removes it from there, and
> instead adds a similar entry for the pend
Mike Stump writes:
> On Mar 1, 2016, at 6:20 AM, Rainer Orth wrote:
>> When switching from gdb 7.10 to the newly released gdb 7.11 on Solaris,
>> all simulate-thread tests started to timeout
>
> Ok. If a domain expert prefers a different strategy, I’m fine with
> anything better as well.
Given
On Thu, 3 Mar 2016, James Greenhalgh wrote:
>
> Hi,
>
> ARM and AArch64 will still vectorize bb-slp-34.c - we're not operating
> with a cost model so we vectorize to a 64-bit vector of two ints, and the
> permutes are just element swaps.
>
> So, don't mark this test xfail for arm/aarch64.
>
>
On Thu, Mar 3, 2016 at 3:09 AM, Richard Henderson wrote:
> Is there anything else we should say?
>
> I thought about recommending that distributions not install the libffi
> shared library from gcc and instead use upstream source. But that doesn't
> really help one way or the other, so I dropped
On Thu, Mar 3, 2016 at 3:13 AM, Richard Henderson wrote:
> [ Ho hum. Re-send due to spam rejection.
> Trying again with compressed patch. ]
>
>
> As discussed in the PR, let's take the opportunity while bumping the soname
> to add symbol versioning.
>
> Versioning is complicated by the fact th
1 - 100 of 109 matches
Mail list logo
