* 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
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
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
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
*
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)
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)
@@
...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
===
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
===
---
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
On Nov 2, 2013, at 3:30 AM, Richard Sandiford rdsandif...@googlemail.com
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...
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)
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)
||
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,
Mike Stump mikest...@comcast.net writes:
On Nov 2, 2013, at 3:30 AM, Richard Sandiford
rdsandif...@googlemail.com 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
Hello!
These two constraints go together with address_no_seg_operand and
vsib_address_operand operand predicates.
2013-11-02 Uros Bizjak ubiz...@gmail.com
* config/i386/constraints.md (Ts, Tv): New address constrains.
* config/i386/i386.md (*leamode, *mode_bndcheck): Use Ts
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
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.
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 new
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
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
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
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: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 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:
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: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
Kenneth Zadeck zad...@naturalbridge.com 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
Kenneth Zadeck zad...@naturalbridge.com 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.
On 11/02/2013 10:25 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
On Thu, Oct 31, 2013 at 9:45 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com 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
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
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'.
I
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 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.exp
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
The first part of this is a simple type mismatch
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 07:06 AM, Richard Sandiford wrote:
On 2013-11-01 21:46, Paolo Carlini wrote:
Hi,
Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely jwakely@gmail.com
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
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
On 11/02/2013 01:51 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 11:31 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 11/02/2013 10:47 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
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
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 functions
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:
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
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
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
46 matches
Mail list logo
