Re: [PATCH] i?86 unaligned/aligned load improvement for AVX512F
On Fri, Jan 3, 2014 at 9:59 AM, Jakub Jelinek wrote:
> This is an attempt to port my recent
> http://gcc.gnu.org/viewcvs?rev=204219&root=gcc&view=rev
> http://gcc.gnu.org/viewcvs?rev=205663&root=gcc&view=rev
> http://gcc.gnu.org/viewcvs?rev=206090&root=gcc&view=rev
> changes also to AVX512F. The motivation is to get:
>
> #include
>
> __m512i
> foo (void *x, void *y)
> {
> __m512i a = _mm512_loadu_si512 (x);
> __m512i b = _mm512_loadu_si512 (y);
> return _mm512_add_epi32 (a, b);
> }
>
> use one of the unaligned memories directly as operand to the vpaddd
> instruction. The first hunk is needed so that we don't regress on say:
>
> #include
>
> __m512i z;
>
> __m512i
> foo (void *x, void *y, int k)
> {
> __m512i a = _mm512_mask_loadu_epi32 (z, k, x);
> __m512i b = _mm512_mask_loadu_epi32 (z, k, y);
> return _mm512_add_epi32 (a, b);
> }
>
> __m512i
> bar (void *x, void *y, int k)
> {
> __m512i a = _mm512_maskz_loadu_epi32 (k, x);
> __m512i b = _mm512_maskz_loadu_epi32 (k, y);
> return _mm512_add_epi32 (a, b);
> }
>
> Does it matter which of vmovdqu32 vs. vmovdqu64 is used if no
> masking/zeroing is performed (i.e. vmovdqu32 (%rax), %zmm0 vs.
> vmovdqu64 (%rax), %zmm0) for performance reasons (i.e. isn't there some
> reinterpretation penalty)?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2014-01-03 Jakub Jelinek
>
> * config/i386/sse.md (avx512f_load_mask): Emit vmovup{s,d}
> or vmovdqu* for misaligned_operand.
> (_loadu,
> _loaddqu): Handle .
> * config/i386/i386.c (ix86_expand_special_args_builtin): Set
> aligned_mem for AVX512F masked aligned load and store builtins and for
> non-temporal moves.
>
> * gcc.target/i386/avx512f-vmovdqu32-1.c: Allow vmovdqu64 instead of
> vmovdqu32.
Taking into account Kirill's comment, the patch is OK, although I find
a bit strange in [1] that
void f2 (int *__restrict e, int *__restrict f) { int i; for (i = 0; i
< 1024; i++) e[i] = f[i]; }
results in
vmovdqu64 (%rsi,%rax), %zmm0
vmovdqu32 %zmm0, (%rdi,%rax)
Shouldn't these two move insns be the same?
[1] http://gcc.gnu.org/ml/gcc/2014-01/msg00015.html
Thanks,
Uros.
[PATCH] Fix PR c++/59635
* cp/lambda.c (maybe_add_lambda_conv_op): Handle marking conversion
function as unimplemented for generic lambdas with varargs.
* g++.dg/opt/pr59635.C: New testcase.
---
gcc/cp/lambda.c | 2 +-
gcc/testsuite/g++.dg/cpp1y/pr59635.C | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr59635.C
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 1855716..8bb820d 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -970,7 +970,7 @@ maybe_add_lambda_conv_op (tree type)
the conversion op is used. */
if (varargs_function_p (callop))
{
- DECL_DELETED_FN (fn) = 1;
+ DECL_DELETED_FN (STRIP_TEMPLATE (fn)) = 1;
return;
}
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr59635.C
b/gcc/testsuite/g++.dg/cpp1y/pr59635.C
new file mode 100644
index 000..07bd6c4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr59635.C
@@ -0,0 +1,9 @@
+// { dg-do compile }
+// { dg-options "-std=c++1y" }
+
+// PR c++/59635
+
+auto f = [] (auto, ...) { return 0; };
+
+int (*p) (int, ...) = f; // { dg-error "unimplemented" }
+
--
1.8.5.2
Re: [PATCH] i?86 unaligned/aligned load improvement for AVX512F
On Sat, Jan 04, 2014 at 09:46:32AM +0100, Uros Bizjak wrote:
> Taking into account Kirill's comment, the patch is OK, although I find
Thanks.
> a bit strange in [1] that
>
> void f2 (int *__restrict e, int *__restrict f) { int i; for (i = 0; i
> < 1024; i++) e[i] = f[i]; }
>
> results in
>
> vmovdqu64 (%rsi,%rax), %zmm0
> vmovdqu32 %zmm0, (%rdi,%rax)
>
> Shouldn't these two move insns be the same?
Right now *mov_internal doesn't care which of the vmovdqa{32,64}
(and vmovdqu{32,64}) it uses, we could do something like following.
We still have a problem that there is no vmovdq[ua]{8,16}, so we need to
pick one of {32,64} for it. Also, there is
case MODE_OI:
case MODE_TI:
return "vmovdqa64\t{%g1, %g0|%g0, %g1}";
a few lines above, if we wanted to make the output look "nicer", we could
also use vmovdqa64 there only for V{2,4}DImode and use vmovdqa32 for other
modes.
Note I haven't tested the patch at all, perhaps some testcases wouldn't
match their regexps anymore (but probably the
gcc.target/i386/avx512f-vmovdqu32-1.c change could go away).
--- gcc/config/i386/sse.md.jj 2014-01-04 09:48:48.0 +0100
+++ gcc/config/i386/sse.md 2014-01-04 10:03:30.256458372 +0100
@@ -743,9 +743,16 @@ (define_insn "*mov_internal"
case MODE_XI:
if (misaligned_operand (operands[0], mode)
|| misaligned_operand (operands[1], mode))
- return "vmovdqu64\t{%1, %0|%0, %1}";
- else
+ {
+ if (mode == V8DImode)
+ return "vmovdqu64\t{%1, %0|%0, %1}";
+ else
+ return "vmovdqu32\t{%1, %0|%0, %1}";
+ }
+ else if (mode == V8DImode)
return "vmovdqa64\t{%1, %0|%0, %1}";
+ else
+ return "vmovdqa32\t{%1, %0|%0, %1}";
default:
gcc_unreachable ();
>
> [1] http://gcc.gnu.org/ml/gcc/2014-01/msg00015.html
>
> Thanks,
> Uros.
Jakub
Re: [Patch] Regex bracket matcher cache optimization
Hi, On 01/04/2014 03:35 AM, Tim Shen wrote: The data structure _BracketMatcher (storing regex like [123a-z]) could be quite slow mainly because of regex_traits. So a result of cache for small range of inputs (char) sounds reasonable. It iterates all 256 inputs and calculate them at regex compile time. Good. Could we actually measure something in the performance testsuite? Thanks, Paolo.
Re: [PATCH] i?86 unaligned/aligned load improvement for AVX512F
Guys,
On 04 Jan 10:09, Jakub Jelinek wrote:
> Note I haven't tested the patch at all, perhaps some testcases wouldn't
> match their regexps anymore (but probably the
> gcc.target/i386/avx512f-vmovdqu32-1.c change could go away).
>
> --- gcc/config/i386/sse.md.jj 2014-01-04 09:48:48.0 +0100
> +++ gcc/config/i386/sse.md2014-01-04 10:03:30.256458372 +0100
> @@ -743,9 +743,16 @@ (define_insn "*mov_internal"
> case MODE_XI:
> if (misaligned_operand (operands[0], mode)
> || misaligned_operand (operands[1], mode))
> - return "vmovdqu64\t{%1, %0|%0, %1}";
> - else
> + {
> + if (mode == V8DImode)
> + return "vmovdqu64\t{%1, %0|%0, %1}";
> + else
> + return "vmovdqu32\t{%1, %0|%0, %1}";
> + }
> + else if (mode == V8DImode)
> return "vmovdqa64\t{%1, %0|%0, %1}";
> + else
> + return "vmovdqa32\t{%1, %0|%0, %1}";
>
> default:
> gcc_unreachable ();
I think this hunk will increase generated code beauty
and have no perf impact.
--
Thanks, K
Re: [Patch, Fortran, OOP] PR 59547: Problem with using tbp specification function in multiple class procedures
2014/1/3 Mikael Morin : > Le 22/12/2013 11:28, Janus Weil a écrit : >> Hi all, >> >> here is a patch for a rejects-valid problem with type-bound >> procedures, which is due to the fact that the PURE attribute is being >> propagated too late. (I'm not sure if this problem could show up also >> with other attributes, so for now I'm only treating PURE.) >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >> > OK. Thanks, Mikael. Committed as r206331. Cheers, Janus
Re: [WIP][RFC][patch] xlocale support for libstdc++
"Václav Zeman" wrote: >Initially, I have set out to implement better locale support in >libstdc++ for non-Glibc systems like FreeBSD, that support POSIX 2008 >locale facilities. Unfortunately, it has turned out that I need >localeconv_l(), which is only available as an extension, so I have >renamed my work to xlocale support. > >This is work in progress. The patch compiles for me but it is >untested. It will need some testing, I intend to test on FreeBSD 9.2. >It should work on MacOS X as well, theoretically. > >The implementation is based on the GNU locale implementation files. > >I would like to ask if something like this would be acceptable, once >it is done. In that case, I would like to ask for necessary license >assignment paperwork. The libstdc++ maintainers will need to advise on the implementation, but in general I think so. And in any case getting paperwork is a good idea. My connectivity is pretty hampered right now, but I hope one of the other GCC maintainers is going to provide you a link. Gerald
Re: [PATCH] Fix slpeel_update_phi_nodes_for_guard1 ICE (PR tree-optimization/59519)
Jakub Jelinek wrote:
>Hi!
>
>Since the r205959 SCEV changes for peeled chrec, apparently we can end
>up
>with multiple PHIs on the to be vectorized loop that have the same
>arguments
>(both on preheader and latch edges).
>slpeel_update_phi_nodes_for_guard1
>doesn't like that, it asserts that for the argument from the latch edge
>we set_current_def only once, when it is shared by more than one PHI,
>we would actually be trying to set it more than once.
>
>What we create is just multiple PHIs on the *new_exit_bb that look like
>_NN = PHI
>but as they necessarily have the same value, IMHO it shouldn't matter
>which one of those we record through set_current_def.
>
>I've tried to trace where we'd call get_current_def on the loop_arg
>besides the get_current_def call changed in the patch, but saw none
>even
>on
>struct S { int f0; } d;
>int a[8] = { 0 }, b, c, e, f;
>
>void
>foo (void)
>{
> for (; e < 1; e++)
>{
> for (b = 0; b < 7; b++)
> {
> c |= (a[b + 1] != 0);
> if (d.f0)
> break;
> }
> f += b;
>}
>}
>where the value is actually used after the loop, in all cases the
>generated
>IL looks sane.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
>2014-01-03 Jakub Jelinek
>
> PR tree-optimization/59519
> * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_guard1): Don't
> ICE if get_current_def (current_new_name) is already non-NULL, as long
> as it is a phi result of some other phi in *new_exit_bb that has
> the same argument.
>
> * gcc.dg/vect/pr59519-1.c: New test.
> * gcc.dg/vect/pr59519-2.c: New test.
>
>--- gcc/tree-vect-loop-manip.c.jj 2013-12-10 12:43:21.0 +0100
>+++ gcc/tree-vect-loop-manip.c 2014-01-02 16:29:21.983645769 +0100
>@@ -483,7 +483,18 @@ slpeel_update_phi_nodes_for_guard1 (edge
> if (!current_new_name)
> continue;
> }
>- gcc_assert (get_current_def (current_new_name) == NULL_TREE);
>+ tree new_name = get_current_def (current_new_name);
>+ /* Because of peeled_chrec optimization it is possible that we
>have
>+ set this earlier. Verify the PHI has the same value. */
>+ if (new_name)
>+ {
>+gimple phi = SSA_NAME_DEF_STMT (new_name);
>+gcc_assert (gimple_code (phi) == GIMPLE_PHI
>+&& gimple_bb (phi) == *new_exit_bb
>+&& (PHI_ARG_DEF_FROM_EDGE (phi, single_exit (loop))
>+== loop_arg));
>+continue;
>+ }
>
> set_current_def (current_new_name, PHI_RESULT (new_phi));
> }
>--- gcc/testsuite/gcc.dg/vect/pr59519-1.c.jj 2014-01-02
>16:39:07.743647669 +0100
>+++ gcc/testsuite/gcc.dg/vect/pr59519-1.c 2014-01-02 16:40:22.414276947
>+0100
>@@ -0,0 +1,19 @@
>+/* PR tree-optimization/59519 */
>+/* { dg-do compile } */
>+/* { dg-additional-options "-O3" } */
>+
>+int a, b, c, d;
>+
>+void
>+foo (void)
>+{
>+ for (; d; d++)
>+for (b = 0; b < 14; b++)
>+ {
>+ c |= 1;
>+ if (a)
>+break;
>+ }
>+}
>+
>+/* { dg-final { cleanup-tree-dump "vect" } } */
>--- gcc/testsuite/gcc.dg/vect/pr59519-2.c.jj 2014-01-02
>16:39:10.726629480 +0100
>+++ gcc/testsuite/gcc.dg/vect/pr59519-2.c 2014-01-02 16:40:26.213249520
>+0100
>@@ -0,0 +1,20 @@
>+/* PR tree-optimization/59519 */
>+/* { dg-do compile } */
>+/* { dg-additional-options "-O3" } */
>+
>+struct S { int f0; } d;
>+int a[8] = { 0 }, b, c, e;
>+
>+void
>+foo (void)
>+{
>+ for (; e < 1; e++)
>+for (b = 0; b < 7; b++)
>+ {
>+ c |= (a[b + 1] != 0);
>+ if (d.f0)
>+break;
>+ }
>+}
>+
>+/* { dg-final { cleanup-tree-dump "vect" } } */
>
> Jakub
Re: [PATCH] Add -march=bdw support
Ilya Tocar wrote: >>> Why not -march=broadwell instead? >Done. Mind updating the release notes with these changes? Let me know if you need any pointers or help. Gerald
Re: [PATCH] i?86 unaligned/aligned load improvement for AVX512F
On Sat, Jan 4, 2014 at 10:29 AM, Kirill Yukhin wrote:
> Guys,
> On 04 Jan 10:09, Jakub Jelinek wrote:
>> Note I haven't tested the patch at all, perhaps some testcases wouldn't
>> match their regexps anymore (but probably the
>> gcc.target/i386/avx512f-vmovdqu32-1.c change could go away).
>>
>> --- gcc/config/i386/sse.md.jj 2014-01-04 09:48:48.0 +0100
>> +++ gcc/config/i386/sse.md2014-01-04 10:03:30.256458372 +0100
>> @@ -743,9 +743,16 @@ (define_insn "*mov_internal"
>> case MODE_XI:
>> if (misaligned_operand (operands[0], mode)
>> || misaligned_operand (operands[1], mode))
>> - return "vmovdqu64\t{%1, %0|%0, %1}";
>> - else
>> + {
>> + if (mode == V8DImode)
>> + return "vmovdqu64\t{%1, %0|%0, %1}";
>> + else
>> + return "vmovdqu32\t{%1, %0|%0, %1}";
>> + }
>> + else if (mode == V8DImode)
>> return "vmovdqa64\t{%1, %0|%0, %1}";
>> + else
>> + return "vmovdqa32\t{%1, %0|%0, %1}";
>>
>> default:
>> gcc_unreachable ();
> I think this hunk will increase generated code beauty
> and have no perf impact.
Yes, let's have consistent move insn mnemonics in the source.
Uros.
Fix IBM long double spurious overflows
This patch fixes various cases of spurious overflow exceptions in the
IBM long double support code. The generic issue is that an initial
approximation is computed by using the relevant arithmetic operation
on the high parts of the operands - but this may overflow double in
some cases where the final result is large but still a long way (up to
around 2^53 ulp) from overflowing long double. For division overflow
could occur not just from the initial a / c division but also from the
subsequent multiplication of the result by c (in some cases where a is
DBL_MAX, say), when the final result of the division need not be large
at all.
__gcc_qadd already tried to handle such overflow cases, but detected
them by examining the result of the addition of high parts - which
leaves a spurious overflow exception raised even if it returns the
correct non-overflowing value. This patch instead checks the operands
and does appropriate scaling, in all of __gcc_qadd, __gcc_qmul and
__gcc_qdiv, to avoid spurious overflow exceptions arising as well as
avoiding the bad results arising from such overflows.
Tested with no regressions with cross to powerpc-linux-gnu (and also
ran the glibc libm tests, which provide a rather more thorough test of
floating-point arithmetic than the GCC testsuite; this patch fixes, at
least, bad results from cbrtl (LDBL_MAX) that arose from the second
division issue mentioned, as well as the specific cases shown in the
tests added to the GCC testsuite). OK to commit?
libgcc:
2014-01-04 Joseph Myers
* config/rs6000/ibm-ldouble.c (bool): New typedef.
(false, true): New macros.
(__gcc_qadd): Detect possible overflow before rather than after
possibly overflowing arithmetic and scale operands and results in
that case.
(__gcc_qmul, __gcc_qdiv): Detect possible overflow and scale
operands and results in that case.
gcc/testsuite:
2014-01-04 Joseph Myers
* gcc.target/powerpc/rs6000-ldouble-4.c,
gcc.target/powerpc/rs6000-ldouble-5.c,
gcc.target/powerpc/rs6000-ldouble-6.c,
gcc.target/powerpc/rs6000-ldouble-7.c: New tests.
Index: libgcc/config/rs6000/ibm-ldouble.c
===
--- libgcc/config/rs6000/ibm-ldouble.c (revision 206325)
+++ libgcc/config/rs6000/ibm-ldouble.c (working copy)
@@ -47,6 +47,10 @@ see the files COPYING3 and COPYING.RUNTIME respect
#if defined (__MACH__) || defined (__powerpc__) || defined (_AIX)
+typedef _Bool bool;
+#define false 0
+#define true 1
+
#define fabs(x) __builtin_fabs(x)
#define isless(x, y) __builtin_isless (x, y)
#define inf() __builtin_inf()
@@ -98,40 +102,47 @@ long double
__gcc_qadd (double a, double aa, double c, double cc)
{
longDblUnion x;
- double z, q, zz, xh;
+ double z, q, zz, xh, xhs;
+ bool scale = false;
- z = a + c;
+ if (nonfinite (a) || nonfinite (c))
+return a + c;
- if (nonfinite (z))
+ if (fabs (a) >= 0x1p1022 || fabs (c) >= 0x1p1022)
{
- if (fabs (z) != inf())
- return z;
- z = cc + aa + c + a;
- if (nonfinite (z))
- return z;
- x.dval[0] = z; /* Will always be DBL_MAX. */
- zz = aa + cc;
- if (fabs(a) > fabs(c))
- x.dval[1] = a - z + c + zz;
- else
- x.dval[1] = c - z + a + zz;
+ scale = true;
+ if (fabs (a) >= 0x1p914)
+ {
+ a *= 0.5;
+ aa *= 0.5;
+ }
+ if (fabs (c) >= 0x1p914)
+ {
+ c *= 0.5;
+ cc *= 0.5;
+ }
}
- else
-{
- q = a - z;
- zz = q + c + (a - (q + z)) + aa + cc;
- /* Keep -0 result. */
- if (zz == 0.0)
- return z;
+ z = a + c;
+ q = a - z;
+ zz = q + c + (a - (q + z)) + aa + cc;
- xh = z + zz;
- if (nonfinite (xh))
- return xh;
+ /* Keep -0 result. */
+ if (zz == 0.0)
+return (scale ? 2.0 * z : z);
- x.dval[0] = xh;
- x.dval[1] = z - xh + zz;
-}
+ xh = z + zz;
+ xhs = xh;
+ if (scale)
+xhs *= 2.0;
+ if (nonfinite (xhs))
+return xhs;
+
+ x.dval[0] = xhs;
+ x.dval[1] = z - xh + zz;
+ if (scale)
+x.dval[1] *= 2.0;
+
return x.ldval;
}
@@ -149,7 +160,24 @@ long double
__gcc_qmul (double a, double b, double c, double d)
{
longDblUnion z;
- double t, tau, u, v, w;
+ double t, tau, u, us, v, w;
+ bool scale = false;
+
+ if (nonfinite (a) || nonfinite (c))
+return a * c;
+
+ if (fabs (a) >= 0x1p512)
+{
+ scale = true;
+ a *= 0.5;
+ b *= 0.5;
+}
+ else if (fabs (c) >= 0x1p512)
+{
+ scale = true;
+ c *= 0.5;
+ d *= 0.5;
+}
t = a * c; /* Highest order double term. */
@@ -169,12 +197,17 @@ __gcc_qmul (double a, double b, double c, double d
w = b*c;
tau += v + w;/* Add in other second-order terms. */
u = t + tau;
+ us = u;
+ if (scale)
+us *= 2.0;
/* Construct long double result. */
- if (nonfinite (u))
-
Re: Fix IBM long double division inaccuracy (glibc bug 15396)
On Sat, 4 Jan 2014, Alan Modra wrote: > On Thu, Jan 02, 2014 at 09:46:56PM +, Joseph S. Myers wrote: > > (Note that there remain other bugs in the IBM long double code, some > > causing glibc test failures, at least (a) invalid results in rounding > > modes other than FE_TONEAREST, (b) spurious overflow and underflow > > exceptions, mainly but not entirely where discontiguous mantissa bits > > are involved.) > > Thing is, the algorithms in rs6000/ibm-ldouble.c require round to > nearest to generate correct results. Quoting from the PowerPC64 ABI: Which means that the functions need to set round-to-nearest internally (maybe only in __gcc_*_round versions used if -frounding-math - one possibility I suggested in bug 59666 discussing that issue). > * The software support is restricted to round-to-nearest mode. >Programs that use extended precision must ensure that this rounding >mode is in effect when extended-precision calculations are performed. This is not a valid statement for an ABI to make as it is contrary to the requirements of ISO C, as I note in bug 59666. When -frounding-math is used, arithmetic must work in all rounding modes (producing valid results, not necessarily correctly rounded for non-IEEE formats). > * Does not support the IEEE status flags for overflow, underflow, and >other conditions. These flag have no meaning in this format. The semantics of all except probably "inexact" are perfectly meaningful for this format. The glibc libm test results for IBM long double are unfortunately rather a mess (more so than for other floating-point formats) as various problems shown up by increased test coverage have languished unfixed for some time - I'm trying to fix some of the more obvious problems to get to a saner state of expected failures. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch, fortran] PR58007: unresolved fixup hell
Hi Mikael, > this patch fixes PR58007, where the compiler was not able to relate a > component pointer to any loaded derived type symbol. > The problem came from an optimization avoiding loading again a symbol > which had already been loaded, skipping by the way the association of > component pointers (if the symbol was a derived type) with the > corresponding module indexes. > > The attached patch fixes this by reading the derived type symbol dump's > component list and do the pointer<->integer association by hand. Then > the regular on demand module loading code works properly and some code > in mio_component_ref that was forcing the module loading of the > containing derived type can be removed. > To associate the component pointers with the module integers, one has to > parse the symbol, or at least its components. It is done by hand in > this patch and to reduce the maintainance burden (for possible future > evolutions of symbol dumping format/content) the component list is moved > at the beginning. More exactly just after the symbol attributes, > because the check_for_ambiguous function relies on the symbol attributes > appearing first in a symbol. > This changes the module format, so MOD_VERSION is bumped. > > Regression tested on x86_64-unknown-linux-gnu. OK for trunk? Basically your patch looks ok to me. However, I don't quite see the necessity for changing the module format (apart from the fact that it makes your patch slightly simpler). Anyway, since the module format has been changed already in 4.9, I think it doesn't matter much if we do it once more, so okay with me. One question, though: I don't understand how the problem is specific to OOP code (and why it did not come up before with F95-style code). Do you think it would be possible to find a non-OOP case where it fails? If not, could there be some problem in gfortran's OOP implementation which causes the failure? > I plan to submit a variant that doesn't change the module format for the > branches (doing more parsing by hand). Isn't that what you posted in comment 12 of the PR? Which branches did you have in mind? The PR contains various test cases which fail on either 4.7 or 4.8 and sometimes both, so potentially both of them are affected by the bug, I guess? Cheers, Janus
[PATCH] Fix PR c++/59636
* cp/parser.c (cp_parser_template_parameter): Early out with
error_mark_node if parameter declaration was not parsed.
* g++.dg/cpp1y/pr59636.C: New testcase.
---
gcc/cp/parser.c | 12 ++--
gcc/testsuite/g++.dg/cpp1y/pr59636.C | 7 +++
2 files changed, 13 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr59636.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 35dcefd..4f737df 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12981,20 +12981,21 @@ cp_parser_template_parameter (cp_parser* parser, bool
*is_non_type,
= cp_parser_parameter_declaration (parser, /*template_parm_p=*/true,
/*parenthesized_p=*/NULL);
+ if (!parameter_declarator)
+return error_mark_node;
+
/* If the parameter declaration is marked as a parameter pack, set
*IS_PARAMETER_PACK to notify the caller. Also, unmark the
declarator's PACK_EXPANSION_P, otherwise we'll get errors from
grokdeclarator. */
- if (parameter_declarator
- && parameter_declarator->declarator
+ if (parameter_declarator->declarator
&& parameter_declarator->declarator->parameter_pack_p)
{
*is_parameter_pack = true;
parameter_declarator->declarator->parameter_pack_p = false;
}
- if (parameter_declarator
- && parameter_declarator->default_argument)
+ if (parameter_declarator->default_argument)
{
/* Can happen in some cases of erroneous input (c++/34892). */
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -13018,8 +13019,7 @@ cp_parser_template_parameter (cp_parser* parser, bool
*is_non_type,
/* We might end up with a pack expansion as the type of the non-type
template parameter, in which case this is a non-type template
parameter pack. */
- else if (parameter_declarator
- && parameter_declarator->decl_specifiers.type
+ else if (parameter_declarator->decl_specifiers.type
&& PACK_EXPANSION_P (parameter_declarator->decl_specifiers.type))
{
*is_parameter_pack = true;
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr59636.C
b/gcc/testsuite/g++.dg/cpp1y/pr59636.C
new file mode 100644
index 000..f2ca5b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr59636.C
@@ -0,0 +1,7 @@
+// { dg-do compile }
+// { dg-options "-std=c++1y" }
+
+// PR c++/59636
+
+auto f = []() { return []<>() {}; }; // { dg-error "expected identifier" }
+
--
1.8.5.2
Re: [PATCH] Fix PR c++/59635
On 2014-01-03 21:45, Adam Butcher wrote:
* g++.dg/opt/pr59635.C: New testcase.
s/opt/cpp1y/
+int (*p) (int, ...) = f; // { dg-error "unimplemented" }
s/dg-error/dg-message/
Re: [Patch] Regex bracket matcher cache optimization
On Sat, Jan 4, 2014 at 4:25 AM, Paolo Carlini wrote: > Good. Could we actually measure something in the performance testsuite? Before: split.cc 108r 107u 0s0mem0pf split_bfs.cc 192r 191u 0s0mem0pf After: split.cc14r 14u 0s0mem0pf split_bfs.cc78r 77u 0s0mem0pf The cache obviously works. -- Regards, Tim Shen
Re: [Patch] Regex bracket matcher cache optimization
On Fri, Jan 3, 2014 at 9:35 PM, Tim Shen wrote: > The data structure _BracketMatcher (storing regex like [123a-z]) could > be quite slow mainly because of regex_traits. So a result of cache for > small range of inputs (char) sounds reasonable. It iterates all 256 > inputs and calculate them at regex compile time. In addition, boost failed the test case (testsuite/28_regex/traits/char/user_defined.cc), which can be seen here: https://gist.github.com/innocentim/8257944 -- Regards, Tim Shen
Re: wide-int, fortran
On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote: > On Nov 23, 2013, at 12:16 PM, Steve Kargl > wrote: >> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote: >>> Richi has asked the we break the wide-int patch so that the >>> individual port and front end maintainers can review their >>> parts without have to go through the entire patch.This >>> patch covers the fortran front end. >>> >>> Ok? >>> >>> + *logical = wi::eq_p (t, 0) ? 0 : 1; >> >> I can't find the meaning of :: in n1256.pdf. What does this do? >> >> Also, given the complete lack of a description of what this >> patch does and no pointer to a discussion of what this >> patch does, and no description of its benefit to gfortran, >> I vote "no". > > I don't like the notion that one person says yes, and one says no, > and then we ignore the no, and use the yes to approve a patch. Can > the fortran come up with a final unified answer? Thanks. My original comment had nothing to do with the technical merit of the patch. My comment, as shown above, objected to dropping a patch on (gfortran) developers with *no* explanation of the patch and *no* pointer to where a discussion may have occurred. -- Steve
