On 2013-11-02 23:31, Paolo Carlini wrote:
In general we are very careful with code bloat, but free functions which just
forward to other functions should be definiyely inline, otherwise typically at
widely used optimization levels like -O2 users get suboptimal performance for
no reason. But
Hi,
When I created the patch to split VSX loads and stores to add permutes
so the register image was correctly little endian, I forgot to implement
a known requirement. When a VSX store is split after reload, we must
reuse the source register for the permute, which leaves it in a swapped
state af
Hi!
Ping.
On Fri, 25 Oct 2013 09:23:24 +0200, I wrote:
> Ping. To sum it up, with these patches applied, there are no changes for
> a "regular" build (not using the new configure options). On the other
> hand, configuring GCC as described, it is possible use the 32-bit x86
> linker for/with a
Hello,
Today's powerpc64-linux gcc has 2 extra failures with -mlra vs. reload
(i.e. svn unpatched).
(I'm excluding guality failure differences here because there are too
many of them that seem to fail at random after minimal changes
anywhere in the compiler...).
Test results are posted here:
rel
Hi
>I see. It didn't occur to me to declare it inline, as I only ever use
>the keyword to satisfy
>ODR requirements. E.g. the non-member swap isn't declared inline
>either.
>
>For future reference, is there a rule of thumb in use?
In general we are very careful with code bloat, but free functio
On 2013-11-02 19:02, Paolo Carlini wrote:
Can you expand? I think it's just as much inline as the other overload
-- does it need to be different?
The other overload is constexpr thus it's implicitly inline. The fall back is
very simple too and I think it should be declared inline, unless you
On 11/02/2013 01:51 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this
>Can you expand? I think it's just as much inline as the other overload
>-- does it need to be different?
The other overload is constexpr thus it's implicitly inline. The fall back is
very simple too and I think it should be declared inline, unless you analyzed
the assembly and believe it norm
On 2013-11-01 21:46, Paolo Carlini wrote:
Hi,
Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely
ha scritto:
Here's the final version of Luc's optional implementation that I'm
committing, tested on x86_64-linux.
Great. Just noticed a minor nit: the fallback __constexpr_addressof appears
Kenneth Zadeck writes:
> On 11/02/2013 11:31 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
> On 11/02/2013 07:06 AM, Richard Sandiford wrote:
>> The first part of this is a simple type mismatch --
>
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int a
On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
> Jukub,
>
> This works!
> New patch attached.
Konstantin,
This patch, when applied on top of r204305, bootstraps fine on
x86_64-apple-darwin12 but
produces a lot of regressions with...
make -k check RUNTESTFLAGS="asan.ex
On Fri, Nov 01, 2013 at 04:56:36PM +0100, Paul Richard Thomas wrote:
>
> This one is trivial. The ICE was caused by an assert that turns out
> to be spurious and has been removed.
>
> Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
>
OK.
--
Steve
On Sat, Nov 02, 2013 at 08:25:28AM -0500, Aldy Hernandez wrote:
> Your patch mangling negative linear steps caused a regression in
> simd-clones-2.c. Well, it already had a failure, but now it has two
> :).
>
> The problem is that AFAIU, a linear step of 1, is mangled with just
> 'l', not 'l1'.
>
Kenneth Zadeck writes:
> On 11/02/2013 10:47 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have inst
On Thu, Oct 31, 2013 at 9:45 PM, Bill Schmidt
wrote:
> Hi,
>
> Brooks Moses reported a bug with code that sets a single element of a
> vector to a given value and the rest of the vector to zero. This is
> implemented in rs6000_expand_vector_set, which uses a vperm instruction
> to place the nonze
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have installed it as
obvious. The second part i
On 11/02/2013 10:25 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 11/02/2013 06:30 AM, Richard Sandiford wrote:
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-extended.
Nonzero/true BImode integers are stored as S
Kenneth Zadeck writes:
> On 11/02/2013 07:06 AM, Richard Sandiford wrote:
>> The first part of this is a simple type mismatch -- get_max_loop_iterations
>> returns a widest_int aka max_wide_int -- and I'd have installed it as
>> obvious. The second part isn't as obvious though. The old code stor
Kenneth Zadeck writes:
> On 11/02/2013 06:30 AM, Richard Sandiford wrote:
>> Bah. After all that effort, it turns out that -- by design --
>> there is one special case where CONST_INTs are not sign-extended.
>> Nonzero/true BImode integers are stored as STORE_FLAG_VALUE,
>> which can be 1 rather
On 11/02/2013 07:14 AM, Richard Sandiford wrote:
The wide-int conversion for the fold_ternary VEC_PERM_EXPR case
converted a mask of valid element numbers to an element count,
which is one greater. The old code set need_mask_canon if an index
was greater than the mask, but the new code sets it i
this is fine with me.
kenny
On 11/02/2013 07:52 AM, Richard Sandiford wrote:
r201806 added some extra checks to the handling of CONCAT when expanding
assignments. This was to fix an ICE on gcc.dg/pr48335-2.c for ppc.
I tripped over this because it also causes the assembly output for
the test
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have installed it as
obvious. The second part isn't as obvious though. The old code stored
the maximum iterations as:
On 11/02/2013 06:48 AM, Richard Sandiford wrote:
It turns out that when doing a vector shift by 2, the optab routine
passes (const_int 2) to convert_modes with oldmode set to the mode
of the shift (e.g. something like V8HI). When the target mode is a
real integer mode like SImode, mainline just
On 11/02/2013 06:30 AM, Richard Sandiford wrote:
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-extended.
Nonzero/true BImode integers are stored as STORE_FLAG_VALUE,
which can be 1 rather than -1. So (const_int 1) can be a
On 11/02/2013 06:19 AM, Richard Sandiford wrote:
...which I'd fluffed when doing the wi:: conversion.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. It fixed a spurious
gcc.dg difference on alpha-linux-gnu. Applied as obvious.
Thanks,
Richard
Index: gcc/wide-int.cc
I always like patches that change host dependencies into more general code.
ok from my perspective.
kenny
On 11/02/2013 06:13 AM, Richard Sandiford wrote:
I decided to lump these together since the problems were the same.
There were some typos in the real_to_integer invocation, while changing:
Hi Jakub.
Your patch mangling negative linear steps caused a regression in
simd-clones-2.c. Well, it already had a failure, but now it has two :).
The problem is that AFAIU, a linear step of 1, is mangled with just 'l',
not 'l1'.
I am not completely sure of this, and was hoping Balaji coul
On Fri, Nov 01, 2013 at 04:39:09PM -0400, Jason Merrill wrote:
> On 11/01/2013 03:10 PM, Marek Polacek wrote:
> >+ /* We need to stabilize side-effects in VLA sizes for regular array
> >+ declarations too, not just pointers to arrays. */
>
> This comment isn't really relevant to its
The second testcase currently ICEs I guess during simd cloning, just wanted
to make it clear that while simd clones without any arguments probably don't
make any sense (other than const, but those really should be hoisted out of
the loop much earlier), simd clones with no return value make sense.
r201806 added some extra checks to the handling of CONCAT when expanding
assignments. This was to fix an ICE on gcc.dg/pr48335-2.c for ppc.
I tripped over this because it also causes the assembly output for
the test to change. I tried backing out the patch and the ICE was
from the assert in wide
Hello!
These two constraints go together with address_no_seg_operand and
vsib_address_operand operand predicates.
2013-11-02 Uros Bizjak
* config/i386/constraints.md (Ts, Tv): New address constrains.
* config/i386/i386.md (*lea, *_): Use Ts
constraint for address_no_seg_operand.
Mike Stump writes:
> On Nov 2, 2013, at 3:30 AM, Richard Sandiford
> wrote:
>> Bah. After all that effort, it turns out that -- by design --
>> there is one special case where CONST_INTs are not sign-extended.
>
> I'm thinking this needs commentary in wide-int.h, though, not sure what
> we'd say
The wide-int conversion for the fold_ternary VEC_PERM_EXPR case
converted a mask of valid element numbers to an element count,
which is one greater. The old code set need_mask_canon if an index
was greater than the mask, but the new code sets it if an index
is greater than the element count, givin
The first part of this is a simple type mismatch -- get_max_loop_iterations
returns a widest_int aka max_wide_int -- and I'd have installed it as
obvious. The second part isn't as obvious though. The old code stored
the maximum iterations as:
if (!get_max_loop_iterations (loop, &iter)
||
It turns out that when doing a vector shift by 2, the optab routine
passes (const_int 2) to convert_modes with oldmode set to the mode
of the shift (e.g. something like V8HI). When the target mode is a
real integer mode like SImode, mainline just ignores that oldmode
and returns a (const_int 2) re
On Nov 2, 2013, at 3:30 AM, Richard Sandiford
wrote:
> Bah. After all that effort, it turns out that -- by design --
> there is one special case where CONST_INTs are not sign-extended.
I'm thinking this needs commentary in wide-int.h, though, not sure what we'd
say...
Bah. After all that effort, it turns out that -- by design --
there is one special case where CONST_INTs are not sign-extended.
Nonzero/true BImode integers are stored as STORE_FLAG_VALUE,
which can be 1 rather than -1. So (const_int 1) can be a valid
BImode integer -- and consequently (const_int
At some point the original "~"s got straightened to "-"s.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. This fixed
a testsuite difference in bfin-elf. Applied as obvious.
Thanks,
Richard
Index: gcc/optabs.c
===
--- gcc/opta
...which I'd fluffed when doing the wi:: conversion.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. It fixed a spurious
gcc.dg difference on alpha-linux-gnu. Applied as obvious.
Thanks,
Richard
Index: gcc/wide-int.cc
===
---
A test for "size > 8" had got inverted.
Tested on bfin-elf and applied as obvious.
Thanks,
Richard
Index: gcc/config/bfin/bfin.c
===
--- gcc/config/bfin/bfin.c (revision 204311)
+++ gcc/config/bfin/bfin.c (working copy)
@
I decided to lump these together since the problems were the same.
There were some typos in the real_to_integer invocation, while changing:
/* There must be no padding. */
if (!host_integerp (TYPE_SIZE (type), 1)
|| (tree_low_cst (TYPE_SIZE (type), 1)
!
gcc/
* tree.c (grow_tree_vec_stat): New function ...
* tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration
and macro front-end.
gcc/cp/
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser
gcc/testsuite/g++.dg/cpp1y/
* lambda-generic.C: New test case.
* lambda-generic-cfun.C: New test case.
* lambda-generic-dep.C: New test case.
* lambda-generic-udt.C: New test case.
* lambda-generic-variadic.C: New
* parser.c (convert_generic_types_to_packs): New function to transform
a range of implicitly introduced non-pack template parms to be parameter
packs.
(cp_parser_parameter_declaration_list): If a function parameter pack
contains generic types, convert them to
Hi Jason,
I've got the tsubst solution for implicit parameter packs working now. I've
also improved the efficiency of incremental template parameter synthesis and
added some testcases. All C++14 generic lambda examples pass and no new
regressions.
Cheers,
Adam
Patch summary (3):
Refactor im
46 matches
Mail list logo
