Re: [PATCH] Avoid UB in insn-emit.c (PR tree-optimization/79345)

[Richard Biener]

On Wed, 1 Mar 2017, Jakub Jelinek wrote:

> On Wed, Mar 01, 2017 at 03:03:29PM +0100, Richard Biener wrote:
> > The patch adds better limiting to that interface and fixes one
> > false positive in fixed-value.c.  Two other false positives are
> > fixed by the wide-int.h patch posted a few hours ago and a patch
> > to genemit from Jakub.
> 
> Here is that patch.  Right now insn-emit.c for match_scratch
> operands in expanders emits
>   rtx operand7 ATTRIBUTE_UNUSED;
> ...
>   rtx operands[8];
>   operands[0] = operand0;
> ...
>   // but no operands[7] = something here;
> ...
>   // C code from *.md file (which typically doesn't touch operands[7])
> ...
>   operand7 = operands[7];
>   (void) operand7;
> ...
>   // generated code that doesn't use operand7
> This triggers -Wuninitialized warning with Richard's patch and is really UB,
> even when we actually don't use it and so hopefully optimize away.
> The following patch just removes all operand7 and operands[7] references
> from the generated code (i.e. operands that are for match_scratch).
> 
> Usually match_scratch numbers come after match_operand/match_dup etc.
> numbers, but as can be seen, there are few spots where that is not the case.
> The patch adds verification of this requirement in genemit and then fixes
> the issues it has diagnosed.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested with
> make s-emit in a cross to
> {powerpc64,aarch64,armv7hl,sparc64,s390x,cris,sh,ia64,hppa,mips}-linux, ok
> for trunk?

This is ok.

Thanks for fixing this,
Richard.

> 2017-03-01  Jakub Jelinek  
> 
>   PR tree-optimization/79345
>   * gensupport.h (struct pattern_stats): Add min_scratch_opno field.
>   * gensupport.c (get_pattern_stats_1) : Update it.
>   (get_pattern_stats): Initialize it.
>   * genemit.c (gen_expand): Verify match_scratch numbers come after
>   match_operand/match_dup numbers.
>   * config/i386/i386.md (mul3_highpart): Swap match_dup and
>   match_scratch numbers.
>   * config/i386/sse.md (avx2_gathersi, avx2_gatherdi):
>   Likewise.
>   * config/s390/s390.md (trunctdsd2): Likewise.
> 
> --- gcc/gensupport.h.jj   2017-01-01 12:45:38.0 +0100
> +++ gcc/gensupport.h  2017-03-01 12:06:21.816440102 +0100
> @@ -199,7 +199,8 @@ struct pattern_stats
>/* The largest match_dup, match_op_dup or match_par_dup number found.  */
>int max_dup_opno;
>  
> -  /* The largest match_scratch number found.  */
> +  /* The smallest and largest match_scratch number found.  */
> +  int min_scratch_opno;
>int max_scratch_opno;
>  
>/* The number of times match_dup, match_op_dup or match_par_dup appears
> --- gcc/gensupport.c.jj   2017-01-05 22:10:31.0 +0100
> +++ gcc/gensupport.c  2017-03-01 12:21:24.830327207 +0100
> @@ -3000,6 +3000,10 @@ get_pattern_stats_1 (struct pattern_stat
>break;
>  
>  case MATCH_SCRATCH:
> +  if (stats->min_scratch_opno == -1)
> + stats->min_scratch_opno = XINT (x, 0);
> +  else
> + stats->min_scratch_opno = MIN (stats->min_scratch_opno, XINT (x, 0));
>stats->max_scratch_opno = MAX (stats->max_scratch_opno, XINT (x, 0));
>break;
>  
> @@ -3032,6 +3036,7 @@ get_pattern_stats (struct pattern_stats
>  
>stats->max_opno = -1;
>stats->max_dup_opno = -1;
> +  stats->min_scratch_opno = -1;
>stats->max_scratch_opno = -1;
>stats->num_dups = 0;
>  
> --- gcc/genemit.c.jj  2017-01-01 12:45:35.0 +0100
> +++ gcc/genemit.c 2017-03-01 12:16:28.391343302 +0100
> @@ -448,6 +448,10 @@ gen_expand (md_rtx_info *info)
>  
>/* Find out how many operands this function has.  */
>get_pattern_stats (&stats, XVEC (expand, 1));
> +  if (stats.min_scratch_opno != -1
> +  && stats.min_scratch_opno <= MAX (stats.max_opno, stats.max_dup_opno))
> +fatal_at (info->loc, "define_expand for %s needs to have match_scratch "
> +  "numbers above all other operands", XSTR (expand, 0));
>  
>/* Output the function name and argument declarations.  */
>printf ("rtx\ngen_%s (", XSTR (expand, 0));
> @@ -479,8 +483,6 @@ gen_expand (md_rtx_info *info)
>   make a local variable.  */
>for (i = stats.num_generator_args; i <= stats.max_dup_opno; i++)
>  printf ("  rtx operand%d;\n", i);
> -  for (; i <= stats.max_scratch_opno; i++)
> -printf ("  rtx operand%d ATTRIBUTE_UNUSED;\n", i);
>printf ("  rtx_insn *_val = 0;\n");
>printf ("  start_sequence ();\n");
>  
> @@ -516,7 +518,7 @@ gen_expand (md_rtx_info *info)
>(unless we aren't going to use them at all).  */
>if (XVEC (expand, 1) != 0)
>   {
> -   for (i = 0; i < stats.num_operand_vars; i++)
> +   for (i = 0; i <= MAX (stats.max_opno, stats.max_dup_opno); i++)
>   {
> printf ("operand%d = operands[%d];\n", i, i);
> printf ("(void) operand%d;\n", i);
> --- gcc/config/i386/i386.md.jj2017-02-22 18:15:48.0 +0100
> +++

Re: [PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699)

[Richard Biener]

On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers  wrote:
> On Wed, 1 Mar 2017, Martin Sebor wrote:
>
>> Joseph, since you commented on the bug, do you have a suggestion
>> for a different site for it or a guard?  The only other call to
>> the function is in the Fortran FE and it's neither guarded nor
>> does it appear to ever be called.
>
> I don't think a guard is needed.  Arguably it should be called from an
> atexit handler, but since we don't have such a handler calling it from the
> relevant pass seems reasonable (and I'm not sure what the right way to
> handle such freeing of memory in the JIT context is).

IMHO we should call it from gcc::~context

Richard.

> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Janne Blomqvist]

On Thu, Mar 2, 2017 at 9:50 AM, Thomas Koenig  wrote:
> Am 02.03.2017 um 08:32 schrieb Janne Blomqvist:
>>
>> On Wed, Mar 1, 2017 at 11:00 PM, Thomas Koenig 
>> wrote:
>>>
>>> Hello world,
>>>
>>> the attached patch enables FMA for the AVX2 and AVX512F variants of
>>> matmul.  This should bring a very nice speedup (although I have
>>> been unable to run benchmarks due to lack of a suitable machine).
>>
>>
>> In lieu of benchmarks, have you looked at the generated asm to verify
>> that fma is actually used?
>
>
> Yes, I did.
>
> Here's something from the new matmul_r8_avx2:
>
> 156c:   c4 62 e5 b8 fd  vfmadd231pd %ymm5,%ymm3,%ymm15
> 1571:   c4 c1 79 10 04 06   vmovupd (%r14,%rax,1),%xmm0
> 1577:   c4 62 dd b8 db  vfmadd231pd %ymm3,%ymm4,%ymm11
> 157c:   c4 c3 7d 18 44 06 10vinsertf128
> $0x1,0x10(%r14,%rax,1),%ymm0,%ymm0
> 1583:   01
> 1584:   c4 62 ed b8 ed  vfmadd231pd %ymm5,%ymm2,%ymm13
> 1589:   c4 e2 ed b8 fc  vfmadd231pd %ymm4,%ymm2,%ymm7
> 158e:   c4 e2 fd a8 ad 30 ffvfmadd213pd
> -0x800d0(%rbp),%ymm0,%ymm5

Great, looks good!

> ... and here from matmul_r8_avx512f:
>
> 1da8:   c4 a1 7b 10 14 d6   vmovsd (%rsi,%r10,8),%xmm2
> 1dae:   c4 c2 b1 b9 f0  vfmadd231sd %xmm8,%xmm9,%xmm6
> 1db3:   62 62 ed 08 b9 e5   vfmadd231sd %xmm5,%xmm2,%xmm28
> 1db9:   62 62 ed 08 b9 ec   vfmadd231sd %xmm4,%xmm2,%xmm29
> 1dbf:   62 62 ed 08 b9 f3   vfmadd231sd %xmm3,%xmm2,%xmm30
> 1dc5:   c4 e2 91 99 e8  vfmadd132sd %xmm0,%xmm13,%xmm5
> 1dca:   c4 e2 99 99 e0  vfmadd132sd %xmm0,%xmm12,%xmm4
> 1dcf:   c4 e2 a1 99 d8  vfmadd132sd %xmm0,%xmm11,%xmm3
> 1dd4:   c4 c2 a9 99 d1  vfmadd132sd %xmm9,%xmm10,%xmm2
> 1dd9:   c4 c2 89 99 c1  vfmadd132sd %xmm9,%xmm14,%xmm0
> 1dde:   0f 8e d3 fe ff ff   jle1cb7
> 

Good, it's using fma, but why is this using xmm registers? That would
mean it's operating only on 128 bit blocks at a time so no better than
plain AVX. AFAIU avx512 should use zmm registers to operate on 512 bit
chunks.

I guess this is not due to your patch, but some other issue.


-- 
Janne Blomqvist

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Richard Biener]

On Thu, Mar 2, 2017 at 9:09 AM, Janne Blomqvist
 wrote:
> On Thu, Mar 2, 2017 at 9:50 AM, Thomas Koenig  wrote:
>> Am 02.03.2017 um 08:32 schrieb Janne Blomqvist:
>>>
>>> On Wed, Mar 1, 2017 at 11:00 PM, Thomas Koenig 
>>> wrote:

 Hello world,

 the attached patch enables FMA for the AVX2 and AVX512F variants of
 matmul.  This should bring a very nice speedup (although I have
 been unable to run benchmarks due to lack of a suitable machine).
>>>
>>>
>>> In lieu of benchmarks, have you looked at the generated asm to verify
>>> that fma is actually used?
>>
>>
>> Yes, I did.
>>
>> Here's something from the new matmul_r8_avx2:
>>
>> 156c:   c4 62 e5 b8 fd  vfmadd231pd %ymm5,%ymm3,%ymm15
>> 1571:   c4 c1 79 10 04 06   vmovupd (%r14,%rax,1),%xmm0
>> 1577:   c4 62 dd b8 db  vfmadd231pd %ymm3,%ymm4,%ymm11
>> 157c:   c4 c3 7d 18 44 06 10vinsertf128
>> $0x1,0x10(%r14,%rax,1),%ymm0,%ymm0
>> 1583:   01
>> 1584:   c4 62 ed b8 ed  vfmadd231pd %ymm5,%ymm2,%ymm13
>> 1589:   c4 e2 ed b8 fc  vfmadd231pd %ymm4,%ymm2,%ymm7
>> 158e:   c4 e2 fd a8 ad 30 ffvfmadd213pd
>> -0x800d0(%rbp),%ymm0,%ymm5
>
> Great, looks good!
>
>> ... and here from matmul_r8_avx512f:
>>
>> 1da8:   c4 a1 7b 10 14 d6   vmovsd (%rsi,%r10,8),%xmm2
>> 1dae:   c4 c2 b1 b9 f0  vfmadd231sd %xmm8,%xmm9,%xmm6
>> 1db3:   62 62 ed 08 b9 e5   vfmadd231sd %xmm5,%xmm2,%xmm28
>> 1db9:   62 62 ed 08 b9 ec   vfmadd231sd %xmm4,%xmm2,%xmm29
>> 1dbf:   62 62 ed 08 b9 f3   vfmadd231sd %xmm3,%xmm2,%xmm30
>> 1dc5:   c4 e2 91 99 e8  vfmadd132sd %xmm0,%xmm13,%xmm5
>> 1dca:   c4 e2 99 99 e0  vfmadd132sd %xmm0,%xmm12,%xmm4
>> 1dcf:   c4 e2 a1 99 d8  vfmadd132sd %xmm0,%xmm11,%xmm3
>> 1dd4:   c4 c2 a9 99 d1  vfmadd132sd %xmm9,%xmm10,%xmm2
>> 1dd9:   c4 c2 89 99 c1  vfmadd132sd %xmm9,%xmm14,%xmm0
>> 1dde:   0f 8e d3 fe ff ff   jle1cb7
>> 
>
> Good, it's using fma, but why is this using xmm registers? That would
> mean it's operating only on 128 bit blocks at a time so no better than
> plain AVX. AFAIU avx512 should use zmm registers to operate on 512 bit
> chunks.
>
> I guess this is not due to your patch, but some other issue.

The question is, was it using %zmm before the patch?

>
> --
> Janne Blomqvist

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Thu, Mar 02, 2017 at 10:09:31AM +0200, Janne Blomqvist wrote:
> > Here's something from the new matmul_r8_avx2:
> >
> > 156c:   c4 62 e5 b8 fd  vfmadd231pd %ymm5,%ymm3,%ymm15
> > 1571:   c4 c1 79 10 04 06   vmovupd (%r14,%rax,1),%xmm0
> > 1577:   c4 62 dd b8 db  vfmadd231pd %ymm3,%ymm4,%ymm11
> > 157c:   c4 c3 7d 18 44 06 10vinsertf128
> > $0x1,0x10(%r14,%rax,1),%ymm0,%ymm0
> > 1583:   01
> > 1584:   c4 62 ed b8 ed  vfmadd231pd %ymm5,%ymm2,%ymm13
> > 1589:   c4 e2 ed b8 fc  vfmadd231pd %ymm4,%ymm2,%ymm7
> > 158e:   c4 e2 fd a8 ad 30 ffvfmadd213pd
> > -0x800d0(%rbp),%ymm0,%ymm5
> 
> Great, looks good!
> 
> > ... and here from matmul_r8_avx512f:
> >
> > 1da8:   c4 a1 7b 10 14 d6   vmovsd (%rsi,%r10,8),%xmm2
> > 1dae:   c4 c2 b1 b9 f0  vfmadd231sd %xmm8,%xmm9,%xmm6
> > 1db3:   62 62 ed 08 b9 e5   vfmadd231sd %xmm5,%xmm2,%xmm28
> > 1db9:   62 62 ed 08 b9 ec   vfmadd231sd %xmm4,%xmm2,%xmm29
> > 1dbf:   62 62 ed 08 b9 f3   vfmadd231sd %xmm3,%xmm2,%xmm30
> > 1dc5:   c4 e2 91 99 e8  vfmadd132sd %xmm0,%xmm13,%xmm5
> > 1dca:   c4 e2 99 99 e0  vfmadd132sd %xmm0,%xmm12,%xmm4
> > 1dcf:   c4 e2 a1 99 d8  vfmadd132sd %xmm0,%xmm11,%xmm3
> > 1dd4:   c4 c2 a9 99 d1  vfmadd132sd %xmm9,%xmm10,%xmm2
> > 1dd9:   c4 c2 89 99 c1  vfmadd132sd %xmm9,%xmm14,%xmm0
> > 1dde:   0f 8e d3 fe ff ff   jle1cb7
> > 
> 
> Good, it's using fma, but why is this using xmm registers? That would
> mean it's operating only on 128 bit blocks at a time so no better than
> plain AVX. AFAIU avx512 should use zmm registers to operate on 512 bit
> chunks.

Well, it uses sd, i.e. the scalar fma, not pd, so those are always xmm regs
and only a single double in them, this must be some scalar epilogue loop or
whatever; but matmul_r8_avx512f also has:
140c:   62 72 e5 40 98 c1   vfmadd132pd %zmm1,%zmm19,%zmm8
1412:   62 72 e5 40 98 cd   vfmadd132pd %zmm5,%zmm19,%zmm9
1418:   62 72 e5 40 98 d1   vfmadd132pd %zmm1,%zmm19,%zmm10
141e:   62 72 e5 40 98 de   vfmadd132pd %zmm6,%zmm19,%zmm11
1424:   62 72 e5 40 98 e1   vfmadd132pd %zmm1,%zmm19,%zmm12
142a:   62 e2 e5 40 98 c6   vfmadd132pd %zmm6,%zmm19,%zmm16
1430:   62 f2 e5 40 98 c8   vfmadd132pd %zmm0,%zmm19,%zmm1
1436:   62 f2 e5 40 98 f0   vfmadd132pd %zmm0,%zmm19,%zmm6
143c:   62 72 e5 40 98 fd   vfmadd132pd %zmm5,%zmm19,%zmm15
1442:   62 72 e5 40 98 f4   vfmadd132pd %zmm4,%zmm19,%zmm14
1448:   62 72 e5 40 98 eb   vfmadd132pd %zmm3,%zmm19,%zmm13
144e:   62 f2 e5 40 98 d0   vfmadd132pd %zmm0,%zmm19,%zmm2
1454:   62 b2 e5 40 98 ec   vfmadd132pd %zmm20,%zmm19,%zmm5
145a:   62 b2 e5 40 98 e4   vfmadd132pd %zmm20,%zmm19,%zmm4
1460:   62 b2 e5 40 98 dc   vfmadd132pd %zmm20,%zmm19,%zmm3
1466:   62 b2 e5 40 98 c4   vfmadd132pd %zmm20,%zmm19,%zmm0
etc. where 8 doubles in zmm regs are processed together.

Jakub

[PATCH] Fix rtl/x86_64 fails with -m32

[Richard Biener]

Annoying me for quite some time, fixed as follows.

Tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2017-03-02  Richard Biener  

* gcc.dg/rtl/x86_64/dfinit.c: Only run for lp64.
* gcc.dg/rtl/x86_64/final.c: Likewise.
* gcc.dg/rtl/x86_64/into-cfglayout.c: Likewise.
* gcc.dg/rtl/x86_64/ira.c: Likewise.
* gcc.dg/rtl/x86_64/times-two.c.after-expand.c: Likewise.
* gcc.dg/rtl/x86_64/vregs.c: Likewise.

Index: gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c(revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */
 /* { dg-options "-fdump-rtl-dfinit" } */
 
 #include "test_1.h"
Index: gcc/testsuite/gcc.dg/rtl/x86_64/final.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/final.c (revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/final.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target x86_64-*-* } } */
+/* { dg-do compile { target { x86_64-*-* && lp64 } } } */
 /* { dg-options "-fdump-rtl-final" } */
 
 /* Lightly-modified dump of test.c.304r.dwarf2 for x86_64 target,
Index: gcc/testsuite/gcc.dg/rtl/x86_64/into-cfglayout.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/into-cfglayout.c(revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/into-cfglayout.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */
 /* { dg-options "-fdump-rtl-into_cfglayout" } */
 
 /* Lightly-modified dump of test.c.226r.vregs for x86_64.  */
Index: gcc/testsuite/gcc.dg/rtl/x86_64/ira.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/ira.c   (revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/ira.c   (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */
 /* { dg-options "-fdump-rtl-ira" } */
 
 /* Lightly-modified dump of test.c.265r.asmcons for x86_64.  */
Index: gcc/testsuite/gcc.dg/rtl/x86_64/times-two.c.after-expand.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/times-two.c.after-expand.c  (revision 
245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/times-two.c.after-expand.c  (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */
 
 extern void abort (void);
 
Index: gcc/testsuite/gcc.dg/rtl/x86_64/vregs.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/vregs.c (revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/vregs.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */
 /* { dg-options "-fdump-rtl-vregs" } */
 
 /* Lightly-modified dump of test.c.225r.expand for x86_64.  */

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Wed, Mar 01, 2017 at 10:00:08PM +0100, Thomas Koenig wrote:
> @@ -101,7 +93,7 @@
>  `static void
>  'matmul_name` ('rtype` * const restrict retarray, 
>   'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
> - int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
> + int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
>  static' include(matmul_internal.m4)dnl
>  `#endif /* HAVE_AVX2 */
>  

I guess the question here is if there are any CPUs that have AVX2 but don't
have FMA3.  If there are none, then this is not controversial, if there are
some, it depends on how widely they are used compared to ones that have both
AVX2 and FMA3.  Going just from our -march= bitsets, it seems if there is
PTA_AVX2, then there is also PTA_FMA: haswell, broadwell, skylake, 
skylake-avx512, knl,
bdver4, znver1, there are CPUs that have just PTA_AVX and not PTA_AVX2 and
still have PTA_FMA: bdver2, bdver3 (but that is not relevant to this patch).

> @@ -110,7 +102,7 @@
>  `static void
>  'matmul_name` ('rtype` * const restrict retarray, 
>   'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
> - int blas_limit, blas_call gemm) __attribute__((__target__("avx512f")));
> + int blas_limit, blas_call gemm) 
> __attribute__((__target__("avx512f,fma")));
>  static' include(matmul_internal.m4)dnl
>  `#endif  /* HAVE_AVX512F */
>  

I think this change is not needed, because the EVEX encoded
VFMADD???[SP][DS] instructions etc. are in AVX512F ISA, not in FMA3 ISA
(which has just the VEX encoded ones).
Which is why I'm seeing the fmas in my libgfortran even without your patch.
Thus I think you should remove this from your patch.

> @@ -147,7 +141,8 @@
>  #endif  /* HAVE_AVX512F */
>  
>  #ifdef HAVE_AVX2
> -   if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
> +   if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
> +  && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
>   {
> matmul_p = matmul_'rtype_code`_avx2;
> goto tailcall;

and this too.

Jakub

Re: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Rainer Orth]

Hi Toma,

> As you suggested, I have added a check_gettimeofday_available proc in
> target-supports.exp and a dg-require-gettimeofday proc in 
> target-supports-dg.exp
> which check for gettimeofday using the existing check_function_available proc.

that's not what I suggested (or at least meant to suggest): having
gettimeofday as an effective-target keyword (like setrlimit, mmap, and
others) is the way to go, just your previous implementation of
check_effective_target_gettimeofday was problematic/unreliable.

If you go this route, there's no need to modify target-supports-dg.exp
at all.

Besides: I forget to mention that new effective-target keywords need to
be documented in sourcebuild.texi.

Sorry for the confusion.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix rtl/x86_64 fails with -m32

[Uros Bizjak]

> Annoying me for quite some time, fixed as follows.
>
> Tested on x86_64-unknown-linux-gnu, applied to trunk.

Index: gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c
===
--- gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (revision 245830)
+++ gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { x86_64-*-* && lp64 } } } */

All hese should be "{ target { { i?86-*-* x86_64-*-* } && { ! ia32 } }
}". x32 works OK with all test, modulo final.c where it ICEs for some
reason.

Uros.

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Thomas Koenig]

Am 02.03.2017 um 09:43 schrieb Jakub Jelinek:

On Wed, Mar 01, 2017 at 10:00:08PM +0100, Thomas Koenig wrote:

@@ -101,7 +93,7 @@
 `static void
 'matmul_name` ('rtype` * const restrict retarray,
'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
-   int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
+   int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
 static' include(matmul_internal.m4)dnl
 `#endif /* HAVE_AVX2 */



I guess the question here is if there are any CPUs that have AVX2 but don't
have FMA3.  If there are none, then this is not controversial, if there are
some, it depends on how widely they are used compared to ones that have both
AVX2 and FMA3.  Going just from our -march= bitsets, it seems if there is
PTA_AVX2, then there is also PTA_FMA: haswell, broadwell, skylake, 
skylake-avx512, knl,
bdver4, znver1, there are CPUs that have just PTA_AVX and not PTA_AVX2 and
still have PTA_FMA: bdver2, bdver3 (but that is not relevant to this patch).


In a previous incantation of the patch, I saw that the compiler
generated the same floating point code for AVX and AVX2 (which why
there currently is no AVX2 floating point version).  I could also
generate an AVX+FMA version for floating point and an AVX2 version
for integer (if anybody cares about integer matmul).

Or I could just leave it as it is.


@@ -110,7 +102,7 @@
 `static void
 'matmul_name` ('rtype` * const restrict retarray,
'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
-   int blas_limit, blas_call gemm) __attribute__((__target__("avx512f")));
+   int blas_limit, blas_call gemm) 
__attribute__((__target__("avx512f,fma")));
 static' include(matmul_internal.m4)dnl
 `#endif  /* HAVE_AVX512F */



I think this change is not needed, because the EVEX encoded
VFMADD???[SP][DS] instructions etc. are in AVX512F ISA, not in FMA3 ISA
(which has just the VEX encoded ones).
Which is why I'm seeing the fmas in my libgfortran even without your patch.
Thus I think you should remove this from your patch.


OK, I'll remove it.




@@ -147,7 +141,8 @@
 #endif  /* HAVE_AVX512F */

 #ifdef HAVE_AVX2
- if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+ if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+&& (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
{
  matmul_p = matmul_'rtype_code`_avx2;
  goto tailcall;


and this too.


Will do.

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Thu, Mar 02, 2017 at 10:03:28AM +0100, Thomas Koenig wrote:
> Am 02.03.2017 um 09:43 schrieb Jakub Jelinek:
> > On Wed, Mar 01, 2017 at 10:00:08PM +0100, Thomas Koenig wrote:
> > > @@ -101,7 +93,7 @@
> > >  `static void
> > >  'matmul_name` ('rtype` * const restrict retarray,
> > >   'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
> > > - int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
> > > + int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
> > >  static' include(matmul_internal.m4)dnl
> > >  `#endif /* HAVE_AVX2 */
> > > 
> > 
> > I guess the question here is if there are any CPUs that have AVX2 but don't
> > have FMA3.  If there are none, then this is not controversial, if there are
> > some, it depends on how widely they are used compared to ones that have both
> > AVX2 and FMA3.  Going just from our -march= bitsets, it seems if there is
> > PTA_AVX2, then there is also PTA_FMA: haswell, broadwell, skylake, 
> > skylake-avx512, knl,
> > bdver4, znver1, there are CPUs that have just PTA_AVX and not PTA_AVX2 and
> > still have PTA_FMA: bdver2, bdver3 (but that is not relevant to this patch).
> 
> In a previous incantation of the patch, I saw that the compiler
> generated the same floating point code for AVX and AVX2 (which why
> there currently is no AVX2 floating point version).  I could also
> generate an AVX+FMA version for floating point and an AVX2 version
> for integer (if anybody cares about integer matmul).

I think having another avx,fma version is not worth it, avx+fma is far less
common than avx without fma.

> > > @@ -147,7 +141,8 @@
> > >  #endif  /* HAVE_AVX512F */
> > > 
> > >  #ifdef HAVE_AVX2
> > > -   if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
> > > +   if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
> > > +  && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
> > >   {
> > > matmul_p = matmul_'rtype_code`_avx2;
> > > goto tailcall;
> > 
> > and this too.
> 
> Will do.

Note I meant obviously the FEATURE_AVX512F related hunk, not this one,
sorry.

Jakub

Re: [PATCH] Fix rtl/x86_64 fails with -m32

[Richard Biener]

On Thu, 2 Mar 2017, Uros Bizjak wrote:

> > Annoying me for quite some time, fixed as follows.
> >
> > Tested on x86_64-unknown-linux-gnu, applied to trunk.
> 
> Index: gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c
> ===
> --- gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (revision 245830)
> +++ gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (working copy)
> @@ -1,4 +1,4 @@
> -/* { dg-do run { target x86_64-*-* } } */
> +/* { dg-do run { target { x86_64-*-* && lp64 } } } */
> 
> All hese should be "{ target { { i?86-*-* x86_64-*-* } && { ! ia32 } }
> }". x32 works OK with all test, modulo final.c where it ICEs for some
> reason.

AFAIK they were testcases with RTL generated for x86_64 lp64 so
restricting to that is appropriate IMHO (do we really support
-m64 on i?86-*-*?)

But feel free to adjust them as you see fit - I was just annoyed
by the persisting FAILs.

Thanks,
Richard.

Re: [PATCH] Fix rtl/x86_64 fails with -m32

[Uros Bizjak]

On Thu, Mar 2, 2017 at 10:10 AM, Richard Biener  wrote:
> On Thu, 2 Mar 2017, Uros Bizjak wrote:
>
>> > Annoying me for quite some time, fixed as follows.
>> >
>> > Tested on x86_64-unknown-linux-gnu, applied to trunk.
>>
>> Index: gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c
>> ===
>> --- gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (revision 245830)
>> +++ gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (working copy)
>> @@ -1,4 +1,4 @@
>> -/* { dg-do run { target x86_64-*-* } } */
>> +/* { dg-do run { target { x86_64-*-* && lp64 } } } */
>>
>> All hese should be "{ target { { i?86-*-* x86_64-*-* } && { ! ia32 } }
>> }". x32 works OK with all test, modulo final.c where it ICEs for some
>> reason.
>
> AFAIK they were testcases with RTL generated for x86_64 lp64 so
> restricting to that is appropriate IMHO (do we really support
> -m64 on i?86-*-*?)

Yes, e.g. i386-pc-solaris2.11 [1].

> But feel free to adjust them as you see fit - I was just annoyed
> by the persisting FAILs.

OK, no problem for me.

[1] https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg02895.html

Uros.

[PATCH] Fix ICE with multiple conditional traps turned into unconditional in one bb (PR rtl-optimization/79780)

[Jakub Jelinek]

Hi!

As the testcase shows, if more than one conditional trap is turned into
non-conditional during one_cprop_pass in a single bb, we only split the
bb after the first one (because the rest is going to be removed as
unreachable), but before that happens, we trigger RTL verification that
complains that there is unconditional trap in the middle of a bb.

The following patch fixes it by turning the second and following trap
into NOTE_INSN_DELETED, so that the verification is happy about it and we
can safely remove the bb as unreachable afterwards.

Bootstrapped/regtested on powerpc64-linux (tested with 
--target_board=unix\{,-m32\})
with yes,rtl,extra checking, ok for trunk?

2017-03-02  Jakub Jelinek  

PR rtl-optimization/79780
* cprop.c (one_cprop_pass): When second and further conditional trap
in a single basic block is turned into an unconditional trap, turn it
into a deleted note to avoid RTL verification failures.

* gcc.c-torture/compile/pr79780.c: New test.

--- gcc/cprop.c.jj  2017-02-13 22:55:30.0 +0100
+++ gcc/cprop.c 2017-03-01 20:53:04.611430286 +0100
@@ -1852,12 +1852,22 @@ one_cprop_pass (void)
if (! NOTE_P (insn) && ! insn->deleted ())
  mark_oprs_set (insn);
 
-   if (!was_uncond_trap && !seen_uncond_trap
+   if (!was_uncond_trap
&& GET_CODE (PATTERN (insn)) == TRAP_IF
&& XEXP (PATTERN (insn), 0) == const1_rtx)
  {
-   seen_uncond_trap = true;
-   uncond_traps.safe_push (insn);
+   /* If we have already seen an unconditional trap
+  earlier, the rest of the bb is going to be removed
+  as unreachable.  Just turn it into a note, so that
+  RTL verification doesn't complain about it before
+  it is finally removed.  */
+   if (seen_uncond_trap)
+ set_insn_deleted (insn);
+   else
+ {
+   seen_uncond_trap = true;
+   uncond_traps.safe_push (insn);
+ }
  }
  }
}
--- gcc/testsuite/gcc.c-torture/compile/pr79780.c.jj2017-03-01 
21:00:56.231240727 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr79780.c   2017-03-01 
21:00:17.0 +0100
@@ -0,0 +1,48 @@
+/* PR rtl-optimization/79780 */
+
+int t3, iy, f4, oi, gn;
+
+void
+foo (long long int mh)
+{
+  int pi = 0;
+
+  if (iy != 0)
+for (;;)
+  f4 = 0;
+
+  if (t3 != 0)
+{
+  while (mh != 0LL)
+   {
+ while (mh < 1LL)
+   ++mh;
+ ++mh;
+   }
+  for (;;)
+   ;
+  for (oi = 0; oi < 1; ++oi)
+   {
+   n3:;
+   }
+  gn = iy = 1;
+}
+
+  f4 = 0;
+
+  if (pi - (mh != 0LL) == 0)
+if (mh != 1LL)
+  {
+   oi = t3 = 0;
+   if (mh == 0LL)
+ ++pi;
+  }
+
+  if (iy != 0 && pi != 0)
+{
+  t3 = 0;
+  goto n3;
+}
+
+  t3 /= 0;
+}

Jakub

[RFC PATCH libiberty] Fix infinite recursion in demangler

[Markus Trippelsdorf]

The following patch from Mark Wielaard fixes many (all?) open demangler
bugs that happen because we overflow the stack due to infinite
recursion.

I'm not sure why Mark didn't post the patch himself.
Anyway here it is.
Any comments?
Thanks.

diff --git a/include/demangle.h b/include/demangle.h
index 7cc955dc28d5..996203b2d786 100644
--- a/include/demangle.h
+++ b/include/demangle.h
@@ -494,6 +494,11 @@ struct demangle_component
   /* The type of this component.  */
   enum demangle_component_type type;
 
+  /* Guard against recursive component printing.
+ Initialize to zero.  Private to d_print_comp.
+ All other fields are final after initialization.  */
+  int d_printing;
+
   union
   {
 /* For DEMANGLE_COMPONENT_NAME.  */
@@ -688,7 +693,7 @@ cplus_demangle_v3_components (const char *mangled, int 
options, void **mem);
 
 extern char *
 cplus_demangle_print (int options,
-  const struct demangle_component *tree,
+  struct demangle_component *tree,
   int estimated_length,
   size_t *p_allocated_size);
 
@@ -708,7 +713,7 @@ cplus_demangle_print (int options,
 
 extern int
 cplus_demangle_print_callback (int options,
-   const struct demangle_component *tree,
+   struct demangle_component *tree,
demangle_callbackref callback, void *opaque);
 
 #ifdef __cplusplus
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index f0dbf9381c6b..341a4182c0b6 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -172,10 +172,10 @@ static struct demangle_component *d_mangled_name (struct 
d_info *, int);
 static struct demangle_component *d_type (struct d_info *);
 
 #define cplus_demangle_print d_print
-static char *d_print (int, const struct demangle_component *, int, size_t *);
+static char *d_print (int, struct demangle_component *, int, size_t *);
 
 #define cplus_demangle_print_callback d_print_callback
-static int d_print_callback (int, const struct demangle_component *,
+static int d_print_callback (int, struct demangle_component *,
  demangle_callbackref, void *);
 
 #define cplus_demangle_init_info d_init_info
@@ -264,7 +264,7 @@ struct d_print_mod
  in which they appeared in the mangled string.  */
   struct d_print_mod *next;
   /* The modifier.  */
-  const struct demangle_component *mod;
+  struct demangle_component *mod;
   /* Whether this modifier was printed.  */
   int printed;
   /* The list of templates which applies to this modifier.  */
@@ -530,7 +530,7 @@ static inline void d_append_string (struct d_print_info *, 
const char *);
 static inline char d_last_char (struct d_print_info *);
 
 static void
-d_print_comp (struct d_print_info *, int, const struct demangle_component *);
+d_print_comp (struct d_print_info *, int, struct demangle_component *);
 
 static void
 d_print_java_identifier (struct d_print_info *, const char *, int);
@@ -539,25 +539,25 @@ static void
 d_print_mod_list (struct d_print_info *, int, struct d_print_mod *, int);
 
 static void
-d_print_mod (struct d_print_info *, int, const struct demangle_component *);
+d_print_mod (struct d_print_info *, int, struct demangle_component *);
 
 static void
 d_print_function_type (struct d_print_info *, int,
-   const struct demangle_component *,
+   struct demangle_component *,
struct d_print_mod *);
 
 static void
 d_print_array_type (struct d_print_info *, int,
-const struct demangle_component *,
+struct demangle_component *,
 struct d_print_mod *);
 
 static void
-d_print_expr_op (struct d_print_info *, int, const struct demangle_component 
*);
+d_print_expr_op (struct d_print_info *, int, struct demangle_component *);
 
 static void d_print_cast (struct d_print_info *, int,
- const struct demangle_component *);
+ struct demangle_component *);
 static void d_print_conversion (struct d_print_info *, int,
-   const struct demangle_component *);
+   struct demangle_component *);
 
 static int d_demangle_callback (const char *, int,
 demangle_callbackref, void *);
@@ -923,6 +923,7 @@ d_make_empty (struct d_info *di)
   if (di->next_comp >= di->num_comps)
 return NULL;
   p = &di->comps[di->next_comp];
+  p->d_printing = 0;
   ++di->next_comp;
   return p;
 }
@@ -4249,7 +4250,7 @@ d_last_char (struct d_print_info *dpi)
 CP_STATIC_IF_GLIBCPP_V3
 int
 cplus_demangle_print_callback (int options,
-   const struct demangle_component *dc,
+   struct demangle_component *dc,
demangle_callbackref callback, void *opaque)
 {
   struct d_print_info dpi;
@@ -4292,7 +4293,7 @@

[PATCH][C] Fix PR79756

[Richard Biener]

Another case of missed TREE_ADDRESSABLE on vector indexing.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Ok for trunk?

2017-03-02  Richard Biener  

PR c/79756
* c-common.c (c_common_mark_addressable_vec): Look through
C_MAYBE_CONST_EXPR.

* gcc.dg/vector-1.c: New testcase.

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 245833)
+++ gcc/c-family/c-common.c (working copy)
@@ -6534,6 +6534,8 @@ complete_array_type (tree *ptype, tree i
 void 
 c_common_mark_addressable_vec (tree t)
 {   
+  if (TREE_CODE (t) == C_MAYBE_CONST_EXPR)
+t = C_MAYBE_CONST_EXPR_EXPR (t);
   while (handled_component_p (t))
 t = TREE_OPERAND (t, 0);
   if (!VAR_P (t)
Index: gcc/testsuite/gcc.dg/vector-1.c
===
--- gcc/testsuite/gcc.dg/vector-1.c (nonexistent)
+++ gcc/testsuite/gcc.dg/vector-1.c (working copy)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu90" } */
+
+typedef int V __attribute__ ((vector_size(4)));
+void fn1 ()
+{
+  (V){(1,0)}[0] = 0;
+}

Re: [RFC PATCH libiberty] Fix infinite recursion in demangler

[Mark Wielaard]

Hi,

On Thu, 2017-03-02 at 10:36 +0100, Markus Trippelsdorf wrote:
> The following patch from Mark Wielaard fixes many (all?) open demangler
> bugs that happen because we overflow the stack due to infinite
> recursion.
> 
> I'm not sure why Mark didn't post the patch himself.
> Anyway here it is.
> Any comments?

Thanks for poking at this issue. I didn't post it because I ran out of
time fully understanding why it works. I do believe this is the right
approach.  As far as I know the demangler can only be crashed by these
tricky endless recursion issues. All other crashers seem to have been
fixed already.

Below is some more explanation. More in the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
I would certainly not mind if someone ran with this patch and made sure
it is fully correct. But there is one "magic bit" in there, that I
cannot fully explain.

> @@ -5683,9 +5684,16 @@ d_print_comp_inner (struct d_print_info *dpi, int 
> options,
>  
>  static void
>  d_print_comp (struct d_print_info *dpi, int options,
> -   const struct demangle_component *dc)
> +   struct demangle_component *dc)
>  {
>struct d_component_stack self;
> +  if (dc == NULL || dc->d_printing > 1)
> +{
> +  d_print_error (dpi);
> +  return;
> +}
> +  else
> +dc->d_printing++;
>  
>self.dc = dc;
>self.parent = dpi->component_stack;

The question is why must that be > 1, not >= 1 or some other constant?

In my local patch I added this comment:

+  /* We need to allow one level of recursion for function types,
+ which are printed recursively with different options depending
+ on whether or not the return type needs to be printed. And when
+ printing a lambda argument then we need to allow another level
+ of recursion to print it.  */

And to track that I introduced the following field in struct
d_print_info:

+  /* Whether a component has been pushed to the modifiers list to
+ print the function return type in the right place.  Used for
+ tracking allowed component recursion depth.  */
+  int func_ret_modifier;

Which is then initialized in d_print_init and incremented/decremented in
d_print_comp_inner around the recursive calls to d_print_comp to print
the return type.

To track the printing of lambda arguments the condition is then changed
to:

+  if (dc == NULL
+  || dc->d_printing > dpi->func_ret_modifier + dpi->is_lambda_arg)

I also added various testcases.

diff --git a/libiberty/testsuite/demangle-expected 
b/libiberty/testsuite/demangle-expected
index b65dcd3..5fc1b9a 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -4666,3 +4666,44 @@ void eat(int*&, Foo()::{lambda(auto:1
 
 _Z3eatIPiZ3BarIsEvvEUlPsPT_PT0_E0_EvRS3_RS5_
 void eat()::{lambda(short*, auto:1*, auto:2*)#2}>(int*&, 
void Bar()::{lambda(short*, auto:1*, auto:2*)#2}&)
+#
+# Test recursion PR67264
+
+_Z1KIStcvT_E
+_Z1KIStcvT_E
+
+_ZcvT_IIS0_EE
+_ZcvT_IIS0_EE
+
+_ZcvT_IZcvT_E1fE
+_ZcvT_IZcvT_E1fE
+
+_Z1gINcvT_EE
+_Z1gINcvT_EE
+
+_ZcvT_ILZcvDTT_EEE
+_ZcvT_ILZcvDTT_EEE
+
+_Z1gIJOOT_EEOT_c
+_Z1gIJOOT_EEOT_c
+
+_Z1KMMMA_xooo
+_Z1KMMMA_xooo
+
+_ZdvMA_DTdvfp_fp_Eededilfdfdfdfd
+_ZdvMA_DTdvfp_fp_Eededilfdfdfdfd
+#
+# Test for Infinite Recursion PR70909
+
+_Z1MA_aA_MMA_St1MS_o11T00t2M0z
+_Z1MA_aA_MMA_St1MS_o11T00t2M0z
+
+#
+# Test for allowing recursion when is_lambda_arg PR68700
+_ZN8futurizeI13frozen_schemaE5applyIRZN7seastar7shardedIN7service13storage_proxyEE9invoke_onIZZNS6_22init_messaging_serviceEvENKUljN5utils4UUIDEE8_clEjSA_EUlOT_E_6futureIJS0_T0_jSD_EUlvE_JEEESG_SD_DpOT0_
+service::storage_proxy::init_messaging_service()::{lambda(unsigned int, 
utils::UUID)#10}::operator()(unsigned int, utils::UUID) 
const::{lambda(auto:1&&)#1} 
futurize::apply 
seastar::sharded::invoke_on >(unsigned int, 
service::storage_proxy::init_messaging_service()::{lambda(unsigned int, 
utils::UUID)#10}::operator()(unsigned int, utils::UUID) 
const::{lambda(auto:1&&)#1})::{lambda()#1}&>(future 
seastar::sharded::invoke_on >(unsigned int, 
service::storage_proxy::init_messaging_service()::{lambda(unsigned int, 
utils::UUID)#10}::operator()(unsigned int, utils::UUID) 
const::{lambda(auto:1&&)#1})::{lambda()#1}&)
+
+#
+# Test for allowing recursion when is_lambda_arg PR70517
+_ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_
+std::remove_reference::type> tconcurrent::future::then 
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto 
await 
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}&& 
const)::{lambda()#1}&>::type&& 
std::move::type> 
tconcurrent::future::then 
>(tconcurrent::future::type> 
tconcurrent::future::then 
>(tconcurrent::future&&)::{lambda(auto:1&& const&)#1}>(auto 
await 
>(tconcurrent::fu

Re: [PATCH][C] Fix PR79756

[Marek Polacek]

On Thu, Mar 02, 2017 at 10:52:08AM +0100, Richard Biener wrote:
> 
> Another case of missed TREE_ADDRESSABLE on vector indexing.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> Ok for trunk?

Ok (given what Joseph wrote in the PR and that c_fully_fold_internal
handles VIEW_CONVERT_EXPR).

Marek

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Toma Tabacu]

Hi,

> From: Rainer Orth
> 
> that's not what I suggested (or at least meant to suggest): having
> gettimeofday as an effective-target keyword (like setrlimit, mmap, and
> others) is the way to go, just your previous implementation of
> check_effective_target_gettimeofday was problematic/unreliable.
> 
> If you go this route, there's no need to modify target-supports-dg.exp
> at all.
> 

I see now. The dg-require-* directives are the predecessors to the
dg-require-effective-target directives.

I've changed it to be a dg-require-effective-target for gettimeofday instead.
Tested it and it works just as well as before.

> 
> Besides: I forget to mention that new effective-target keywords need to
> be documented in sourcebuild.texi.
> 

Done. Thanks for pointing this out.

There were 2 existing ways of describing this sort of effective-target; I chose
the more succinct one.

Regards,
Toma

gcc/
* doc/sourcebuild.texi (Effective-Target Keywords, Environment
attributes): Document gettimeofday.

gcc/testsuite/

* gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
gettimeofday. Remove dg-skip-if for AVR.
* lib/target-supports.exp (check_effective_target_gettimeofday): New.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 0dc4348..da17ff6 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1914,6 +1914,9 @@ Target is @samp{freestanding} as defined in section 4 of 
the C99 standard.
 Effectively, it is a target which supports no extra headers or libraries
 other than what is considered essential.
 
+@item gettimeofday
+Target supports @code{gettimeofday}.
+
 @item init_priority
 Target supports constructors with initialization priority arguments.
 
diff --git a/gcc/testsuite/gcc.dg/lto/pr60449_0.c 
b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
index 5b878a6..e6c3166 100644
--- a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
@@ -1,5 +1,5 @@
 /* { dg-lto-do link } */
-/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" } } */
+/* { dg-require-effective-target gettimeofday } */
 
 extern int printf (const char *__restrict __format, ...);
 typedef long int __time_t;
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 2766af4..d1639dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -968,6 +968,11 @@ proc check_effective_target_setrlimit {} {
 return [check_function_available "setrlimit"]
 }
 
+# Return 1 if the target supports gettimeofday, 0 otherwise.
+proc check_effective_target_gettimeofday {} {
+return [check_function_available "gettimeofday"]
+}
+
 # Return 1 if the target supports swapcontext, 0 otherwise.
 proc check_effective_target_swapcontext {} {
 return [check_no_compiler_messages swapcontext executable {

Re: [PATCH] Fix PR79345, better uninit warnings for memory

[Jakub Jelinek]

On Wed, Mar 01, 2017 at 03:03:29PM +0100, Richard Biener wrote:
> One issue with the patch is duplicate warnings as TREE_NO_WARNING
> doesn't work very well on tcc_reference trees which are not
> shared.  A followup could use some sort of hash table to mitigate

Can't we use TREE_NO_WARNING on get_base_address instead?  That is
shared...

> @@ -2925,14 +2927,22 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> if (!*visited)
>   *visited = BITMAP_ALLOC (NULL);
> for (i = 0; i < gimple_phi_num_args (def_stmt); ++i)
> - cnt += walk_aliased_vdefs_1 (ref, gimple_phi_arg_def (def_stmt, i),
> -  walker, data, visited, 0,
> -  function_entry_reached);
> + {
> +   int res = walk_aliased_vdefs_1 (ref,
> +   gimple_phi_arg_def (def_stmt, i),
> +   walker, data, visited, 0,
> +   function_entry_reached, limit);
> +   if (res == -1)
> + return -1;
> +   cnt += res;
> + }

This doesn't look right.  The recursive call starts with cnt of 0 again,
so if say you have limit 20 and cnt 10 when you are about to recurse and
that walk does 15 oracle comparisons, it won't return -1, but 15 and
you cnt += 15 to get 25 and never reach the limit, so then you walk perhaps
another 10 times.
Can't you just pass cnt instead of 0 and then use
  if (res == -1)
return -1;
  cnt = res;
?  Or you'd need to play gaves with decrementing the limit for the recursive
call.
> +   /* For limiting the alias walk below we count all
> +  vdefs in the function.  We then give the alias walk an
> +  overall budget (and simply not warn for further stmts).
> +  ???  The interface doesn't give us the chance to assign
> +  a maximum cost to each walk (and abort the walk if hit).  */

I don't understand the last two lines, I thought you've added the ability
to the interface above and you actually use it.

Otherwise it LGTM, yes, we will end up with new warnings, but unless the
alias oracle is wrong, there shouldn't be too many false positives, right?

Jakub

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Thomas Koenig]

Here's the updated version, which just uses FMA for AVX2.

OK for trunk?

Regards

Thomas

2017-03-01  Thomas Koenig  

PR fortran/78379
* m4/matmul.m4: (matmul_'rtype_code`_avx2): Also generate for
reals.  Add fma to target options.
(matmul_'rtype_code`):  Call AVX2 only if FMA is available.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.

Index: generated/matmul_c10.c
===
--- generated/matmul_c10.c	(Revision 245760)
+++ generated/matmul_c10.c	(Arbeitskopie)
@@ -74,9 +74,6 @@ extern void matmul_c10 (gfc_array_c10 * const rest
 	int blas_limit, blas_call gemm);
 export_proto(matmul_c10);
 
-
-
-
 /* Put exhaustive list of possible architectures here here, ORed together.  */
 
 #if defined(HAVE_AVX) || defined(HAVE_AVX2) || defined(HAVE_AVX512F)
@@ -628,7 +625,7 @@ matmul_c10_avx (gfc_array_c10 * const restrict ret
 static void
 matmul_c10_avx2 (gfc_array_c10 * const restrict retarray, 
 	gfc_array_c10 * const restrict a, gfc_array_c10 * const restrict b, int try_blas,
-	int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
+	int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
 static void
 matmul_c10_avx2 (gfc_array_c10 * const restrict retarray, 
 	gfc_array_c10 * const restrict a, gfc_array_c10 * const restrict b, int try_blas,
@@ -2277,7 +2274,8 @@ void matmul_c10 (gfc_array_c10 * const restrict re
 #endif  /* HAVE_AVX512F */
 
 #ifdef HAVE_AVX2
-  	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+  	  if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+	 && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
 	{
 	  matmul_p = matmul_c10_avx2;
 	  goto tailcall;
Index: generated/matmul_c16.c
===
--- generated/matmul_c16.c	(Revision 245760)
+++ generated/matmul_c16.c	(Arbeitskopie)
@@ -74,9 +74,6 @@ extern void matmul_c16 (gfc_array_c16 * const rest
 	int blas_limit, blas_call gemm);
 export_proto(matmul_c16);
 
-
-
-
 /* Put exhaustive list of possible architectures here here, ORed together.  */
 
 #if defined(HAVE_AVX) || defined(HAVE_AVX2) || defined(HAVE_AVX512F)
@@ -628,7 +625,7 @@ matmul_c16_avx (gfc_array_c16 * const restrict ret
 static void
 matmul_c16_avx2 (gfc_array_c16 * const restrict retarray, 
 	gfc_array_c16 * const restrict a, gfc_array_c16 * const restrict b, int try_blas,
-	int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
+	int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
 static void
 matmul_c16_avx2 (gfc_array_c16 * const restrict retarray, 
 	gfc_array_c16 * const restrict a, gfc_array_c16 * const restrict b, int try_blas,
@@ -2277,7 +2274,8 @@ void matmul_c16 (gfc_array_c16 * const restrict re
 #endif  /* HAVE_AVX512F */
 
 #ifdef HAVE_AVX2
-  	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+  	  if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+	 && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
 	{
 	  matmul_p = matmul_c16_avx2;
 	  goto tailcall;
Index: generated/matmul_c4.c
===
--- generated/matmul_c4.c	(Revision 245760)
+++ generated/matmul_c4.c	(Arbeitskopie)
@@ -74,9 +74,6 @@ extern void matmul_c4 (gfc_array_c4 * const restri
 	int blas_limit, blas_call gemm);
 export_proto(matmul_c4);
 
-
-
-
 /* Put exhaustive list of possible architectures here here, ORed together.  */
 
 #if defined(HAVE_AVX) || defined(HAVE_AVX2) || defined(HAVE_AVX512F)
@@ -628,7 +625,7 @@ matmul_c4_avx (gfc_array_c4 * const restrict retar
 static void
 matmul_c4_avx2 (gfc_array_c4 * const restrict retarray, 
 	gfc_array_c4 * const restrict a, gfc_array_c4 * const restrict b, int try_blas,
-	int blas_limit, blas_call gemm) __attribute__((__target__("avx2")));
+	int blas_limit, blas_call gemm) __attribute__((__target__("avx2,fma")));
 static void
 matmul_c4_avx2 (gfc_array_c4 * const restrict retarray, 
 	gfc_array_c4 * const restrict a, gfc_array_c4 * const restrict b, int try_blas,
@@ -2277,7 +2274,8 @@ void matmul_c4 (gfc_array_c4 * const restrict reta
 #endif  /* HAVE_AVX512F */
 
 #ifdef HAVE_AVX2
-  	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+  	  if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
+	 && (__cpu_mode

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Thu, Mar 02, 2017 at 11:45:59AM +0100, Thomas Koenig wrote:
> Here's the updated version, which just uses FMA for AVX2.
> 
> OK for trunk?
> 
> Regards
> 
>   Thomas
> 
> 2017-03-01  Thomas Koenig  
> 
> PR fortran/78379
> * m4/matmul.m4: (matmul_'rtype_code`_avx2): Also generate for
> reals.  Add fma to target options.
> (matmul_'rtype_code`):  Call AVX2 only if FMA is available.
> * generated/matmul_c10.c: Regenerated.
> * generated/matmul_c16.c: Regenerated.
> * generated/matmul_c4.c: Regenerated.
> * generated/matmul_c8.c: Regenerated.
> * generated/matmul_i1.c: Regenerated.
> * generated/matmul_i16.c: Regenerated.
> * generated/matmul_i2.c: Regenerated.
> * generated/matmul_i4.c: Regenerated.
> * generated/matmul_i8.c: Regenerated.
> * generated/matmul_r10.c: Regenerated.
> * generated/matmul_r16.c: Regenerated.
> * generated/matmul_r4.c: Regenerated.
> * generated/matmul_r8.c: Regenerated.

Ok, thanks.

Jakub

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Thu, Mar 02, 2017 at 11:45:59AM +0100, Thomas Koenig wrote:
> Here's the updated version, which just uses FMA for AVX2.
> 
> OK for trunk?
> 
> Regards
> 
>   Thomas
> 
> 2017-03-01  Thomas Koenig  
> 
> PR fortran/78379
> * m4/matmul.m4: (matmul_'rtype_code`_avx2): Also generate for
> reals.  Add fma to target options.
> (matmul_'rtype_code`):  Call AVX2 only if FMA is available.
> * generated/matmul_c10.c: Regenerated.
> * generated/matmul_c16.c: Regenerated.
> * generated/matmul_c4.c: Regenerated.
> * generated/matmul_c8.c: Regenerated.
> * generated/matmul_i1.c: Regenerated.
> * generated/matmul_i16.c: Regenerated.
> * generated/matmul_i2.c: Regenerated.
> * generated/matmul_i4.c: Regenerated.
> * generated/matmul_i8.c: Regenerated.
> * generated/matmul_r10.c: Regenerated.
> * generated/matmul_r16.c: Regenerated.
> * generated/matmul_r4.c: Regenerated.
> * generated/matmul_r8.c: Regenerated.

Actually, I see a problem, but not related to this patch.
I bet e.g. tsan would complain heavily on the wrappers, because the code
is racy:
  static void (*matmul_p) ('rtype` * const restrict retarray,
'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
int blas_limit, blas_call gemm) = NULL;

  if (matmul_p == NULL)
{
  matmul_p = matmul_'rtype_code`_vanilla;
  if (__cpu_model.__cpu_vendor == VENDOR_INTEL)
{
  /* Run down the available processors in order of preference.  */
#ifdef HAVE_AVX512F
  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX512F))
{
  matmul_p = matmul_'rtype_code`_avx512f;
  goto tailcall;
}

#endif  /* HAVE_AVX512F */
...
}

tailcall:
   (*matmul_p) (retarray, a, b, try_blas, blas_limit, gemm);

So, even when assuming all matmul_p = stores are atomic, e.g. if you call
matmul from 2 or more threads about the same time for the first time,
it could be that the first one sets matmul_p to vanilla and then another
thread runs it (uselessly slow), etc.

As you don't care about the if (matmul_p == NULL) part being done in
multiple threads concurrently, I guess you could e.g. do:
  static void (*matmul_p) ('rtype` * const restrict retarray,
'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
int blas_limit, blas_call gemm); //  <--- No need for NULL initializer 
for static var
  void (*matmul_fn) ('rtype` * const restrict retarray,
'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
int blas_limit, blas_call gemm);

  matmul_fn = __atomic_load_n (&matmul_p, __ATOMIC_RELAXED);
  if (matmul_fn == NULL)
{
  matmul_fn = matmul_'rtype_code`_vanilla;
  if (__cpu_model.__cpu_vendor == VENDOR_INTEL)
{
  /* Run down the available processors in order of preference.  */
#ifdef HAVE_AVX512F
  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX512F))
{
  matmul_fn = matmul_'rtype_code`_avx512f;
  goto finish;
}

#endif  /* HAVE_AVX512F */
...
  finish:
  __atomic_store_n (&matmul_p, matmul_fn, __ATOMIC_RELAXED);
}
  (*matmul_fn) (retarray, a, b, try_blas, blas_limit, gemm);

(i.e. make sure you read matmul_p in each call exactly once and store at
most once per thread).

Jakub

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

[JonY]

On 03/01/2017 11:36 AM, JonY wrote:
> Patch OK?
> 
> ChangeLog:
>   * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls.
> 

Applied, tested with x86_64-w64-mingw32 to trunk.




signature.asc
Description: OpenPGP digital signature

[PATCH] Fix libgfortran build for mingw*

[JonY]

Applied to trunk, tested with x86_64-w64-mingw32.

Changelog:

2017-03-02  Jonathan Yong <10wa...@gmail.com>

* config/i386/gthr-win32.h: Define NOGDI before
windows.h include to prevent w32api CC_NONE macro
clash with libgfortran.


--- trunk/libgcc/config/i386/gthr-win32.h   2017/03/02 11:00:28 245834
+++ trunk/libgcc/config/i386/gthr-win32.h   2017/03/02 11:03:23 245835
@@ -545,6 +545,7 @@
 
 #else /* ! __GTHREAD_HIDE_WIN32API */
 
+#define NOGDI
 #include 
 #include 
 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Fix PR79345, better uninit warnings for memory

[Richard Biener]

On Thu, 2 Mar 2017, Jakub Jelinek wrote:

> On Wed, Mar 01, 2017 at 03:03:29PM +0100, Richard Biener wrote:
> > One issue with the patch is duplicate warnings as TREE_NO_WARNING
> > doesn't work very well on tcc_reference trees which are not
> > shared.  A followup could use some sort of hash table to mitigate
> 
> Can't we use TREE_NO_WARNING on get_base_address instead?  That is
> shared...

At least for VAR_DECL based refs, yes (the only ones we currently
analyze).  For MEM_REF bases it won't work.  It would of 
course only warn once per aggregate and
for a maybe-uninit warning it might be the false positive
(the patch only sets TREE_NO_WARNING on the always-executed case).

For the user maybe we should change the order we walk BBs to RPO
and thus warn at the first maybe-uninit point so we can say
"further uninit warnings suppressed for X"?

> > @@ -2925,14 +2927,22 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> >   if (!*visited)
> > *visited = BITMAP_ALLOC (NULL);
> >   for (i = 0; i < gimple_phi_num_args (def_stmt); ++i)
> > -   cnt += walk_aliased_vdefs_1 (ref, gimple_phi_arg_def (def_stmt, i),
> > -walker, data, visited, 0,
> > -function_entry_reached);
> > +   {
> > + int res = walk_aliased_vdefs_1 (ref,
> > + gimple_phi_arg_def (def_stmt, i),
> > + walker, data, visited, 0,
> > + function_entry_reached, limit);
> > + if (res == -1)
> > +   return -1;
> > + cnt += res;
> > +   }
> 
> This doesn't look right.  The recursive call starts with cnt of 0 again,
> so if say you have limit 20 and cnt 10 when you are about to recurse and
> that walk does 15 oracle comparisons, it won't return -1, but 15 and
> you cnt += 15 to get 25 and never reach the limit, so then you walk perhaps
> another 10 times.
> Can't you just pass cnt instead of 0 and then use
> if (res == -1)
>   return -1;
> cnt = res;
> ?  Or you'd need to play gaves with decrementing the limit for the recursive
> call.

Ah, indeed.  Will fix (passing cnt).

> > + /* For limiting the alias walk below we count all
> > +vdefs in the function.  We then give the alias walk an
> > +overall budget (and simply not warn for further stmts).
> > +???  The interface doesn't give us the chance to assign
> > +a maximum cost to each walk (and abort the walk if hit).  */
> 
> I don't understand the last two lines, I thought you've added the ability
> to the interface above and you actually use it.

Will adjust the comment.

> Otherwise it LGTM, yes, we will end up with new warnings, but unless the
> alias oracle is wrong, there shouldn't be too many false positives, right?

Yes, we are not warning for the case where there is at least one path
with an initialization, like

void foo(int b)
{
  S s;
  if (b)
s.a = 1;
  return s.a;
}

will not warn (trivial to add but not necessary for the regression fix).

We also do not warn for pointer-based accesses (so unfortunately no
fix for PR2972).  Also trivial to add, but see PR79814 for more
bootstrap fallout.

Thanks,
Richard.

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Thomas Koenig]

Hi Jakub,


Actually, I see a problem, but not related to this patch.
I bet e.g. tsan would complain heavily on the wrappers, because the code
is racy:


Here is a patch implementing your suggestion.  Tested at least so
far that all matmul test cases pass on my machine.

OK for trunk?

Regards

Thomas

2017-03-02  Thomas Koenig  
Jakub Jelinek  

* m4/matmul.m4 (matmul_'rtype_code`_avx2):  Avoid
race condition on storing function pointer.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.

Index: generated/matmul_c10.c
===
--- generated/matmul_c10.c	(Revision 245836)
+++ generated/matmul_c10.c	(Arbeitskopie)
@@ -2258,9 +2258,14 @@ void matmul_c10 (gfc_array_c10 * const restrict re
 	gfc_array_c10 * const restrict a, gfc_array_c10 * const restrict b, int try_blas,
 	int blas_limit, blas_call gemm) = NULL;
 
+  void (*matmul_fn) (gfc_array_c10 * const restrict retarray, 
+	gfc_array_c10 * const restrict a, gfc_array_c10 * const restrict b, int try_blas,
+	int blas_limit, blas_call gemm) = NULL;
+
+  matmul_fn = __atomic_load_n (&matmul_p, __ATOMIC_RELAXED);
   if (matmul_p == NULL)
 {
-  matmul_p = matmul_c10_vanilla;
+  matmul_fn = matmul_c10_vanilla;
   if (__cpu_model.__cpu_vendor == VENDOR_INTEL)
 	{
   /* Run down the available processors in order of preference.  */
@@ -2267,8 +2272,8 @@ void matmul_c10 (gfc_array_c10 * const restrict re
 #ifdef HAVE_AVX512F
   	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX512F))
 	{
-	  matmul_p = matmul_c10_avx512f;
-	  goto tailcall;
+	  matmul_fn = matmul_c10_avx512f;
+	  goto store;
 	}
 
 #endif  /* HAVE_AVX512F */
@@ -2277,8 +2282,8 @@ void matmul_c10 (gfc_array_c10 * const restrict re
   	  if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
 	 && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
 	{
-	  matmul_p = matmul_c10_avx2;
-	  goto tailcall;
+	  matmul_fn = matmul_c10_avx2;
+	  goto store;
 	}
 
 #endif
@@ -2286,14 +2291,15 @@ void matmul_c10 (gfc_array_c10 * const restrict re
 #ifdef HAVE_AVX
   	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX))
  	{
-  matmul_p = matmul_c10_avx;
-	  goto tailcall;
+  matmul_fn = matmul_c10_avx;
+	  goto store;
 	}
 #endif  /* HAVE_AVX */
 }
+   store:
+  __atomic_store_n (&matmul_p, matmul_fn, __ATOMIC_RELAXED);
}
 
-tailcall:
(*matmul_p) (retarray, a, b, try_blas, blas_limit, gemm);
 }
 
Index: generated/matmul_c16.c
===
--- generated/matmul_c16.c	(Revision 245836)
+++ generated/matmul_c16.c	(Arbeitskopie)
@@ -2258,9 +2258,14 @@ void matmul_c16 (gfc_array_c16 * const restrict re
 	gfc_array_c16 * const restrict a, gfc_array_c16 * const restrict b, int try_blas,
 	int blas_limit, blas_call gemm) = NULL;
 
+  void (*matmul_fn) (gfc_array_c16 * const restrict retarray, 
+	gfc_array_c16 * const restrict a, gfc_array_c16 * const restrict b, int try_blas,
+	int blas_limit, blas_call gemm) = NULL;
+
+  matmul_fn = __atomic_load_n (&matmul_p, __ATOMIC_RELAXED);
   if (matmul_p == NULL)
 {
-  matmul_p = matmul_c16_vanilla;
+  matmul_fn = matmul_c16_vanilla;
   if (__cpu_model.__cpu_vendor == VENDOR_INTEL)
 	{
   /* Run down the available processors in order of preference.  */
@@ -2267,8 +2272,8 @@ void matmul_c16 (gfc_array_c16 * const restrict re
 #ifdef HAVE_AVX512F
   	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX512F))
 	{
-	  matmul_p = matmul_c16_avx512f;
-	  goto tailcall;
+	  matmul_fn = matmul_c16_avx512f;
+	  goto store;
 	}
 
 #endif  /* HAVE_AVX512F */
@@ -2277,8 +2282,8 @@ void matmul_c16 (gfc_array_c16 * const restrict re
   	  if ((__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX2))
 	 && (__cpu_model.__cpu_features[0] & (1 << FEATURE_FMA)))
 	{
-	  matmul_p = matmul_c16_avx2;
-	  goto tailcall;
+	  matmul_fn = matmul_c16_avx2;
+	  goto store;
 	}
 
 #endif
@@ -2286,14 +2291,15 @@ void matmul_c16 (gfc_array_c16 * const restrict re
 #ifdef HAVE_AVX
   	  if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX))
  	{
-  matmul_p = matmul_c16_avx;
-	  goto tailcall;
+  matmul_fn = matmul_c16_avx;
+	  goto st

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Jakub Jelinek]

On Thu, Mar 02, 2017 at 12:57:05PM +0100, Thomas Koenig wrote:
> --- m4/matmul.m4  (Revision 245836)
> +++ m4/matmul.m4  (Arbeitskopie)
> @@ -123,9 +123,14 @@ void matmul_'rtype_code` ('rtype` * const restrict
>   'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
>   int blas_limit, blas_call gemm) = NULL;

Please drop the " = NULL" here

> +  void (*matmul_fn) ('rtype` * const restrict retarray, 
> + 'rtype` * const restrict a, 'rtype` * const restrict b, int try_blas,
> + int blas_limit, blas_call gemm) = NULL;

and here as well.  The first one because static vars are zero initialized
by default, the latter because it makes no sense to initialize it and then
immediately overwrite it in the next stmt.

> +
> +  matmul_fn = __atomic_load_n (&matmul_p, __ATOMIC_RELAXED);
>if (matmul_p == NULL)

This needs to test matmul_fn == NULL instead of matmul_p == NULL.

> @@ -151,14 +156,15 @@ void matmul_'rtype_code` ('rtype` * const restrict
>  #ifdef HAVE_AVX
> if (__cpu_model.__cpu_features[0] & (1 << FEATURE_AVX))
>   {
> -  matmul_p = matmul_'rtype_code`_avx;
> -   goto tailcall;
> +  matmul_fn = matmul_'rtype_code`_avx;
> +   goto store;
>   }
>  #endif  /* HAVE_AVX */
>  }
> +   store:
> +  __atomic_store_n (&matmul_p, matmul_fn, __ATOMIC_RELAXED);
> }
>  
> -tailcall:
> (*matmul_p) (retarray, a, b, try_blas, blas_limit, gemm);

And this needs to use *matmul_fn instead of *matmul_p too.
The whole point is that matmul_p is only loaded using __atomic_load_n
and only optionally stored using __atomic_store_n.

Ok with those changes.

Jakub

Re: [PATCH] Avoid peeling for gaps if accesses are aligned

[Richard Biener]

On Wed, 1 Mar 2017, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
> >
> >> Richard Biener  writes:
> >> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
> >> >
> >> >> Richard Biener  writes:
> >> >> > On Wed, 1 Mar 2017, Richard Sandiford wrote:
> >> >> >
> >> >> >> Sorry for the late reply, but:
> >> >> >> 
> >> >> >> Richard Biener  writes:
> >> >> >> > On Mon, 7 Nov 2016, Richard Biener wrote:
> >> >> >> >
> >> >> >> >> 
> >> >> >> >> Currently we force peeling for gaps whenever element overrun can 
> >> >> >> >> occur
> >> >> >> >> but for aligned accesses we know that the loads won't trap and 
> >> >> >> >> thus
> >> >> >> >> we can avoid this.
> >> >> >> >> 
> >> >> >> >> Bootstrap and regtest running on x86_64-unknown-linux-gnu (I 
> >> >> >> >> expect
> >> >> >> >> some testsuite fallout here so didn't bother to invent a new 
> >> >> >> >> testcase).
> >> >> >> >> 
> >> >> >> >> Just in case somebody thinks the overrun is a bad idea in general
> >> >> >> >> (even when not trapping).  Like for ASAN or valgrind.
> >> >> >> >
> >> >> >> > This is what I applied.
> >> >> >> >
> >> >> >> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >> >> >> >
> >> >> >> > Richard.
> >> >> >> [...]
> >> >> >> > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> >> >> >> > index 15aec21..c29e73d 100644
> >> >> >> > --- a/gcc/tree-vect-stmts.c
> >> >> >> > +++ b/gcc/tree-vect-stmts.c
> >> >> >> > @@ -1789,6 +1794,10 @@ get_group_load_store_type (gimple *stmt, 
> >> >> >> > tree vectype, bool slp,
> >> >> >> >/* If there is a gap at the end of the group then these 
> >> >> >> > optimizations
> >> >> >> > would access excess elements in the last iteration.  */
> >> >> >> >bool would_overrun_p = (gap != 0);
> >> >> >> > +  /* If the access is aligned an overrun is fine.  */
> >> >> >> > +  if (would_overrun_p
> >> >> >> > +&& aligned_access_p (STMT_VINFO_DATA_REF (stmt_info)))
> >> >> >> > +  would_overrun_p = false;
> >> >> >> >if (!STMT_VINFO_STRIDED_P (stmt_info)
> >> >> >> >  && (can_overrun_p || !would_overrun_p)
> >> >> >> >  && compare_step_with_zero (stmt) > 0)
> >> >> >> 
> >> >> >> ...is this right for all cases?  I think it only looks for 
> >> >> >> single-vector
> >> >> >> alignment, but the gap can in principle be vector-sized or larger,
> >> >> >> at least for load-lanes.
> >> >> >>
> >> >> >> E.g. say we have a 128-bit vector of doubles in a group of size 4
> >> >> >> and a gap of 2 or 3.  Even if the access itself is aligned, the group
> >> >> >> spans two vectors and we have no guarantee that the second one
> >> >> >> is mapped.
> >> >> >
> >> >> > The check assumes that if aligned_access_p () returns true then the
> >> >> > whole access is aligned in a way that it can't cross page boundaries.
> >> >> > That's of course not the case if alignment is 16 bytes but the access
> >> >> > will be a multiple of that.
> >> >> >  
> >> >> >> I haven't been able to come up with a testcase though.  We seem to be
> >> >> >> overly conservative when computing alignments.
> >> >> >
> >> >> > Not sure if we can run into this with load-lanes given that bumps the
> >> >> > vectorization factor.  Also does load-lane work with gaps?
> >> >> >
> >> >> > I think that gap can never be larger than nunits-1 so it is by 
> >> >> > definition
> >> >> > in the last "vector" independent of the VF.
> >> >> >
> >> >> > Classical gap case is
> >> >> >
> >> >> > for (i=0; i >> >> >  {
> >> >> >y[3*i + 0] = x[4*i + 0];
> >> >> >y[3*i + 1] = x[4*i + 1];
> >> >> >y[3*i + 2] = x[4*i + 2];
> >> >> >  }
> >> >> >
> >> >> > where x has a gap of 1.  You'll get VF of 12 for the above.  Make
> >> >> > the y's different streams and you should get the perfect case for
> >> >> > load-lane:
> >> >> >
> >> >> > for (i=0; i >> >> >  {
> >> >> >y[i] = x[4*i + 0];
> >> >> >z[i] = x[4*i + 1];
> >> >> >w[i] = x[4*i + 2];
> >> >> >  } 
> >> >> >
> >> >> > previously we'd peel at least 4 iterations into the epilogue for
> >> >> > the fear of accessing x[4*i + 3].  When x is V4SI aligned that's
> >> >> > ok.
> >> >> 
> >> >> The case I was thinking of was like the second, but with the
> >> >> element type being DI or DF and with the + 2 statement removed.
> >> >> E.g.:
> >> >> 
> >> >> double __attribute__((noinline))
> >> >> foo (double *a)
> >> >> {
> >> >>   double res = 0.0;
> >> >>   for (int n = 0; n < 256; n += 4)
> >> >> res += a[n] + a[n + 1];
> >> >>   return res;
> >> >> }
> >> >> 
> >> >> (with -ffast-math).  We do use LD4 for this, and having "a" aligned
> >> >> to V2DF isn't enough to guarantee that we can access a[n + 2]
> >> >> and a[n + 3].
> >> >
> >> > Yes, indeed.  It's safe when peeling for gaps would remove
> >> > N < alignof (ref) / sizeof (ref) scalar iterations.
> >> >
> >> > Peeling for gaps simply subtracts one from the niter of the vectorized 
> >> > loop.
> >> 
> >> I think subtracting

[PATCH] Fix ICE with -Walloca-larger-than=[>INT_MAX] (PR middle-end/79809)

[Marek Polacek]

As demonstrated by this test, we can crash on the assert in alloca_call_type:
gcc_assert (is_vla || warn_alloca_limit > 0);
when -Walloca-larger-than= receives an argument greater than INT_MAX.  Even
though warn_vla_limit is marked as UInteger in c.opt, those are still
represented as ints; opt-functions.awk has

202 else if (flag_set_p("UInteger", flags))
203 return "int "
...
213 if (flag_set_p("UInteger", flags))
214 return "int "

So 4207115063 is converted to int which is some negative value.

It's probably too late to change opt-functions.awk now, so the following
is a badn aid fix.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2017-03-02  Marek Polacek  

PR middle-end/79809
* gimple-ssa-warn-alloca.c (pass_walloca::gate): Use HOST_WIDE_INT.
(alloca_call_type): Likewise.

* g++.dg/Walloca1.C: New test.

diff --git gcc/gimple-ssa-warn-alloca.c gcc/gimple-ssa-warn-alloca.c
index d553a34..dd41775 100644
--- gcc/gimple-ssa-warn-alloca.c
+++ gcc/gimple-ssa-warn-alloca.c
@@ -78,7 +78,8 @@ pass_walloca::gate (function *fun ATTRIBUTE_UNUSED)
   if (first_time_p)
 return warn_alloca != 0;
 
-  return warn_alloca_limit > 0 || warn_vla_limit > 0;
+  return ((unsigned HOST_WIDE_INT) warn_alloca_limit > 0
+ || (unsigned HOST_WIDE_INT) warn_vla_limit > 0);
 }
 
 // Possible problematic uses of alloca.
@@ -278,8 +279,8 @@ alloca_call_type (gimple *stmt, bool is_vla, tree 
*invalid_casted_type)
   wide_int min, max;
   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_UNBOUNDED);
 
-  gcc_assert (!is_vla || warn_vla_limit > 0);
-  gcc_assert (is_vla || warn_alloca_limit > 0);
+  gcc_assert (!is_vla || (unsigned HOST_WIDE_INT) warn_vla_limit > 0);
+  gcc_assert (is_vla || (unsigned HOST_WIDE_INT) warn_alloca_limit > 0);
 
   // Adjust warn_alloca_max_size for VLAs, by taking the underlying
   // type into account.
diff --git gcc/testsuite/g++.dg/Walloca1.C gcc/testsuite/g++.dg/Walloca1.C
index e69de29..23b97e8 100644
--- gcc/testsuite/g++.dg/Walloca1.C
+++ gcc/testsuite/g++.dg/Walloca1.C
@@ -0,0 +1,6 @@
+/* PR middle-end/79809 */
+/* { dg-do compile } */
+/* { dg-options "-Walloca-larger-than=4207115063 -Wvla-larger-than=1233877270 
-O2" } */
+
+int a;
+char *b = static_cast(__builtin_alloca (a)); // { dg-warning "argument 
to .alloca. may be too large" }

Marek

Re: [PATCH] Fix ICE with -Walloca-larger-than=[>INT_MAX] (PR middle-end/79809)

[Martin Liška]

On 03/02/2017 01:32 PM, Marek Polacek wrote:
> It's probably too late to change opt-functions.awk now, so the following
> is a badn aid fix.

Thanks for the patch, I've written this to my TODO list for new stage1.
It's bit connected to IntegerRange attribute which I would like to append
to options.

Martin

Re: [patch, fortran] Enable FMA for AVX2 and AVX512F for matmul

[Thomas Koenig]

Am 02.03.2017 um 13:02 schrieb Jakub Jelinek:

And this needs to use *matmul_fn instead of *matmul_p too.
The whole point is that matmul_p is only loaded using __atomic_load_n
and only optionally stored using __atomic_store_n.

Ok with those changes.


Thanks! Committed as

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=245839

Regards

Thomas

Re: [PATCH] Fix PR79345, better uninit warnings for memory

[Richard Biener]

On Thu, 2 Mar 2017, Richard Biener wrote:

> On Thu, 2 Mar 2017, Jakub Jelinek wrote:
> 
> > On Wed, Mar 01, 2017 at 03:03:29PM +0100, Richard Biener wrote:
> > > One issue with the patch is duplicate warnings as TREE_NO_WARNING
> > > doesn't work very well on tcc_reference trees which are not
> > > shared.  A followup could use some sort of hash table to mitigate
> > 
> > Can't we use TREE_NO_WARNING on get_base_address instead?  That is
> > shared...
> 
> At least for VAR_DECL based refs, yes (the only ones we currently
> analyze).  For MEM_REF bases it won't work.  It would of 
> course only warn once per aggregate and
> for a maybe-uninit warning it might be the false positive
> (the patch only sets TREE_NO_WARNING on the always-executed case).
> 
> For the user maybe we should change the order we walk BBs to RPO
> and thus warn at the first maybe-uninit point so we can say
> "further uninit warnings suppressed for X"?
> 
> > > @@ -2925,14 +2927,22 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> > > if (!*visited)
> > >   *visited = BITMAP_ALLOC (NULL);
> > > for (i = 0; i < gimple_phi_num_args (def_stmt); ++i)
> > > - cnt += walk_aliased_vdefs_1 (ref, gimple_phi_arg_def (def_stmt, i),
> > > -  walker, data, visited, 0,
> > > -  function_entry_reached);
> > > + {
> > > +   int res = walk_aliased_vdefs_1 (ref,
> > > +   gimple_phi_arg_def (def_stmt, i),
> > > +   walker, data, visited, 0,
> > > +   function_entry_reached, limit);
> > > +   if (res == -1)
> > > + return -1;
> > > +   cnt += res;
> > > + }
> > 
> > This doesn't look right.  The recursive call starts with cnt of 0 again,
> > so if say you have limit 20 and cnt 10 when you are about to recurse and
> > that walk does 15 oracle comparisons, it won't return -1, but 15 and
> > you cnt += 15 to get 25 and never reach the limit, so then you walk perhaps
> > another 10 times.
> > Can't you just pass cnt instead of 0 and then use
> >   if (res == -1)
> > return -1;
> >   cnt = res;
> > ?  Or you'd need to play gaves with decrementing the limit for the recursive
> > call.
> 
> Ah, indeed.  Will fix (passing cnt).
> 
> > > +   /* For limiting the alias walk below we count all
> > > +  vdefs in the function.  We then give the alias walk an
> > > +  overall budget (and simply not warn for further stmts).
> > > +  ???  The interface doesn't give us the chance to assign
> > > +  a maximum cost to each walk (and abort the walk if hit).  */
> > 
> > I don't understand the last two lines, I thought you've added the ability
> > to the interface above and you actually use it.
> 
> Will adjust the comment.
> 
> > Otherwise it LGTM, yes, we will end up with new warnings, but unless the
> > alias oracle is wrong, there shouldn't be too many false positives, right?
> 
> Yes, we are not warning for the case where there is at least one path
> with an initialization, like
> 
> void foo(int b)
> {
>   S s;
>   if (b)
> s.a = 1;
>   return s.a;
> }
> 
> will not warn (trivial to add but not necessary for the regression fix).
> 
> We also do not warn for pointer-based accesses (so unfortunately no
> fix for PR2972).  Also trivial to add, but see PR79814 for more
> bootstrap fallout.

On IRC we decided to wait&see for the TREE_NO_WARNING issue.  So the
following is what I committed.

Bootstrapped / tested on x86_64-unknown-linux-gnu.

Richard.

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.

Index: gcc/tree-ssa-alias.h
===
--- gcc/tree-ssa-alias.h(revision 245803)
+++ gcc/tree-ssa-alias.h(working copy)
@@ -131,10 +131,11 @@ extern void *walk_non_aliased_vuses (ao_
 void *(*)(ao_ref *, tree, void *, bool *),
 tree (*)(tree),
 void *);
-extern unsigned int walk_al

Re: [PATCH] Fix ICE with multiple conditional traps turned into unconditional in one bb (PR rtl-optimization/79780)

[Bernd Schmidt]

On 03/02/2017 10:23 AM, Jakub Jelinek wrote:

2017-03-02  Jakub Jelinek  

PR rtl-optimization/79780
* cprop.c (one_cprop_pass): When second and further conditional trap
in a single basic block is turned into an unconditional trap, turn it
into a deleted note to avoid RTL verification failures.

* gcc.c-torture/compile/pr79780.c: New test.


Ok.


Bernd

[PATCH] Fix release-checking bootstrap

[Richard Biener]

Looks like I broke $subject, thus the following.  The issue is similar
as the fixed-value.c case I fixed with the Wuninit patch.

Bootstrap on x86_64-unknown-linux-gnu with release checking in stage3,
will commit soonish.

Richard.

2017-03-02  Richard Biener  

* fold-const.c (const_binop): Use ulow () instead of elt (0).

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 245839)
+++ gcc/fold-const.c(working copy)
@@ -1249,7 +1249,7 @@ const_binop (enum tree_code code, tree a
  return NULL_TREE;
wide_int w2 = arg2;
f2.data.high = w2.elt (1);
-   f2.data.low = w2.elt (0);
+   f2.data.low = w2.ulow ();
f2.mode = SImode;
  }
  break;

[PATCH, GCC/LTO] Fix PR69866: LTO with def for weak alias in regular object file

[Thomas Preudhomme]

Hi,

This patch fixes an assert failure when linking one LTOed object file
having a weak alias with a regular object file containing a strong
definition for that same symbol. The patch is twofold:

+ do not add an alias to a partition if it is external
+ do not declare (.globl) an alias if it is external

ChangeLog entries are as follow:

*** gcc/lto/ChangeLog ***

2017-03-01  Thomas Preud'homme  

PR lto/69866
* lto/lto-partition.c (add_symbol_to_partition_1): Do not add external
aliases to partition.

*** gcc/ChangeLog ***

2017-03-01  Thomas Preud'homme  

PR lto/69866
* cgraphunit.c (cgraph_node::assemble_thunks_and_aliases): Do not
declare external aliases.

*** gcc/testsuite/ChangeLog ***

2017-02-28  Thomas Preud'homme  

PR lto/69866
* gcc.dg/lto/pr69866_0.c: New test.
* gcc.dg/lto/pr69866_1.c: Likewise.


Testing: Testsuite shows no regression when targeting Cortex-M3 with an
arm-none-eabi GCC cross-compiler, neither does it show any regression with 
native LTO-bootstrapped x86-64_linux-gnu and aarch64-linux-gnu compilers.


Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index c82a88a599ca61b068dd9783d2a6158163809b37..580500ff922b8546d33119261a2455235edbf16d 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1972,7 +1972,7 @@ cgraph_node::assemble_thunks_and_aliases (void)
   FOR_EACH_ALIAS (this, ref)
 {
   cgraph_node *alias = dyn_cast  (ref->referring);
-  if (!alias->transparent_alias)
+  if (!alias->transparent_alias && !DECL_EXTERNAL (alias->decl))
 	{
 	  bool saved_written = TREE_ASM_WRITTEN (decl);
 
diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index e27d0d1690c1fcfb39e2fac03ce0f4154031fc7c..f44fd435ed075a27e373bdfdf0464eb06e1731ef 100644
--- a/gcc/lto/lto-partition.c
+++ b/gcc/lto/lto-partition.c
@@ -178,7 +178,8 @@ add_symbol_to_partition_1 (ltrans_partition part, symtab_node *node)
   /* Add all aliases associated with the symbol.  */
 
   FOR_EACH_ALIAS (node, ref)
-if (!ref->referring->transparent_alias)
+if (!ref->referring->transparent_alias
+	&& ref->referring->get_partitioning_class () != SYMBOL_EXTERNAL)
   add_symbol_to_partition_1 (part, ref->referring);
 else
   {
@@ -189,7 +190,8 @@ add_symbol_to_partition_1 (ltrans_partition part, symtab_node *node)
 	  {
 	/* Nested transparent aliases are not permitted.  */
 	gcc_checking_assert (!ref2->referring->transparent_alias);
-	add_symbol_to_partition_1 (part, ref2->referring);
+	if (ref2->referring->get_partitioning_class () != SYMBOL_EXTERNAL)
+	  add_symbol_to_partition_1 (part, ref2->referring);
 	  }
   }
 
diff --git a/gcc/testsuite/gcc.dg/lto/pr69866_0.c b/gcc/testsuite/gcc.dg/lto/pr69866_0.c
new file mode 100644
index ..f49ef8d4c1da7a21d1bfb5409d647bd18141595b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr69866_0.c
@@ -0,0 +1,13 @@
+/* { dg-lto-do link } */
+
+int _umh(int i)
+{
+  return i+1;
+}
+
+int weaks(int i) __attribute__((weak, alias("_umh")));
+
+int main()
+{
+  return weaks(10);
+}
diff --git a/gcc/testsuite/gcc.dg/lto/pr69866_1.c b/gcc/testsuite/gcc.dg/lto/pr69866_1.c
new file mode 100644
index ..3a14f850eefaffbf659ce4642adef7900330f4ed
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr69866_1.c
@@ -0,0 +1,6 @@
+/* { dg-options { -fno-lto } } */
+
+int weaks(int i)
+{
+  return i+1;
+}

[PATCH] S/390: Disable vectorization for loops with few iterations

[Robin Dapp]

Hi,

the following patch defines the PARAM_MIN_VECT_LOOP_BOUND parameter in
the s390 backend.  It helps with the vectorization epilogue problem
described here [1].
I see an overall performance increase of > 1% in SPECfp2006, yet some
cases like cactusADM regress.  This seems to be caused by the vectorizer
creating an epilogue guard for one more iteration than before, which, in
turn, causes e.g. predcom to run on the epilogue that it used to ignore
before ("Loop iterates only 1 time, nothing to do.").  Subsequent,
minor, effects cause an eventual slowdown.

Until the reason for the bad epilogue code is understood, this patch
mitigates the problem.  When investigating the issue, I stumbled across
an attempt to vectorize the epilogue itself as well as combine it with
the vectorized loop in addition to vector masking [2].  A similar
approach might also help here.  My original observation of high register
pressure within the epilogue still stands.  In this specific case, it
would most likely suffice to save all registers once, run the epilogue
and restore the registers.  I'm pretty sure this would be faster than
the "spill fest" that's currently happening.

Regards
 Robin

[1] https://gcc.gnu.org/ml/gcc/2017-01/msg00234.html
[2] https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01562.html

--

gcc/ChangeLog:

2017-03-02  Robin Dapp  

* config/s390/s390.c (s390_option_override_internal): Set
PARAM_MIN_VECT_LOOP_BOUND
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index bfb2865..bd6b059 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -14680,6 +14680,10 @@ s390_option_override_internal (bool main_args_p,
  opts->x_param_values,
  opts_set->x_param_values);
 
+  maybe_set_param_value (PARAM_MIN_VECT_LOOP_BOUND, 2,
+			 opts->x_param_values,
+			 opts_set->x_param_values);
+
   /* Call target specific restore function to do post-init work.  At the moment,
  this just sets opts->x_s390_cost_pointer.  */
   s390_function_specific_restore (opts, NULL);

Re: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Rainer Orth]

Hi Toma,

>> that's not what I suggested (or at least meant to suggest): having
>> gettimeofday as an effective-target keyword (like setrlimit, mmap, and
>> others) is the way to go, just your previous implementation of
>> check_effective_target_gettimeofday was problematic/unreliable.
>> 
>> If you go this route, there's no need to modify target-supports-dg.exp
>> at all.
>
> I see now. The dg-require-* directives are the predecessors to the
> dg-require-effective-target directives.

right: the latter requires less setup to implement.

> I've changed it to be a dg-require-effective-target for gettimeofday instead.
> Tested it and it works just as well as before.
>
>> Besides: I forget to mention that new effective-target keywords need to
>> be documented in sourcebuild.texi.
>
> Done. Thanks for pointing this out.
>
> There were 2 existing ways of describing this sort of effective-target; I 
> chose
> the more succinct one.

Seems fine: I could find no difference between the two sets, just
another random difference.

> gcc/
>   * doc/sourcebuild.texi (Effective-Target Keywords, Environment
>   attributes): Document gettimeofday.
>
> gcc/testsuite/
>
>   * gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
>   gettimeofday. Remove dg-skip-if for AVR.

Two spaces after period.

>   * lib/target-supports.exp (check_effective_target_gettimeofday): New.

Better say "New proc." or something like this.

Ok with those nits fixed.

Thanks for your patience.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Toma Tabacu]

Hi,

> From: Rainer Orth
> >
> > gcc/testsuite/
> >
> > * gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
> > gettimeofday. Remove dg-skip-if for AVR.
> 
> Two spaces after period.
> 

Fixed.

> > * lib/target-supports.exp (check_effective_target_gettimeofday): New.
> 
> Better say "New proc." or something like this.
> 

Fixed.

> 
> Thanks for your patience.
> 
>   Rainer

No problem.
Thanks for the review.

Below is the version with the updated ChangeLog entries.

Catherine, Matthew, what do you think ?

Regards,
Toma

gcc/
* doc/sourcebuild.texi (Effective-Target Keywords, Environment
attributes): Document gettimeofday.

gcc/testsuite/

* gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
gettimeofday.  Remove dg-skip-if for AVR.
* lib/target-supports.exp (check_effective_target_gettimeofday):
New proc.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 0dc4348..da17ff6 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1914,6 +1914,9 @@ Target is @samp{freestanding} as defined in section 4 of 
the C99 standard.
 Effectively, it is a target which supports no extra headers or libraries
 other than what is considered essential.
 
+@item gettimeofday
+Target supports @code{gettimeofday}.
+
 @item init_priority
 Target supports constructors with initialization priority arguments.
 
diff --git a/gcc/testsuite/gcc.dg/lto/pr60449_0.c 
b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
index 5b878a6..e6c3166 100644
--- a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
@@ -1,5 +1,5 @@
 /* { dg-lto-do link } */
-/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" } } */
+/* { dg-require-effective-target gettimeofday } */
 
 extern int printf (const char *__restrict __format, ...);
 typedef long int __time_t;
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 2766af4..d1639dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -968,6 +968,11 @@ proc check_effective_target_setrlimit {} {
 return [check_function_available "setrlimit"]
 }
 
+# Return 1 if the target supports gettimeofday, 0 otherwise.
+proc check_effective_target_gettimeofday {} {
+return [check_function_available "gettimeofday"]
+}
+
 # Return 1 if the target supports swapcontext, 0 otherwise.
 proc check_effective_target_swapcontext {} {
 return [check_no_compiler_messages swapcontext executable {

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Moore, Catherine]

> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, March 2, 2017 11:47 AM
> To: Rainer Orth 
> Cc: Moore, Catherine ; gcc-
> patc...@gcc.gnu.org; Matthew Fortune
> 
> Subject: RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-
> elf* targets.
> 
> Hi,
> 
> > From: Rainer Orth
> > >
> > > gcc/testsuite/
> > >
> > >   * gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
> > >   gettimeofday. Remove dg-skip-if for AVR.
> >
> > Two spaces after period.
> >
> 
> Fixed.
> 
> > >   * lib/target-supports.exp (check_effective_target_gettimeofday):
> New.
> >
> > Better say "New proc." or something like this.
> >
> 
> Fixed.
> 
> >
> > Thanks for your patience.
> >
> > Rainer
> 
> No problem.
> Thanks for the review.
> 
> Below is the version with the updated ChangeLog entries.
> 
> Catherine, Matthew, what do you think ?
> 

This patch fixes my original objection.  Thanks.

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

[Thomas Preudhomme]

On 27/02/17 05:48, NightStrike wrote:



On Feb 22, 2017 10:06 AM, "Thomas Preudhomme" mailto:thomas.preudho...@foss.arm.com>> wrote:

Oh great thanks!

Best regards,

Thomas


On 17/02/17 22:52, JonY wrote:

On 02/17/2017 11:31 AM, Thomas Preudhomme wrote:

Here you are:

2017-01-24  Thomas Preud'homme  mailto:thomas.preudho...@arm.com>>

* configure.ac 
(--enable-mingw-wildcard): Add new configurable
feature.
* configure: Regenerate.
* config.in : Regenerate.
* config/i386/driver-mingw32.c: new file.
* config/i386/x-mingw32: Add rule to build driver-mingw32.o.
* config.host: Link driver-mingw32.o on MinGW host.
* doc/install.texi: Document new --enable-mingw-wildcard
configure
option.

Must have forgotten to paste it.


Thanks, I'll stage it locally until stage 1 opens.


This should be mentioned in the "porting to" page when it eventually goes in, as
it may be surprising behavior.



Will do once the file is created for gcc-8. Thanks for the suggestion

Best regards,

Thomas

[PATCH,testsuite] MIPS: Fix register mode checking for n64 in pr68273.c.

[Toma Tabacu]

Hi,

pr68273.c currently fails when targeting MIPS64 with the n64 ABI.
This is because it is checking for some registers in SImode, but, because of
n64, they will actually be in DImode.

This patch restricts matching for SImode registers to ilp32 targets and adds
matching for DImode registers for lp64 targets.
This makes sure that the test is run on as many targets as possible, compared
to the alternative of adding -mabi=32 to the test options.

I haven't checked to see what happens with eabi or o64, though.

Does this approach work ? Or should I just make separate tests for o32, n32 and
n64, each one using -mabi=* as a test option to force an ABI ?

Tested with mips-mti-elf.

Regards,
Toma

gcc/testsuite/

* gcc.target/mips/pr68273.c (dg-final): Match SImode registers only for
ilp32 targets and match DImode registers for lp64 targets.

diff --git a/gcc/testsuite/gcc.target/mips/pr68273.c 
b/gcc/testsuite/gcc.target/mips/pr68273.c
index cbe81e1..ce8ca93 100644
--- a/gcc/testsuite/gcc.target/mips/pr68273.c
+++ b/gcc/testsuite/gcc.target/mips/pr68273.c
@@ -75,5 +75,8 @@ op (Node q)
 }
 
 
-/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:SI 5 \\\$5\\\)" 2 
"expand" } }  */
-/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:SI 6 \\\$6\\\)" 1 
"expand" } }  */
+/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:SI 5 \\\$5\\\)" 2 
"expand" { target { ilp32 } } } }  */
+/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:SI 6 \\\$6\\\)" 1 
"expand" { target { ilp32 } } } }  */
+
+/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:DI 5 \\\$5\\\)" 2 
"expand" { target { lp64 } } } }  */
+/* { dg-final { scan-rtl-dump-times "\\\(set \\\(reg:DI 6 \\\$6\\\)" 1 
"expand" { target { lp64 } } } }  */

Re: [PATCH,rs6000] PR79395: Fix compile error with -mcpu=power9 and -mno-vsx and __builtin_vec_cmpne_p

[Andreas Schwab]

../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]

 UNSPEC_PREDICATE))
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ne_v8hi_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
 UNSPEC_PREDICATE))
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ne_v16qi_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
 UNSPEC_PREDICATE))
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v4si_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
  [(match_operand:VI 1 "vlogical_operand")
  ^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v8hi_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
  [(match_operand:VI 1 "vlogical_operand")
  ^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v16qi_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
  [(match_operand:VI 1 "vlogical_operand")
  ^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ne_v2di_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:784:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
   [(parallel
  ^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v2di_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:810:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
 [(set (reg:CC CR6_REGNO)
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ne_v4sf_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
 [(set (reg:CC CR6_REGNO)
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ne_v2df_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
 [(set (reg:CC CR6_REGNO)
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v4sf_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
(gt:VEC_A (match_dup 1)
 ~^
../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
gen_vector_ae_v2df_p(rtx, rtx, rtx)':
../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
uninitialized in this function [-Werror=uninitialized]
(gt:VEC_A (match_dup 1)
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* gen_vsx_tsqrtdf2_fg(rtx, 
rtx)':
../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
(set (match_operand:SI 0 "gpc_reg_operand" "")
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
gen_vsx_tsqrtv4sf2_fg(rtx, rtx)':
../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
(set (match_operand:SI 0 "gpc_reg_operand" "")
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
gen_vsx_tsqrtv2df2_fg(rtx, rtx)':
../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
(set (match_operand:SI 0 "gpc_reg_operand" "")
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* gen_vsx_tsqrtdf2_fe(rtx, 
rtx)':
../../gcc/config/rs6000/vsx.md:1415:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
   "xtsqrt %0,%x1"
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
gen_vsx_tsqrtv4sf2_fe(rtx, rtx)':
../../gcc/config/rs6000/vsx.md:1415:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
   "xtsqrt %0,%x1"
 ~^
../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
gen_vsx_tsqrtv2df2_fe(rtx, rtx)':
../../gcc/config/rs6000/vsx.md:1415:14: error: 'operands[2]' is used 
uninitialized in this function [-Werror=uninitialized]
   "xtsqrt %0,%x1"
 ~^

Andreas.

-- 
Andreas Schwab, sch...

Re: [PATCH,rs6000] PR79395: Fix compile error with -mcpu=power9 and -mno-vsx and __builtin_vec_cmpne_p

[Bill Schmidt]

Hi Andreas,

We discovered the problem this morning in-house and are working on a patch.

-- Bill

Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com

> On Mar 2, 2017, at 11:25 AM, Andreas Schwab  wrote:
> 
> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> 
> UNSPEC_PREDICATE))
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ne_v8hi_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> UNSPEC_PREDICATE))
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ne_v16qi_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> UNSPEC_PREDICATE))
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v4si_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>  [(match_operand:VI 1 "vlogical_operand")
>  ^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v8hi_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>  [(match_operand:VI 1 "vlogical_operand")
>  ^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v16qi_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>  [(match_operand:VI 1 "vlogical_operand")
>  ^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ne_v2di_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:784:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>   [(parallel
>  ^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v2di_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:810:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> [(set (reg:CC CR6_REGNO)
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ne_v4sf_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> [(set (reg:CC CR6_REGNO)
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ne_v2df_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
> [(set (reg:CC CR6_REGNO)
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v4sf_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>(gt:VEC_A (match_dup 1)
> ~^
> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
> gen_vector_ae_v2df_p(rtx, rtx, rtx)':
> ../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
> uninitialized in this function [-Werror=uninitialized]
>(gt:VEC_A (match_dup 1)
> ~^
> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
> gen_vsx_tsqrtdf2_fg(rtx, rtx)':
> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
> uninitialized in this function [-Werror=uninitialized]
>(set (match_operand:SI 0 "gpc_reg_operand" "")
> ~^
> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
> gen_vsx_tsqrtv4sf2_fg(rtx, rtx)':
> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
> uninitialized in this function [-Werror=uninitialized]
>(set (match_operand:SI 0 "gpc_reg_operand" "")
> ~^
> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
> gen_vsx_tsqrtv2df2_fg(rtx, rtx)':
> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
> uninitialized in this function [-Werror=uninitialized]
>(set (match_operand:SI 0 "gpc_reg_operand" "")
> ~^
> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
> gen_vsx_tsqrtdf2_fe(rtx, rtx)':
> ../../gcc/config/rs6000/vsx.md:1415:14: error: 'operands[2]' is used 
> uninitialized in this function [-Werror=uninitialized]
>   "xtsqrt %0,%x1"
> ~^
> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
> gen_vsx_tsqrtv4sf2_fe(rtx, rtx)':
> ../../gcc/config/rs6000/v

C PATCH to fix c/79758 (ICE-on-invalid with function redefinition and old style decls)

[Marek Polacek]

This patch fixes an ICE-on-invalid where we redefine a function whose prototype
parameter list contains error_mark_node, which then causes a crash in
store_parm_decls_oldstyle.  Fixed by adding yet another error_mark_node check.

While at it, I fixed wrong formatting in the nearby code.  Also use NULL_TREE
instead of 0 where appropriate.  I really dislike those zeros-as-trees; one
day I'll just go and turn them into NULL_TREEs.

I also fixed missing TREE_VALUE (), which is what I think was intended there.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2017-03-02  Marek Polacek  

PR c/79758
* c-decl.c (store_parm_decls_oldstyle): Check if the element of
current_function_prototype_arg_types is error_mark_node.  Fix
formatting.  Add TREE_VALUE.

* gcc.dg/noncompile/pr79758.c: New test.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 32edacc..e3bf898 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -8965,12 +8965,15 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
   tree type;
   for (parm = DECL_ARGUMENTS (fndecl),
 type = current_function_prototype_arg_types;
-  parm || (type && TREE_VALUE (type) != error_mark_node
-   && (TYPE_MAIN_VARIANT (TREE_VALUE (type)) != 
void_type_node));
+  parm || (type != NULL_TREE
+   && TREE_VALUE (type) != error_mark_node
+   && TYPE_MAIN_VARIANT (TREE_VALUE (type)) != void_type_node);
   parm = DECL_CHAIN (parm), type = TREE_CHAIN (type))
{
- if (parm == 0 || type == 0
- || TYPE_MAIN_VARIANT (TREE_VALUE (type)) == void_type_node)
+ if (parm == NULL_TREE
+ || type == NULL_TREE
+ || (TREE_VALUE (type) != error_mark_node
+ && TYPE_MAIN_VARIANT (TREE_VALUE (type)) == void_type_node))
{
  if (current_function_prototype_built_in)
warning_at (DECL_SOURCE_LOCATION (fndecl),
@@ -8996,7 +8999,7 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
 declared for the arg.  ISO C says we take the unqualified
 type for parameters declared with qualified type.  */
  if (TREE_TYPE (parm) != error_mark_node
- && TREE_TYPE (type) != error_mark_node
+ && TREE_TYPE (TREE_VALUE (type)) != error_mark_node
  && ((TYPE_ATOMIC (DECL_ARG_TYPE (parm))
   != TYPE_ATOMIC (TREE_VALUE (type)))
  || !comptypes (TYPE_MAIN_VARIANT (DECL_ARG_TYPE (parm)),
@@ -9017,7 +9020,7 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
  if (targetm.calls.promote_prototypes (TREE_TYPE 
(current_function_decl))
  && INTEGRAL_TYPE_P (TREE_TYPE (parm))
  && TYPE_PRECISION (TREE_TYPE (parm))
- < TYPE_PRECISION (integer_type_node))
+< TYPE_PRECISION (integer_type_node))
DECL_ARG_TYPE (parm)
  = c_type_promotes_to (TREE_TYPE (parm));
 
diff --git gcc/testsuite/gcc.dg/noncompile/pr79758.c 
gcc/testsuite/gcc.dg/noncompile/pr79758.c
index e69de29..aeaf7c7 100644
--- gcc/testsuite/gcc.dg/noncompile/pr79758.c
+++ gcc/testsuite/gcc.dg/noncompile/pr79758.c
@@ -0,0 +1,6 @@
+/* PR c/79758 */
+/* { dg-do compile } */
+
+void fn1 (int[a]) { }; /* { dg-error "undeclared here|parameter name omitted" 
} */
+void fn1 (b) { }; /* { dg-error "redefinition" } */
+/* { dg-warning "defaults to 'int'" "" { target *-*-* } .-1 } */

Marek

Add -Wdisabled-optimization to loop prefetching pass (PR, tree-optimization/79803).

[Martin Liška]

Hello.

I've just followed Richi's advises in the PR.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 9a850909d00e2b63961167665d48f7ebbb99ac84 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 2 Mar 2017 13:34:55 +0100
Subject: [PATCH] Add -Wdisabled-optimization to loop prefetching pass (PR
 tree-optimization/79803).

gcc/ChangeLog:

2017-03-02  Martin Liska  

	PR tree-optimization/79803
	* tree-ssa-loop-prefetch.c (tree_ssa_prefetch_arrays): Remove
	assert.
	(pass_loop_prefetch::execute): Disabled optimization if an
	assumption about L1 cache size is not met.

gcc/testsuite/ChangeLog:

2017-03-02  Martin Liska  

	PR tree-optimization/79803
	* gcc.dg/tree-ssa/pr79803.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr79803.c | 39 +
 gcc/tree-ssa-loop-prefetch.c| 13 +++
 2 files changed, 48 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr79803.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79803.c b/gcc/testsuite/gcc.dg/tree-ssa/pr79803.c
new file mode 100644
index 000..e43a40739d5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79803.c
@@ -0,0 +1,39 @@
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options "-march=opteron-sse3 -Ofast --param l1-cache-line-size=3 -Wdisabled-optimization" } */
+/* { dg-require-effective-target indirect_jumps } */
+
+#include 
+
+extern void abort (void);
+
+jmp_buf buf;
+
+void raise0(void)
+{
+  __builtin_longjmp (buf, 1);
+}
+
+int execute(int cmd) /* { dg-warning "'l1-cache-size' is not an even number 3" } */
+{
+  int last = 0;
+
+  if (__builtin_setjmp (buf) == 0)
+while (1)
+  {
+	last = 1;
+	raise0 ();
+  }
+
+  if (last == 0)
+return 0;
+  else
+return cmd;
+}
+
+int main(void)
+{
+  if (execute (1) == 0)
+abort ();
+
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index 54cd9421998..2cdf210308b 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -47,6 +47,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks.h"
 #include "tree-inline.h"
 #include "tree-data-ref.h"
+#include "diagnostic-core.h"
 
 /* This pass inserts prefetch instructions to optimize cache usage during
accesses to arrays in loops.  It processes loops sequentially and:
@@ -1977,10 +1978,6 @@ tree_ssa_prefetch_arrays (void)
   set_builtin_decl (BUILT_IN_PREFETCH, decl, false);
 }
 
-  /* We assume that size of cache line is a power of two, so verify this
- here.  */
-  gcc_assert ((PREFETCH_BLOCK & (PREFETCH_BLOCK - 1)) == 0);
-
   FOR_EACH_LOOP (loop, LI_FROM_INNERMOST)
 {
   if (dump_file && (dump_flags & TDF_DETAILS))
@@ -2038,6 +2035,14 @@ pass_loop_prefetch::execute (function *fun)
   if (number_of_loops (fun) <= 1)
 return 0;
 
+  if ((PREFETCH_BLOCK & (PREFETCH_BLOCK - 1)) != 0)
+{
+  warning (OPT_Wdisabled_optimization,
+	   "% is not an even number %d",
+	   PREFETCH_BLOCK);
+  return 0;
+}
+
   return tree_ssa_prefetch_arrays ();
 }
 
-- 
2.11.1

Fix ICE in use-after-scope w/ -fno-tree-dce (PR, sanitize/79783).

[Martin Liška]

Hello.

It can happen with inlining and -fno-tree-dce that VAR_DECL for a SSA
NAME was removed and thus the poisoning should not have any usage.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From d8aa72dc1d696f5500c00b6c2f532f2a87cf58d2 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 2 Mar 2017 11:55:00 +0100
Subject: [PATCH] Fix ICE in use-after-scope w/ -fno-tree-dce (PR
 sanitize/79783).

gcc/ChangeLog:

2017-03-02  Martin Liska  

	PR sanitize/79783
	* asan.c (asan_expand_poison_ifn): Do not expand ASAN_POISON
	when having a SSA NAME w/o VAR_DECL assigned to it.

gcc/testsuite/ChangeLog:

2017-03-02  Martin Liska  

	PR sanitize/79783
	* g++.dg/asan/pr79783.C: New test.
---
 gcc/asan.c  |  5 -
 gcc/testsuite/g++.dg/asan/pr79783.C | 19 +++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/asan/pr79783.C

diff --git a/gcc/asan.c b/gcc/asan.c
index 6cdd59b7ea7..307423ced03 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -3107,7 +3107,10 @@ asan_expand_poison_ifn (gimple_stmt_iterator *iter,
 {
   gimple *g = gsi_stmt (*iter);
   tree poisoned_var = gimple_call_lhs (g);
-  if (!poisoned_var)
+
+  /* It can happen with inlining and -fno-tree-dce that VAR_DECL for a SSA
+ NAME was removed and thus the poisoning should not have any usage.  */
+  if (!poisoned_var || SSA_NAME_VAR (poisoned_var) == NULL_TREE)
 {
   gsi_remove (iter, true);
   return true;
diff --git a/gcc/testsuite/g++.dg/asan/pr79783.C b/gcc/testsuite/g++.dg/asan/pr79783.C
new file mode 100644
index 000..939f60b2819
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/pr79783.C
@@ -0,0 +1,19 @@
+// PR sanitizer/79783
+// { dg-options "-fno-tree-dce" }
+
+struct A
+{
+  static void foo(const char&) {}
+};
+
+struct B
+{
+  B() { A::foo(char()); }
+};
+
+struct C
+{
+  virtual void bar() const { B b; }
+};
+
+C c;
-- 
2.11.1

GCSE: Use HOST_WIDE_INT instead of int (PR, rtl-optimization/79574).

[Martin Liška]

Hello.

This is second part of fixes needed to not trigger integer overflow in gcse 
pass.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From a3e8ca75be55bd6d707f54ae3972e30285b64566 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 2 Mar 2017 12:21:07 +0100
Subject: [PATCH] GCSE: Use HOST_WIDE_INT instead of int (PR
 rtl-optimization/79574).

gcc/ChangeLog:

2017-03-02  Martin Liska  

	PR rtl-optimization/79574
	* gcse.c (struct gcse_expr): Use HOST_WIDE_INT instead of int.
	(hash_scan_set): Likewise.
	(dump_hash_table): Likewise.
	(hoist_code): Likewise.

gcc/testsuite/ChangeLog:

2017-03-02  Martin Liska  

	PR rtl-optimization/79574
	* gcc.dg/pr79574-2.c: New test.
---
 gcc/gcse.c   | 26 +++---
 gcc/testsuite/gcc.dg/pr79574-2.c | 33 +
 2 files changed, 48 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr79574-2.c

diff --git a/gcc/gcse.c b/gcc/gcse.c
index 5c6984c3240..2b0a11268eb 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -281,7 +281,7 @@ struct gcse_expr
  to keep register pressure under control.
  A value of "0" removes restrictions on how far the expression can
  travel.  */
-  int max_distance;
+  HOST_WIDE_INT max_distance;
 };
 
 /* Occurrence of an expression.
@@ -458,7 +458,7 @@ static int oprs_unchanged_p (const_rtx, const rtx_insn *, int);
 static int oprs_anticipatable_p (const_rtx, const rtx_insn *);
 static int oprs_available_p (const_rtx, const rtx_insn *);
 static void insert_expr_in_table (rtx, machine_mode, rtx_insn *, int, int,
-  int, struct gcse_hash_table_d *);
+  HOST_WIDE_INT, struct gcse_hash_table_d *);
 static unsigned int hash_expr (const_rtx, machine_mode, int *, int);
 static void record_last_reg_set_info (rtx_insn *, int);
 static void record_last_mem_set_info (rtx_insn *);
@@ -488,8 +488,10 @@ static void alloc_code_hoist_mem (int, int);
 static void free_code_hoist_mem (void);
 static void compute_code_hoist_vbeinout (void);
 static void compute_code_hoist_data (void);
-static int should_hoist_expr_to_dom (basic_block, struct gcse_expr *, basic_block,
- sbitmap, int, int *, enum reg_class,
+static int should_hoist_expr_to_dom (basic_block, struct gcse_expr *,
+ basic_block,
+ sbitmap, HOST_WIDE_INT, int *,
+ enum reg_class,
  int *, bitmap, rtx_insn *);
 static int hoist_code (void);
 static enum reg_class get_regno_pressure_class (int regno, int *nregs);
@@ -743,7 +745,7 @@ static basic_block current_bb;
GCSE.  */
 
 static int
-want_to_gcse_p (rtx x, machine_mode mode, int *max_distance_ptr)
+want_to_gcse_p (rtx x, machine_mode mode, HOST_WIDE_INT *max_distance_ptr)
 {
 #ifdef STACK_REGS
   /* On register stack architectures, don't GCSE constants from the
@@ -1115,7 +1117,8 @@ expr_equiv_p (const_rtx x, const_rtx y)
 static void
 insert_expr_in_table (rtx x, machine_mode mode, rtx_insn *insn,
 		  int antic_p,
-		  int avail_p, int max_distance, struct gcse_hash_table_d *table)
+		  int avail_p, HOST_WIDE_INT max_distance,
+		  struct gcse_hash_table_d *table)
 {
   int found, do_not_record_p;
   unsigned int hash;
@@ -1231,7 +1234,7 @@ hash_scan_set (rtx set, rtx_insn *insn, struct gcse_hash_table_d *table)
   else if (REG_P (dest))
 {
   unsigned int regno = REGNO (dest);
-  int max_distance = 0;
+  HOST_WIDE_INT max_distance = 0;
 
   /* See if a REG_EQUAL note shows this equivalent to a simpler expression.
 
@@ -1300,7 +1303,7 @@ hash_scan_set (rtx set, rtx_insn *insn, struct gcse_hash_table_d *table)
   else if (flag_gcse_las && REG_P (src) && MEM_P (dest))
 {
   unsigned int regno = REGNO (src);
-  int max_distance = 0;
+  HOST_WIDE_INT max_distance = 0;
 
   /* Only record sets of pseudo-regs in the hash table.  */
   if (regno >= FIRST_PSEUDO_REGISTER
@@ -1413,7 +1416,7 @@ dump_hash_table (FILE *file, const char *name, struct gcse_hash_table_d *table)
   {
 	expr = flat_table[i];
 	fprintf (file, "Index %d (hash value %d; max distance %d)\n  ",
-		 expr->bitmap_index, hash_val[i], expr->max_distance);
+		 expr->bitmap_index, hash_val[i], (int)expr->max_distance);
 	print_rtl (file, expr->expr);
 	fprintf (file, "\n");
   }
@@ -2884,7 +2887,8 @@ update_bb_reg_pressure (basic_block bb, rtx_insn *from)
 
 static int
 should_hoist_expr_to_dom (basic_block expr_bb, struct gcse_expr *expr,
-			  basic_block bb, sbitmap visited, int distance,
+			  basic_block bb, sbitmap visited,
+			  HOST_WIDE_INT distance,
 			  int *bb_size, enum reg_class pressure_class,
 			  int *nregs, bitmap hoisted_bbs, rtx_insn *from)
 {
@@ -3161,7 +3165,7 @@ hoist_code (void)
 		 computes the expression.  */
 	  FOR_EACH_VEC_ELT (domby, j, dominated)
 		{
-		  int max_distance;
+		  HOST_WIDE_INT max_distance;
 
 		  /* Ignore self dominance.  */
 		  if (bb == dominated)
diff --git a/gcc/testsui

C++ PATCH to fix -Wpedantic -Werror=write-strings behavior (PR c++/79791)

[Marek Polacek]

This PR complains that the -Wpedantic -Werror=write-strings combination doesn't
result in an error but in a pedwarn, which I think is a valid point.  The
principle is that more specific options take precedence over less specific
options, so e.g. -Wpedantic -Wno-write-strings shouldn't give a -Wwrite-strings
warning.  -Wwrite-strings is enabled by default for C++:
c-family/c-opts.c:205:  opts->x_warn_write_strings = c_dialect_cxx ();
so I think the following patch fixes the problem; the warning will only ever be
disabled if the user specifies -Wno-write-strings, and in C++11 it will always
be a pedwarn, so -pedantic-errors works as expected.  I added a bunch of tests
to further exercise other combinations, too.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2017-03-02  Marek Polacek  

PR c++/79791
* typeck.c (string_conv_p): In C++11, always call pedwarn with
OPT_Wwrite_strings.

* g++.dg/warn/Wwrite-strings-1.C: New test.
* g++.dg/warn/Wwrite-strings-2.C: New test.
* g++.dg/warn/Wwrite-strings-3.C: New test.
* g++.dg/warn/Wwrite-strings-4.C: New test.
* g++.dg/warn/Wwrite-strings-5.C: New test.
* g++.dg/warn/Wwrite-strings-6.C: New test.
* g++.dg/warn/Wwrite-strings-7.C: New test.
* g++.dg/warn/Wwrite-strings-8.C: New test.
* g++.dg/warn/Wwrite-strings-9.C: New test.
* g++.dg/warn/Wwrite-strings-10.C: New test.
* g++.dg/warn/Wwrite-strings-11.C: New test.
* g++.dg/warn/Wwrite-strings-12.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 3216bc41..d24 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -2175,8 +2175,7 @@ string_conv_p (const_tree totype, const_tree exp, int 
warn)
   if (warn)
 {
   if (cxx_dialect >= cxx11)
-   pedwarn (input_location,
-pedantic ? OPT_Wpedantic : OPT_Wwrite_strings,
+   pedwarn (input_location, OPT_Wwrite_strings,
 "ISO C++ forbids converting a string constant to %qT",
 totype);
   else
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
index e69de29..05abca3 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
@@ -0,0 +1,5 @@
+// PR c++/79791
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+char *s = "foo"; // { dg-warning "ISO C\\+\\+ forbids converting a string 
constant" }
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
index e69de29..d34b0b0 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
@@ -0,0 +1,5 @@
+// PR c++/79791
+// { dg-do compile { target { ! c++11 } } }
+// { dg-options "" }
+
+char *s = "foo"; // { dg-warning "deprecated conversion from string constant" }
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
index e69de29..11ddcdb 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
@@ -0,0 +1,5 @@
+// PR c++/79791
+// { dg-do compile { target { ! c++11 } } }
+// { dg-options "-pedantic-errors" }
+
+char *s = "foo"; // { dg-warning "deprecated conversion from string constant" }
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
index e69de29..754a9c8 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
@@ -0,0 +1,6 @@
+// PR c++/79791
+// { dg-do compile { target { ! c++11 } } }
+// { dg-options "-Werror=write-strings" }
+// { dg-message "some warnings being treated as errors" "" { target *-*-* } 0 }
+
+char *s = "foo"; // { dg-error "deprecated conversion from string constant" }
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
index e69de29..53084d9 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
@@ -0,0 +1,5 @@
+// PR c++/79791
+// { dg-do compile { target c++11 } }
+// { dg-options "-pedantic-errors" }
+
+char *s = "foo"; // { dg-error "ISO C\\+\\+ forbids converting a string 
constant" }
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
index e69de29..6cb9654 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
@@ -0,0 +1,5 @@
+// PR c++/79791
+// { dg-do compile { target c++11 } }
+// { dg-options "-pedantic-errors -Wno-write-strings" }
+
+char *s = "foo";
diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-4.C 
gcc/testsuite/g++.dg/warn/Wwrite-strings-4.C
index e69de29..2654c39 100644
--- gcc/testsuite/g++.dg/warn/Wwrite-strings-4.C
+++ gcc/testsuite/g++.dg/warn/Wwrite-strings-4.C
@@ -0,0 +1,6 @@
+// PR c++/79791
+// { dg-do compile { target c++11 } }
+// { dg-options "-Werror=write-strings" }
+/

[PATCH, i386]: Fix PR79514, ICE with -m96bit-long-double on x86_64

[Uros Bizjak]

Hello!

Attached patch adds new insn_and_split pattern to handle pre_modify
XFmode push variant. -m96bit-long-double option sets XFmode size to 12
bytes that is not divisible with push size (8 bytes), resulting in
pre_modify push variant.

2017-03-02  Uros Bizjak  

PR target/79514
* config/i386/i386.md (*pushxf_rounded): New insn_and_split pattern.

testsuite/ChangeLog:

2017-03-02  Uros Bizjak  

PR target/79514
* gcc.target/i386/pr79514.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will be backported to release branches.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 245842)
+++ config/i386/i386.md (working copy)
@@ -3015,6 +3015,36 @@
   operands[0] = replace_equiv_address (operands[0], stack_pointer_rtx);
 })
 
+(define_insn_and_split "*pushxf_rounded"
+  [(set (mem:XF
+ (pre_modify:DI
+   (reg:DI SP_REG)
+   (plus:DI (reg:DI SP_REG) (const_int -16
+   (match_operand:XF 0 "nonmemory_no_elim_operand" "f,r,*r,C"))]
+  "TARGET_64BIT"
+  "#"
+  "&& 1"
+  [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -16)))
+   (set (match_dup 1) (match_dup 0))]
+{
+  rtx pat = PATTERN (curr_insn);
+  operands[1] = SET_DEST (pat);
+
+  /* Preserve memory attributes. */
+  operands[1] = replace_equiv_address (operands[1], stack_pointer_rtx);
+}
+  [(set_attr "type" "multi")
+   (set_attr "unit" "i387,*,*,*")
+   (set (attr "mode")
+   (cond [(eq_attr "alternative" "1,2,3")
+(const_string "DI")
+ ]
+ (const_string "XF")))
+   (set (attr "preferred_for_size")
+ (cond [(eq_attr "alternative" "1")
+  (symbol_ref "false")]
+   (symbol_ref "true")))])
+
 (define_insn "*pushxf"
   [(set (match_operand:XF 0 "push_operand" "=<,<,<,<")
(match_operand:XF 1 "general_no_elim_operand" "f,r,*r,oF"))]
Index: testsuite/gcc.target/i386/pr79514.c
===
--- testsuite/gcc.target/i386/pr79514.c (nonexistent)
+++ testsuite/gcc.target/i386/pr79514.c (working copy)
@@ -0,0 +1,12 @@
+/* PR target/79514 */
+/* { dg-do compile } */
+/* { dg-options "-m96bit-long-double" } */
+
+extern void bar (long double);
+
+extern long double x;
+
+void foo (void)
+{
+  bar (x);
+}

Re: [PATCH] PR libstdc++/79789 fix non-reserved names in headers

[Jonathan Wakely]

On 2 March 2017 at 05:25, Jonathan Wakely wrote:
> Some of these are years old, most are more recent. The new testcase
> should help prevent us trying to use these names again.
>
> PR libstdc++/79789
> * include/bits/hashtable_policy.h (__clp2): Use reserved names for
> parameters and local variables.
> * include/bits/ios_base.h (make_error_code, make_error_condition):
> Likewise.
> * include/bits/list.tcc (list::sort): Likewise.
> * include/bits/mask_array.h (mask_array): Likewise.
> * include/bits/regex.h (regex_token_iterator): Likewise.
> * include/bits/slice_array.h (slice_array): Likewise.
> * include/bits/stl_algo.h (__sample): Likewise.
> * include/std/memory (undeclare_no_pointers): Likewise.
> * include/std/type_traits (is_callable_v, is_nothrow_callable_v):
> Likewise.
> * libsupc++/exception_ptr.h (__dest_thunk): Likewise.
> * testsuite/17_intro/headers/names.cc: New test.

I meant to put this new test in 17_intro not 17_intro/headers, so I've moved it.

* testsuite/17_intro/headers/names.cc: Rename to ...
* testsuite/17_intro/names.cc: ... here.

> Tested powerpc64le-linux, committed to trunk.
>
> I'll backport pieces of this as appropriate to the branches.

Done.

[PATCH, rs6000, committed] Fix bootstrap failures for uninitialized memory

[Bill Schmidt]

Hi,

The expanded warnings for uninitialized memory caught a couple of
problems in the rs6000 back end, causing bootstrap to fail.  Some
of them were just introduced yesterday, while others are a bit
older.  These are just misnumbering of operands, skipping over
one and causing it to be uninitialized.  Bootstrapped and tested
on powerpc64le-unknown-linux-gnu, committed as obvious.

Thanks,
Bill


2017-03-02  Bill Schmidt  

* config/rs6000/vector.md (vector_ne__p): Correct operand
numbers.
(vector_ae__p): Likewise.
(vector_nez__p): Likewise.
(vector_ne_v2di_p): Likewise.
(vector_ae_v2di_p): Likewise.
(vector_ne__p): Likewise.
* config/rs6000/vsx.md (vsx_tsqrt2_fg): Correct operand
numbers.
(vsx_tsqrt2_fe): Likewise.


Index: gcc/config/rs6000/vector.md
===
--- gcc/config/rs6000/vector.md (revision 245843)
+++ gcc/config/rs6000/vector.md (working copy)
@@ -700,7 +700,7 @@
  (unspec:CC [(ne:CC (match_operand:VI 1 "vlogical_operand")
 (match_operand:VI 2 "vlogical_operand"))]
   UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (ne:VI (match_dup 1)
 (match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -708,7 +708,7 @@
   (const_int 0)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (mode);
+  operands[3] = gen_reg_rtx (mode);
 })
 
 ;; This expansion handles the V16QI, V8HI, and V4SI modes in the
@@ -719,7 +719,7 @@
  (unspec:CC [(ne:CC (match_operand:VI 1 "vlogical_operand")
 (match_operand:VI 2 "vlogical_operand"))]
   UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (ne:VI (match_dup 1)
 (match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -730,7 +730,7 @@
(const_int 1)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (mode);
+  operands[3] = gen_reg_rtx (mode);
 })
 
 ;; This expansion handles the V16QI, V8HI, and V4SI modes in the
@@ -763,7 +763,7 @@
  (unspec:CC [(eq:CC (match_operand:V2DI 1 "vlogical_operand")
 (match_operand:V2DI 2 "vlogical_operand"))]
 UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (eq:V2DI (match_dup 1)
   (match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -771,7 +771,7 @@
   (const_int 0)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (V2DImode);
+  operands[3] = gen_reg_rtx (V2DImode);
 })
 
 ;; This expansion handles the V2DI mode in the implementation of the
@@ -786,7 +786,7 @@
  (unspec:CC [(eq:CC (match_operand:V2DI 1 "vlogical_operand")
 (match_operand:V2DI 2 "vlogical_operand"))]
 UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (eq:V2DI (match_dup 1)
   (match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -797,7 +797,7 @@
(const_int 1)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (V2DImode);
+  operands[3] = gen_reg_rtx (V2DImode);
 })
 
 ;; This expansion handles the V4SF and V2DF modes in the Power9
@@ -811,7 +811,7 @@
  (unspec:CC [(eq:CC (match_operand:VEC_F 1 "vlogical_operand")
 (match_operand:VEC_F 2 "vlogical_operand"))]
 UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (eq:VEC_F (match_dup 1)
(match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -819,7 +819,7 @@
   (const_int 0)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (mode);
+  operands[3] = gen_reg_rtx (mode);
 })
 
 ;; This expansion handles the V4SF and V2DF modes in the Power9
@@ -833,7 +833,7 @@
  (unspec:CC [(eq:CC (match_operand:VEC_F 1 "vlogical_operand")
 (match_operand:VEC_F 2 "vlogical_operand"))]
 UNSPEC_PREDICATE))
- (set (match_dup 4)
+ (set (match_dup 3)
  (eq:VEC_F (match_dup 1)
(match_dup 2)))])
(set (match_operand:SI 0 "register_operand" "=r")
@@ -844,7 +844,7 @@
(const_int 1)))]
   "TARGET_P9_VECTOR"
 {
-  operands[4] = gen_reg_rtx (mode);
+  operands[3] = gen_reg_rtx (mode);
 })
 
 (define_expand "vector_gt__p"
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 245843)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1383,28 +1383,28 @@
 
 ;; *tsqrt* returning the fg flag
 (define_expand "vsx_tsqrt2_fg"
-  [(set (match_dup 3)
+  [(set (match_dup 2)
(unspec:CCFP [(match_operand:VSX_B 1 "vsx_register_operand" "")]
   

Re: [PATCH,rs6000] PR79395: Fix compile error with -mcpu=power9 and -mno-vsx and __builtin_vec_cmpne_p

[Bill Schmidt]

Fixed as r245849.  Thanks...

-- Bill

Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com

> On Mar 2, 2017, at 11:33 AM, Bill Schmidt  wrote:
> 
> Hi Andreas,
> 
> We discovered the problem this morning in-house and are working on a patch.
> 
> -- Bill
> 
> Bill Schmidt, Ph.D.
> GCC for Linux on Power
> Linux on Power Toolchain
> IBM Linux Technology Center
> wschm...@linux.vnet.ibm.com
> 
>> On Mar 2, 2017, at 11:25 AM, Andreas Schwab  wrote:
>> 
>> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>> 
>>UNSPEC_PREDICATE))
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ne_v8hi_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>UNSPEC_PREDICATE))
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ne_v16qi_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:721:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>UNSPEC_PREDICATE))
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v4si_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>> [(match_operand:VI 1 "vlogical_operand")
>> ^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v8hi_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>> [(match_operand:VI 1 "vlogical_operand")
>> ^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v16qi_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:743:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>> [(match_operand:VI 1 "vlogical_operand")
>> ^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ne_v2di_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:784:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>  [(parallel
>> ^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v2di_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:810:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>[(set (reg:CC CR6_REGNO)
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ne_v4sf_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>[(set (reg:CC CR6_REGNO)
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ne_v2df_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:832:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>[(set (reg:CC CR6_REGNO)
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v4sf_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>   (gt:VEC_A (match_dup 1)
>>~^
>> ../../gcc/config/rs6000/vector.md: In function 'rtx_def* 
>> gen_vector_ae_v2df_p(rtx, rtx, rtx)':
>> ../../gcc/config/rs6000/vector.md:857:14: error: 'operands[3]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>   (gt:VEC_A (match_dup 1)
>>~^
>> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
>> gen_vsx_tsqrtdf2_fg(rtx, rtx)':
>> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>   (set (match_operand:SI 0 "gpc_reg_operand" "")
>>~^
>> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
>> gen_vsx_tsqrtv4sf2_fg(rtx, rtx)':
>> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>   (set (match_operand:SI 0 "gpc_reg_operand" "")
>>~^
>> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
>> gen_vsx_tsqrtv2df2_fg(rtx, rtx)':
>> ../../gcc/config/rs6000/vsx.md:1402:14: error: 'operands[2]' is used 
>> uninitialized in this function [-Werror=uninitialized]
>>   (set (match_operand:SI 0 "gpc_reg_operand" "")
>>~^
>> ../../gcc/config/rs6000/vsx.md: In function 'rtx_def* 
>> gen_vsx_tsqrtdf2_fe(rtx,

Re: [PATCH] Fix rtl/x86_64 fails with -m32

[Uros Bizjak]

On Thu, Mar 2, 2017 at 10:10 AM, Richard Biener  wrote:
> On Thu, 2 Mar 2017, Uros Bizjak wrote:
>
>> > Annoying me for quite some time, fixed as follows.
>> >
>> > Tested on x86_64-unknown-linux-gnu, applied to trunk.
>>
>> Index: gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c
>> ===
>> --- gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (revision 245830)
>> +++ gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c (working copy)
>> @@ -1,4 +1,4 @@
>> -/* { dg-do run { target x86_64-*-* } } */
>> +/* { dg-do run { target { x86_64-*-* && lp64 } } } */
>>
>> All hese should be "{ target { { i?86-*-* x86_64-*-* } && { ! ia32 } }
>> }". x32 works OK with all test, modulo final.c where it ICEs for some
>> reason.
>
> AFAIK they were testcases with RTL generated for x86_64 lp64 so
> restricting to that is appropriate IMHO (do we really support
> -m64 on i?86-*-*?)
>
> But feel free to adjust them as you see fit - I was just annoyed
> by the persisting FAILs.

Adjusted by attached patch.

2017-03-02  Uros Bizjak  

* gcc.dg/rtl/x86_64/*.c: Test for
"{ i?86-*-* x86_64-*-* } && lp64" targets only.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros
Index: gcc.dg/rtl/x86_64/dfinit.c
===
--- gcc.dg/rtl/x86_64/dfinit.c  (revision 245843)
+++ gcc.dg/rtl/x86_64/dfinit.c  (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target { x86_64-*-* && lp64 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 /* { dg-options "-fdump-rtl-dfinit" } */
 
 #include "test_1.h"
Index: gcc.dg/rtl/x86_64/different-structs.c
===
--- gcc.dg/rtl/x86_64/different-structs.c   (revision 245843)
+++ gcc.dg/rtl/x86_64/different-structs.c   (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target x86_64-*-* } } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 
 extern double sqrt(double x);
 
Index: gcc.dg/rtl/x86_64/final.c
===
--- gcc.dg/rtl/x86_64/final.c   (revision 245843)
+++ gcc.dg/rtl/x86_64/final.c   (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { x86_64-*-* && lp64 } } } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 /* { dg-options "-fdump-rtl-final" } */
 
 /* Lightly-modified dump of test.c.304r.dwarf2 for x86_64 target,
Index: gcc.dg/rtl/x86_64/into-cfglayout.c
===
--- gcc.dg/rtl/x86_64/into-cfglayout.c  (revision 245843)
+++ gcc.dg/rtl/x86_64/into-cfglayout.c  (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target { x86_64-*-* && lp64 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 /* { dg-options "-fdump-rtl-into_cfglayout" } */
 
 /* Lightly-modified dump of test.c.226r.vregs for x86_64.  */
Index: gcc.dg/rtl/x86_64/ira.c
===
--- gcc.dg/rtl/x86_64/ira.c (revision 245843)
+++ gcc.dg/rtl/x86_64/ira.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target { x86_64-*-* && lp64 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 /* { dg-options "-fdump-rtl-ira" } */
 
 /* Lightly-modified dump of test.c.265r.asmcons for x86_64.  */
Index: gcc.dg/rtl/x86_64/pro_and_epilogue.c
===
--- gcc.dg/rtl/x86_64/pro_and_epilogue.c(revision 245843)
+++ gcc.dg/rtl/x86_64/pro_and_epilogue.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 /* { dg-options "-fdump-rtl-pro_and_epilogue" } */
 
 /* Lightly-modified dump of test.c.274r.split2 for x86_64.  */
Index: gcc.dg/rtl/x86_64/test-multiple-fns.c
===
--- gcc.dg/rtl/x86_64/test-multiple-fns.c   (revision 245843)
+++ gcc.dg/rtl/x86_64/test-multiple-fns.c   (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 
 /* Verify that we can have multiple __RTL functions in one test case.
Each of these __RTL functions returns a const, dumped immediately after
Index: gcc.dg/rtl/x86_64/test-return-const.c.after-expand.c
===
--- gcc.dg/rtl/x86_64/test-return-const.c.after-expand.c(revision 
245843)
+++ gcc.dg/rtl/x86_64/test-return-const.c.after-expand.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do run { target x86_64-*-* } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
 
 extern void abort (void);
 
Index: gcc.dg/rtl/x86_64/test-return-const.c.before-fwprop.c
===

Re: C PATCH to fix c/79758 (ICE-on-invalid with function redefinition and old style decls)

[Bernd Schmidt]

On 03/02/2017 06:35 PM, Marek Polacek wrote:

While at it, I fixed wrong formatting in the nearby code.  Also use NULL_TREE
instead of 0 where appropriate.  I really dislike those zeros-as-trees; one
day I'll just go and turn them into NULL_TREEs.


I sympathize, but it makes it harder to see which parts of the patch are 
actual changes. Generally it's best to separate functional and 
formatting changes.



@@ -8996,7 +8999,7 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
 declared for the arg.  ISO C says we take the unqualified
 type for parameters declared with qualified type.  */
  if (TREE_TYPE (parm) != error_mark_node
- && TREE_TYPE (type) != error_mark_node
+ && TREE_TYPE (TREE_VALUE (type)) != error_mark_node
  && ((TYPE_ATOMIC (DECL_ARG_TYPE (parm))
   != TYPE_ATOMIC (TREE_VALUE (type)))
  || !comptypes (TYPE_MAIN_VARIANT (DECL_ARG_TYPE (parm)),


Isn't this most likely intended to be TREE_VALUE (type) != error_mark_node?


@@ -9017,7 +9020,7 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
  if (targetm.calls.promote_prototypes (TREE_TYPE 
(current_function_decl))
  && INTEGRAL_TYPE_P (TREE_TYPE (parm))
  && TYPE_PRECISION (TREE_TYPE (parm))
- < TYPE_PRECISION (integer_type_node))
+< TYPE_PRECISION (integer_type_node))


Should add the necessary parens while fixing formatting.


Bernd

Re: GCSE: Use HOST_WIDE_INT instead of int (PR, rtl-optimization/79574).

[Bernd Schmidt]

On 03/02/2017 06:50 PM, Martin Liška wrote:

Hello.

This is second part of fixes needed to not trigger integer overflow in gcse 
pass.


So, how is this intended to work? The min/max stored in the param is an 
int, and by using a HOST_WIDE_INT here, we expect that it is a larger 
type and therefore won't overflow?



   {
expr = flat_table[i];
fprintf (file, "Index %d (hash value %d; max distance %d)\n  ",
-expr->bitmap_index, hash_val[i], expr->max_distance);
+expr->bitmap_index, hash_val[i], (int)expr->max_distance);
print_rtl (file, expr->expr);
fprintf (file, "\n");


Use HOST_WIDE_INT_PRINT_DEC maybe? Otherwise OK, I guess.


Bernd

New Danish PO file for 'gcc' (version 7.1-b20170226)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/da.po

(This file, 'gcc-7.1-b20170226.da.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

RE: [PATCH,testsuite] MIPS: Fix register mode checking for n64 in pr68273.c.

[Matthew Fortune]

Toma Tabacu  writes:
> pr68273.c currently fails when targeting MIPS64 with the n64 ABI.
> This is because it is checking for some registers in SImode, but, because of
> n64, they will actually be in DImode.
> 
> This patch restricts matching for SImode registers to ilp32 targets and adds
> matching for DImode registers for lp64 targets.
> This makes sure that the test is run on as many targets as possible, compared
> to the alternative of adding -mabi=32 to the test options.
> 
> I haven't checked to see what happens with eabi or o64, though.
> 
> Does this approach work ? Or should I just make separate tests for o32, n32 
> and
> n64, each one using -mabi=* as a test option to force an ABI ?

I'm happy with this approach.  As long as it works for o32/n32/n64 that is
sufficient right now.  If anyone starts to build and run the testsuite regularly
for default eabi/o64 then tests can be fixed which will involve much more than
just this one.

> Tested with mips-mti-elf.
> 
> Regards,
> Toma
> 
> gcc/testsuite/
> 
>   * gcc.target/mips/pr68273.c (dg-final): Match SImode registers only for
>   ilp32 targets and match DImode registers for lp64 targets.

OK, thanks.

Matthew

Re: [PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699)

[Martin Sebor]

On 03/02/2017 01:08 AM, Richard Biener wrote:

On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers  wrote:

On Wed, 1 Mar 2017, Martin Sebor wrote:


Joseph, since you commented on the bug, do you have a suggestion
for a different site for it or a guard?  The only other call to
the function is in the Fortran FE and it's neither guarded nor
does it appear to ever be called.


I don't think a guard is needed.  Arguably it should be called from an
atexit handler, but since we don't have such a handler calling it from the
relevant pass seems reasonable (and I'm not sure what the right way to
handle such freeing of memory in the JIT context is).


IMHO we should call it from gcc::~context


Thanks, that makes sense to me.  The attached patch does that.

Martin
PR tree-optimization/79699 - small memory leak in MPFR

gcc/ChangeLog:

	PR tree-optimization/79699
	* context.c (context::~context): Free MPFR caches to avoid
	a memory leak on program exit.

diff --git a/gcc/context.c b/gcc/context.c
index a7ded9c..d2009b9 100644
--- a/gcc/context.c
+++ b/gcc/context.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "context.h"
 #include "pass_manager.h"
 #include "dumpfile.h"
+#include "mpfr.h"
 
 /* The singleton holder of global state: */
 gcc::context *g;
@@ -42,4 +43,7 @@ gcc::context::~context ()
 {
   delete m_passes;
   delete m_dumps;
+
+  /* Release MPFR caches to avoid Valgrind leak reports.  */
+  mpfr_free_cache ();
 }

[PATCH] Fix IFN_ATOMIC* handling with -fnon-call-exceptions (PR middle-end/79805)

[Jakub Jelinek]

Hi!

The __atomic/__sync builtins have nothrow conditional on
-fnon-call-exceptions, but internal fns have right now only constant flags.
As per discussions on IRC, this patch removes ECF_NOTHROW from those 4 ifns
and instead calls gimple_call_set_nothrow when creating those to say
if it can or can't throw.  Furthermore, if we need to add statements after
the former builtin, now ifn with -fnon-call-exceptions, we need to insert
them on the fallthru edge instead of right after it.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-03-02  Jakub Jelinek  

PR middle-end/79805
* internal-fn.def (ATOMIC_BIT_TEST_AND_SET, ATOMIC_BIT_TEST_AND_RESET,
ATOMIC_BIT_TEST_AND_COMPLEMENT, ATOMIC_COMPARE_EXCHANGE): Remove
ECF_NOTHROW.
* gimple-fold.c (fold_builtin_atomic_compare_exchange): Set
gimple_call_nothrow_p flag based on flag_non_call_exceptions.  For
-fnon-call-exceptions emit following stmts on the fallthrough edge.
(optimize_atomic_bit_test_and): Similarly, except don't create new
bb if inserting just debug stmts on the edge, try to insert them
on the fallthru bb or just reset debug stmts.

* g++.dg/opt/pr79805.C: New test.

--- gcc/internal-fn.def.jj  2017-02-09 14:55:38.0 +0100
+++ gcc/internal-fn.def 2017-03-02 13:14:43.659419232 +0100
@@ -205,11 +205,13 @@ DEF_INTERNAL_FN (GOACC_TILE, ECF_NOTHROW
current target.  */
 DEF_INTERNAL_FN (SET_EDOM, ECF_LEAF | ECF_NOTHROW, NULL)
 
-/* Atomic functions.  */
-DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_SET, ECF_LEAF | ECF_NOTHROW, NULL)
-DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_COMPLEMENT, ECF_LEAF | ECF_NOTHROW, NULL)
-DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_RESET, ECF_LEAF | ECF_NOTHROW, NULL)
-DEF_INTERNAL_FN (ATOMIC_COMPARE_EXCHANGE, ECF_LEAF | ECF_NOTHROW, NULL)
+/* Atomic functions.  These don't have ECF_NOTHROW because for
+   -fnon-call-exceptions they can throw, otherwise we set
+   gimple_call_nothrow_p on it.  */
+DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_SET, ECF_LEAF, NULL)
+DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_COMPLEMENT, ECF_LEAF, NULL)
+DEF_INTERNAL_FN (ATOMIC_BIT_TEST_AND_RESET, ECF_LEAF, NULL)
+DEF_INTERNAL_FN (ATOMIC_COMPARE_EXCHANGE, ECF_LEAF, NULL)
 
 /* To implement [[fallthrough]].  */
 DEF_INTERNAL_FN (FALLTHROUGH, ECF_LEAF | ECF_NOTHROW, NULL)
--- gcc/gimple-fold.c.jj2017-02-07 16:40:45.0 +0100
+++ gcc/gimple-fold.c   2017-03-02 16:04:51.304850077 +0100
@@ -3533,6 +3533,8 @@ fold_builtin_atomic_compare_exchange (gi
   tree itype = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (parmt)));
   tree ctype = build_complex_type (itype);
   tree expected = TREE_OPERAND (gimple_call_arg (stmt, 1), 0);
+  bool may_throw = false;
+  edge e = NULL;
   gimple *g = gimple_build_assign (make_ssa_name (TREE_TYPE (expected)),
   expected);
   gsi_insert_before (gsi, g, GSI_SAME_STMT);
@@ -3558,19 +3560,43 @@ fold_builtin_atomic_compare_exchange (gi
   gimple_set_vdef (g, gimple_vdef (stmt));
   gimple_set_vuse (g, gimple_vuse (stmt));
   SSA_NAME_DEF_STMT (gimple_vdef (g)) = g;
-  if (gimple_call_lhs (stmt))
+  tree oldlhs = gimple_call_lhs (stmt);
+  if (flag_non_call_exceptions && stmt_ends_bb_p (stmt))
 {
-  gsi_insert_before (gsi, g, GSI_SAME_STMT);
+  may_throw = true;
+  gimple_call_set_lhs (stmt, NULL_TREE);
+  gsi_replace (gsi, g, true);
+  e = find_fallthru_edge (gsi_bb (*gsi)->succs);
+}
+  gimple_call_set_nothrow (as_a  (g), flag_non_call_exceptions == 0);
+  if (oldlhs)
+{
+  if (!may_throw)
+   gsi_insert_before (gsi, g, GSI_SAME_STMT);
   g = gimple_build_assign (make_ssa_name (itype), IMAGPART_EXPR,
   build1 (IMAGPART_EXPR, itype, lhs));
-  gsi_insert_before (gsi, g, GSI_SAME_STMT);
-  g = gimple_build_assign (gimple_call_lhs (stmt), NOP_EXPR,
-  gimple_assign_lhs (g));
+  if (may_throw)
+   {
+ gsi_insert_on_edge_immediate (e, g);
+ *gsi = gsi_for_stmt (g);
+   }
+  else
+   gsi_insert_before (gsi, g, GSI_SAME_STMT);
+  g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g));
+  if (may_throw)
+   gsi_insert_after (gsi, g, GSI_NEW_STMT);
 }
-  gsi_replace (gsi, g, true);
+  if (!may_throw)
+gsi_replace (gsi, g, true);
   g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR,
   build1 (REALPART_EXPR, itype, lhs));
-  gsi_insert_after (gsi, g, GSI_NEW_STMT);
+  if (may_throw && oldlhs == NULL_TREE)
+{
+  gsi_insert_on_edge_immediate (e, g);
+  *gsi = gsi_for_stmt (g);
+}
+  else
+gsi_insert_after (gsi, g, GSI_NEW_STMT);
   if (!useless_type_conversion_p (TREE_TYPE (expected), itype))
 {
   g = gimple_build_assign (make_ssa_name (TREE_TYPE (expected)),
--- gcc/tree-ssa-ccp.c.jj   2017-01-01 12:45:37.0 +0100
+++ gcc/tree-ssa-ccp.c  2017-03-02 15:59:04.392422

Re: [PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699)

[Andrew Pinski]

On Thu, Mar 2, 2017 at 1:33 PM, Martin Sebor  wrote:
> On 03/02/2017 01:08 AM, Richard Biener wrote:
>>
>> On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers 
>> wrote:
>>>
>>> On Wed, 1 Mar 2017, Martin Sebor wrote:
>>>
 Joseph, since you commented on the bug, do you have a suggestion
 for a different site for it or a guard?  The only other call to
 the function is in the Fortran FE and it's neither guarded nor
 does it appear to ever be called.
>>>
>>>
>>> I don't think a guard is needed.  Arguably it should be called from an
>>> atexit handler, but since we don't have such a handler calling it from
>>> the
>>> relevant pass seems reasonable (and I'm not sure what the right way to
>>> handle such freeing of memory in the JIT context is).
>>
>>
>> IMHO we should call it from gcc::~context
>
>
> Thanks, that makes sense to me.  The attached patch does that.

Is this function call thread safe?  Or rather is MPFR thread safe?
I am thinking of the case where there are two gcc::context around one
running in each thread.  I am not saying this is the current behavior
but I do know there was talk about making GCC thread safe before and I
want to make sure we understand that this might cause issues in that
goal.

Thanks,
Andrew

>
> Martin

[PATCH] Fix -O0 -ffloat-store -mavx ICE (PR target/79807)

[Jakub Jelinek]

Hi!

For -O1 and above, we force all operands and targets of x86 builtins into
registers during expansion, because we expect combiner will do its job.
But for -O0, we try to keep them in MEM if the predicate allows it, we just
make sure that at most one input operand is a MEM.  We still allow
MEM destination and one MEM input operand, which is why we ICE - most
insns/expanders don't allow that in the predicates and it is fine, but
various insns/expanders have e.g. nonimmediate_operand on both target
and some input operand and just have a condition that requires that one
of those is a register or that both of them are not memory.  The expanders
don't check the condition though, it is checked only when the insn is being
recognized in vregs pass and that is too late.
The following patch fixes that by forcing all input operands at -O0 into
non-memory if the target is memory.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Or are there any define_insn/define_expand where it is desirable to have
both input and output operand a MEM (and does it have to be matching)?
For various scalar binary and unary expanders the backend already uses a helper
that will force something into memory if dest and src are both memory and
not rtx_equal_p, but do we have anything like that in anything these two
builtin expanders emit?

2017-03-02  Jakub Jelinek  

PR target/79807
* config/i386/i386.c (ix86_expand_multi_arg_builtin): If target
is a memory operand, increase num_memory.
(ix86_expand_args_builtin): Likewise.

* gcc.target/i386/pr79807.c: New test.

--- gcc/config/i386/i386.c.jj   2017-03-02 08:08:43.0 +0100
+++ gcc/config/i386/i386.c  2017-03-02 17:58:28.396999033 +0100
@@ -34249,6 +34249,8 @@ ix86_expand_multi_arg_builtin (enum insn
   || GET_MODE (target) != tmode
   || !insn_data[icode].operand[0].predicate (target, tmode))
 target = gen_reg_rtx (tmode);
+  else if (memory_operand (target, tmode))
+num_memory++;
 
   gcc_assert (nargs <= 4);
 
@@ -35534,6 +35536,8 @@ ix86_expand_args_builtin (const struct b
  || GET_MODE (target) != tmode
  || !insn_p->operand[0].predicate (target, tmode))
target = gen_reg_rtx (tmode);
+  else if (memory_operand (target, tmode))
+   num_memory++;
   real_target = target;
 }
   else
--- gcc/testsuite/gcc.target/i386/pr79807.c.jj  2017-03-02 18:03:30.032023436 
+0100
+++ gcc/testsuite/gcc.target/i386/pr79807.c 2017-03-02 18:02:53.0 
+0100
@@ -0,0 +1,12 @@
+/* PR target/79807 */
+/* { dg-do compile } */
+/* { dg-options "-O0 -mavx -ffloat-store" } */
+
+typedef double __v2df __attribute__ ((__vector_size__ (16)));
+typedef double __v4df __attribute__ ((__vector_size__ (32)));
+
+__v2df
+foo (__v4df x)
+{
+  return __builtin_ia32_pd_pd256 (x);
+}

Jakub

Re: [PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699)

[Martin Sebor]

On 03/02/2017 02:40 PM, Andrew Pinski wrote:

On Thu, Mar 2, 2017 at 1:33 PM, Martin Sebor  wrote:

On 03/02/2017 01:08 AM, Richard Biener wrote:


On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers 
wrote:


On Wed, 1 Mar 2017, Martin Sebor wrote:


Joseph, since you commented on the bug, do you have a suggestion
for a different site for it or a guard?  The only other call to
the function is in the Fortran FE and it's neither guarded nor
does it appear to ever be called.



I don't think a guard is needed.  Arguably it should be called from an
atexit handler, but since we don't have such a handler calling it from
the
relevant pass seems reasonable (and I'm not sure what the right way to
handle such freeing of memory in the JIT context is).



IMHO we should call it from gcc::~context



Thanks, that makes sense to me.  The attached patch does that.


Is this function call thread safe?  Or rather is MPFR thread safe?
I am thinking of the case where there are two gcc::context around one
running in each thread.  I am not saying this is the current behavior
but I do know there was talk about making GCC thread safe before and I
want to make sure we understand that this might cause issues in that
goal.


The latest MPFR manual implies the function is thread safe if
MPFR itself has been built as thread safe:

  http://www.mpfr.org/mpfr-current/mpfr.html#Memory-Handling-1

Similar text is in the MPFR 2.4 manual (and so is mpfr_free_cache)
so it should be safe to call the function even with older versions
of the library.

Martin

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Jakub Jelinek]

Hi!

On Wed, Mar 01, 2017 at 08:26:36PM +0100, Uros Bizjak wrote:
> 2017-03-01  Uros Bizjak  
> 
> * config/i386/i386.c (print_reg): Warn for values of
> unsupported size in integer register.
> 
> testsuite/ChangeLog:
> 
> 2017-03-01  Uros Bizjak  
> 
> * gcc.target/i386/invsize-2.c: New test.
> * gcc.target/i386/invsize-3.c: Ditto.
> * gcc.target/i386/invsize-4.c: Ditto.
> * gcc.target/i386/pr66274.c: Expect "unsuported size" warning.
> * gcc.target/i386/stackalign/asm-1.c: Ditto.
> 
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

This broke
FAIL: gcc.dg/pr57134.c (test for excess errors)
on i686-linux, the warning triggers there.

It seems "# %0 %1" actually isn't needed for reproduction of the original
bug (tried powerpc64-linux cross at r20 where it ICEs even with ""
and succeeds at r204000), so is this ok for trunk?

Other option is to add { dg-final { dg-warning "..." { target ia32 } } }
but that really doesn't scale to other targets, or -w.

2017-03-02  Jakub Jelinek  

* gcc.dg/pr57134.c: Use empty inline asm string literal.

--- gcc/testsuite/gcc.dg/pr57134.c.jj   2013-06-19 19:28:33.0 +0200
+++ gcc/testsuite/gcc.dg/pr57134.c  2017-03-02 23:24:40.329317713 +0100
@@ -18,7 +18,7 @@ static __inline__ __attribute__((always_
 atomic64_read(const atomic64_t *v)
 {
  int64_t t;
- __asm__ __volatile__("# %0, %1" : "=r"(t) : "m"(v->counter));
+ __asm__ __volatile__("" : "=r"(t) : "m"(v->counter));
  return t;
 }
 


Jakub

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Martin Sebor]

On 03/02/2017 12:58 AM, Richard Biener wrote:

On Wed, 1 Mar 2017, Martin Sebor wrote:


On 02/28/2017 11:41 PM, Richard Biener wrote:

On March 1, 2017 3:34:46 AM GMT+01:00, Martin Sebor 
wrote:

On 02/28/2017 01:41 PM, Richard Biener wrote:

On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law 

wrote:

On 02/28/2017 10:54 AM, Martin Sebor wrote:

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide

when

to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.


OK.

WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm
not
sure if that's documented anywhere though.


Actually the only criteria is zero P1 regressions.  Those are

documented to block a release.

Yes, that is mentioned in the document.  Would it be fair to say
that the number of P2 bugs (or regressions) or their nature plays
into the decision in some way as well?  If so, what can the release
criteria say about it?


Ultimatively P2 bugs do not play a role and 'time' will trump them.  OTOH we
never were in an uncomfortable situation with P2s at the desired point of
release.

Also note that important P2 bugs can be promoted to P1 and not important P1
to P2.


I'm trying to get a better idea which bugs to work on and where
my help might have the biggest impact.  I think having better
visibility into the bug triage process (such as bug priorities
and how they impact the release schedule) might help others
focus too.


In order of importance:
- P1
- wrong-code, rejects-valid, ice-on-valid (even if not regressions,
regressions more important)
- P2 regressions, more recent ones first (newest working version)


I see.  This is helpful, thanks.

The kinds of problems you mention are discussed in the document
so just to make the importance clear, would adding the following
after this sentence

  In general bugs blocking the release are marked with priority P1
  (Maintaining the GCC Bugzilla database).

accurately reflect what you described?

  As a general rule of thumb, within each priority level, bugs that
  result in incorrect code are considered more urgent than those
  that lead to rejecting valid code, which in turn are viewed as
  more severe than ice-on-valid code (compiler crashes).  More
  recently reported bugs are also prioritized over very old ones.


I'd rather see to clarify things in bugs/management.html.  Note
that wrong-code, rejects-valid, ice-on-valid are equally important.
Less important would be accepts-invalid or ice-on-invalid or, of course,
missed-optimization.  Also it's not more recently _reported_  bugs
but a [6/7 Regression] is more important to fix than a [5/6/7 Regression]
(this is also why [7 Regression]s are P1 by default).


Got it.  Attached is a rewording of the paragraph above added to
bugs/management.html.  I put it under the Importance (Severity
and Priority) heading but it could probably fit just as well under
Procedures and Policies.

Please let me know if there's anything else that can be said to
further clarify things, or if you have any other suggestions.

Martin
Index: management.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.31
diff -u -r1.31 management.html
--- management.html	29 Jun 2014 11:31:33 -	1.31
+++ management.html	2 Mar 2017 22:35:00 -
@@ -56,6 +56,8 @@
 Bugzilla offers a number of different fields.  From a maintainer's
 perspective, these are the relevant ones and what their values mean:
 
+Status
+
 The status and resolution fields define and track the life cycle of a
 bug.  In addition to their https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html";>regular
@@ -77,9 +79,10 @@
 
 
 
+Importance (Severity and Priority)
 
 The following two fields describe how serious a bug is from a user's
-perspective (severity) and which priority we assign to it in fixing it:
+perspective (Severity) and what Priority we assign to it in fixing it:
 
 
 
@@ -140,6 +143,18 @@
 
 
 
+As a general rule of thumb, within each priority level, bugs that result
+in incorrect code (keyword wrong-code) are considered equally as important
+to fix as those that lead to rejecting valid code (rejects-valid) and as
+those that cause an ICE for valid code (ice-on-valid-code).  Lower in
+importance, however, are accepts-invalid and ice-on-invalid bugs,
+and less important still are missed-optimization opportunities.
+
+Regressions that only affect more recent releases are prioritized over those
+that also affect older releases.  For example, prior to the relea

Re: C++ PATCH for C++17 class template argument deduction issues

[Jason Merrill]

On Wed, Mar 1, 2017 at 3:58 PM, Jason Merrill  wrote:
> On Tue, Feb 28, 2017 at 1:56 PM, Jason Merrill  wrote:
>> This patch implements some proposed resolutions to open issues with
>> C++17 class template argument deduction.
>
> And some more:

This patch handles the issues of references to members of the class
template differently, by also allowing explicit guides to refer to
them:
commit d32c5f542b7bfe825149fc134b8c5348061f0bfb
Author: Jason Merrill 
Date:   Thu Mar 2 13:20:27 2017 -1000

Allow deduction guides to look into primary template.

* cp-tree.h (struct saved_scope): Add deduction_guide_type.
(struct cp_decl_specifier_seq): Add constructor_p.
* parser.c (cp_parser_decl_specifier_seq): Set constructor_p.
(cp_parser_init_declarator): Check it.  Set ctor_dtor_or_conv_p.
Clear deduction_guide_type.  Don't handle deduction guide names.
(cp_parser_declarator): Don't clear ctor_dtor_or_conv_p.
(cp_parser_direct_declarator): Likewise.  Handle deduction guides.
(cp_parser_member_declaration, cp_parser_cache_defarg)
(cp_parser_objc_class_ivars): Set ctor_dtor_or_conv_p.
* pt.c (tsubst_copy, tsubst_copy_and_build): Revert last change.
(build_deduction_guide): Set deduction_guide_type.
(dependent_scope_p): Check deduction_guide_type.
* search.c (lookup_member): Likewise.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f53f744..31edc5f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1272,6 +1272,7 @@ struct GTY(()) saved_scope {
   vec *lang_base;
   tree lang_name;
   tree template_parms;
+  tree deduction_guide_type;
   cp_binding_level *x_previous_class_level;
   tree x_saved_tree;
 
@@ -5422,6 +5423,9 @@ struct cp_decl_specifier_seq {
   BOOL_BITFIELD gnu_thread_keyword_p : 1;
   /* True iff the type is a decltype.  */
   BOOL_BITFIELD decltype_p : 1;
+  /* True iff the declaration declares a constructor or C++17 deduction
+ guide.  */
+  BOOL_BITFIELD constructor_p : 1;
 };
 
 /* The various kinds of declarators.  */
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e684870..fbe864f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13313,6 +13313,8 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
   && constructor_possible_p
   && (cp_parser_constructor_declarator_p
   (parser, decl_spec_seq_has_spec_p (decl_specs, ds_friend;
+  if (constructor_p)
+   decl_specs->constructor_p = true;
 
   /* If we don't have a DECL_SPEC yet, then we must be looking at
 a type-specifier.  */
@@ -19010,7 +19012,7 @@ cp_parser_init_declarator (cp_parser* parser,
   enum cpp_ttype initialization_kind;
   bool is_direct_init = false;
   bool is_non_constant_init;
-  int ctor_dtor_or_conv_p;
+  int ctor_dtor_or_conv_p = decl_specifiers->constructor_p ? -1 : 0;
   bool friend_p = cp_parser_friend_p (decl_specifiers);
   tree pushed_scope = NULL_TREE;
   bool range_for_decl_p = false;
@@ -19048,6 +19050,9 @@ cp_parser_init_declarator (cp_parser* parser,
 
   parser->default_arg_ok_p = saved_default_arg_ok_p;
 
+  if (cxx_dialect >= cxx1z)
+scope_chain->deduction_guide_type = NULL_TREE;
+
   /* If the DECLARATOR was erroneous, there's no need to go
  further.  */
   if (declarator == cp_error_declarator)
@@ -19095,25 +19100,6 @@ cp_parser_init_declarator (cp_parser* parser,
 
   if (function_declarator_p (declarator))
 {
-  /* Handle C++17 deduction guides.  */
-  if (!decl_specifiers->type
- && ctor_dtor_or_conv_p <= 0
- && cxx_dialect >= cxx1z)
-   {
- cp_declarator *id = get_id_declarator (declarator);
- tree name = id->u.id.unqualified_name;
- parser->scope = id->u.id.qualifying_scope;
- tree tmpl = cp_parser_lookup_name_simple (parser, name, id->id_loc);
- if (tmpl
- && (DECL_CLASS_TEMPLATE_P (tmpl)
- || DECL_TEMPLATE_TEMPLATE_PARM_P (tmpl)))
-   {
- id->u.id.unqualified_name = dguide_name (tmpl);
- id->u.id.sfk = sfk_deduction_guide;
- ctor_dtor_or_conv_p = 1;
-   }
-   }
-
   /* Check to see if the token indicates the start of a
 function-definition.  */
   if (cp_parser_token_starts_function_definition_p (token))
@@ -19432,8 +19418,10 @@ cp_parser_init_declarator (cp_parser* parser,
 
If CTOR_DTOR_OR_CONV_P is not NULL, *CTOR_DTOR_OR_CONV_P is used to
detect constructors, destructors, deduction guides, or conversion operators.
-   It is set to -1 if the declarator is a name, and +1 if it is a
-   function. Otherwise it is set to zero. Usually you just want to
+   The caller should set it before the call, to -1 if parsing the
+   decl-specifier-seq determined that we're declaring a constructor or
+   deduction guide, or 0 otherwise.  This function sets it to -1 if the
+   declarator i

Re: C++ PATCH to fix -Wpedantic -Werror=write-strings behavior (PR c++/79791)

[Jason Merrill]

OK.

On Thu, Mar 2, 2017 at 8:31 AM, Marek Polacek  wrote:
> This PR complains that the -Wpedantic -Werror=write-strings combination 
> doesn't
> result in an error but in a pedwarn, which I think is a valid point.  The
> principle is that more specific options take precedence over less specific
> options, so e.g. -Wpedantic -Wno-write-strings shouldn't give a 
> -Wwrite-strings
> warning.  -Wwrite-strings is enabled by default for C++:
> c-family/c-opts.c:205:  opts->x_warn_write_strings = c_dialect_cxx ();
> so I think the following patch fixes the problem; the warning will only ever 
> be
> disabled if the user specifies -Wno-write-strings, and in C++11 it will always
> be a pedwarn, so -pedantic-errors works as expected.  I added a bunch of tests
> to further exercise other combinations, too.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2017-03-02  Marek Polacek  
>
> PR c++/79791
> * typeck.c (string_conv_p): In C++11, always call pedwarn with
> OPT_Wwrite_strings.
>
> * g++.dg/warn/Wwrite-strings-1.C: New test.
> * g++.dg/warn/Wwrite-strings-2.C: New test.
> * g++.dg/warn/Wwrite-strings-3.C: New test.
> * g++.dg/warn/Wwrite-strings-4.C: New test.
> * g++.dg/warn/Wwrite-strings-5.C: New test.
> * g++.dg/warn/Wwrite-strings-6.C: New test.
> * g++.dg/warn/Wwrite-strings-7.C: New test.
> * g++.dg/warn/Wwrite-strings-8.C: New test.
> * g++.dg/warn/Wwrite-strings-9.C: New test.
> * g++.dg/warn/Wwrite-strings-10.C: New test.
> * g++.dg/warn/Wwrite-strings-11.C: New test.
> * g++.dg/warn/Wwrite-strings-12.C: New test.
>
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> index 3216bc41..d24 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -2175,8 +2175,7 @@ string_conv_p (const_tree totype, const_tree exp, int 
> warn)
>if (warn)
>  {
>if (cxx_dialect >= cxx11)
> -   pedwarn (input_location,
> -pedantic ? OPT_Wpedantic : OPT_Wwrite_strings,
> +   pedwarn (input_location, OPT_Wwrite_strings,
>  "ISO C++ forbids converting a string constant to %qT",
>  totype);
>else
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
> index e69de29..05abca3 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C
> @@ -0,0 +1,5 @@
> +// PR c++/79791
> +// { dg-do compile { target c++11 } }
> +// { dg-options "" }
> +
> +char *s = "foo"; // { dg-warning "ISO C\\+\\+ forbids converting a string 
> constant" }
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
> index e69de29..d34b0b0 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C
> @@ -0,0 +1,5 @@
> +// PR c++/79791
> +// { dg-do compile { target { ! c++11 } } }
> +// { dg-options "" }
> +
> +char *s = "foo"; // { dg-warning "deprecated conversion from string 
> constant" }
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
> index e69de29..11ddcdb 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C
> @@ -0,0 +1,5 @@
> +// PR c++/79791
> +// { dg-do compile { target { ! c++11 } } }
> +// { dg-options "-pedantic-errors" }
> +
> +char *s = "foo"; // { dg-warning "deprecated conversion from string 
> constant" }
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
> index e69de29..754a9c8 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C
> @@ -0,0 +1,6 @@
> +// PR c++/79791
> +// { dg-do compile { target { ! c++11 } } }
> +// { dg-options "-Werror=write-strings" }
> +// { dg-message "some warnings being treated as errors" "" { target *-*-* } 
> 0 }
> +
> +char *s = "foo"; // { dg-error "deprecated conversion from string constant" }
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
> index e69de29..53084d9 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C
> @@ -0,0 +1,5 @@
> +// PR c++/79791
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-pedantic-errors" }
> +
> +char *s = "foo"; // { dg-error "ISO C\\+\\+ forbids converting a string 
> constant" }
> diff --git gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C 
> gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
> index e69de29..6cb9654 100644
> --- gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
> +++ gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C
> @@ -0,0 +1,5 @@
> +// PR c++/79791
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-pedantic-errors -Wno-write-strings" }
> +
> +char *s = "foo";
> diff --git gcc/testsuite/g++.dg/warn/Wwri

Re: C++ PATCH for C++17 class template argument deduction issues

[Jason Merrill]

On Thu, Mar 2, 2017 at 3:26 PM, Jason Merrill  wrote:
> On Wed, Mar 1, 2017 at 3:58 PM, Jason Merrill  wrote:
>> On Tue, Feb 28, 2017 at 1:56 PM, Jason Merrill  wrote:
>>> This patch implements some proposed resolutions to open issues with
>>> C++17 class template argument deduction.
>>
>> And some more:
>
> This patch handles the issues of references to members of the class
> template differently, by also allowing explicit guides to refer to
> them:

This patch adjusts some overload resolution.
commit a777aadaf635dc1ef460c5e12d2ead4292eaa6a9
Author: Jason Merrill 
Date:   Wed Mar 1 16:11:26 2017 -1000

Update overload resolution with deduction guides.

* pt.c (do_class_deduction): Always build the copy guide.
(copy_guide_p, template_guide_p): New.
(build_deduction_guide): Remember the original constructor.
* call.c (joust): Prefer the copy guide and non-template guides.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index babab00..dc629b96 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -9717,6 +9717,22 @@ joust (struct z_candidate *cand1, struct z_candidate 
*cand2, bool warn,
   int art2 = DECL_ARTIFICIAL (cand2->fn);
   if (art1 != art2)
return art2 - art1;
+
+  if (art1)
+   {
+ /* Prefer the special copy guide over a declared copy/move
+constructor.  */
+ if (copy_guide_p (cand1->fn))
+   return 1;
+ if (copy_guide_p (cand2->fn))
+   return -1;
+
+ /* Prefer a candidate generated from a non-template constructor.  */
+ int tg1 = template_guide_p (cand1->fn);
+ int tg2 = template_guide_p (cand2->fn);
+ if (tg1 != tg2)
+   return tg2 - tg1;
+   }
 }
 
   /* or, if not that, F2 is from a using-declaration, F1 is not, and the
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 31edc5f..7583672 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6288,6 +6288,8 @@ extern tree template_parm_to_arg(tree);
 extern tree dguide_name(tree);
 extern bool dguide_name_p  (tree);
 extern bool deduction_guide_p  (const_tree);
+extern bool copy_guide_p   (const_tree);
+extern bool template_guide_p   (const_tree);
 
 /* in repo.c */
 extern void init_repo  (void);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3b320fc..13293eb 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -24852,6 +24852,35 @@ deduction_guide_p (const_tree fn)
   return false;
 }
 
+/* True if FN is the copy deduction guide, i.e. A(A)->A.  */
+
+bool
+copy_guide_p (const_tree fn)
+{
+  gcc_assert (deduction_guide_p (fn));
+  if (!DECL_ARTIFICIAL (fn))
+return false;
+  tree parms = FUNCTION_FIRST_USER_PARMTYPE (DECL_TI_TEMPLATE (fn));
+  return (TREE_CHAIN (parms) == void_list_node
+ && same_type_p (TREE_VALUE (parms), TREE_TYPE (DECL_NAME (fn;
+}
+
+/* True if FN is a guide generated from a constructor template.  */
+
+bool
+template_guide_p (const_tree fn)
+{
+  gcc_assert (deduction_guide_p (fn));
+  if (!DECL_ARTIFICIAL (fn))
+return false;
+  if (tree ctor = DECL_ABSTRACT_ORIGIN (fn))
+{
+  tree tmpl = DECL_TI_TEMPLATE (ctor);
+  return PRIMARY_TEMPLATE_P (tmpl);
+}
+  return false;
+}
+
 /* OLDDECL is a _DECL for a template parameter.  Return a similar parameter at
LEVEL:INDEX, using tsubst_args and complain for substitution into non-type
template parameter types.  Note that the handling of template template
@@ -25100,6 +25129,8 @@ build_deduction_guide (tree ctor, tree outer_args, 
tsubst_flags_t complain)
   TREE_TYPE (ded_tmpl) = TREE_TYPE (ded_fn);
   DECL_TEMPLATE_INFO (ded_fn) = build_template_info (ded_tmpl, targs);
   DECL_PRIMARY_TEMPLATE (ded_tmpl) = ded_tmpl;
+  if (DECL_P (ctor))
+DECL_ABSTRACT_ORIGIN (ded_fn) = ctor;
   if (ci)
 set_constraints (ded_tmpl, ci);
 
@@ -25153,7 +25184,6 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
 }
 
   bool saw_ctor = false;
-  bool saw_copy = false;
   if (CLASSTYPE_METHOD_VEC (type))
 // FIXME cache artificial deduction guides
 for (tree fns = CLASSTYPE_CONSTRUCTORS (type); fns; fns = OVL_NEXT (fns))
@@ -25163,16 +25193,6 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
cands = ovl_cons (guide, cands);
 
saw_ctor = true;
-
-   tree parms = FUNCTION_FIRST_USER_PARMTYPE (fn);
-   if (parms && sufficient_parms_p (TREE_CHAIN (parms)))
- {
-   tree pt = TREE_VALUE (parms);
-   if (TREE_CODE (pt) == REFERENCE_TYPE
-   && (same_type_ignoring_top_level_qualifiers_p
-   (TREE_TYPE (pt), type)))
- saw_copy = true;
- }
   }
 
   if (!saw_ctor && args->length() == 0)
@@ -25180,7 +25200,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
   tree guide = bu

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Uros Bizjak]

On Thu, Mar 2, 2017 at 11:31 PM, Jakub Jelinek  wrote:
> Hi!
>
> On Wed, Mar 01, 2017 at 08:26:36PM +0100, Uros Bizjak wrote:
>> 2017-03-01  Uros Bizjak  
>>
>> * config/i386/i386.c (print_reg): Warn for values of
>> unsupported size in integer register.
>>
>> testsuite/ChangeLog:
>>
>> 2017-03-01  Uros Bizjak  
>>
>> * gcc.target/i386/invsize-2.c: New test.
>> * gcc.target/i386/invsize-3.c: Ditto.
>> * gcc.target/i386/invsize-4.c: Ditto.
>> * gcc.target/i386/pr66274.c: Expect "unsuported size" warning.
>> * gcc.target/i386/stackalign/asm-1.c: Ditto.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> This broke
> FAIL: gcc.dg/pr57134.c (test for excess errors)
> on i686-linux, the warning triggers there.
>
> It seems "# %0 %1" actually isn't needed for reproduction of the original
> bug (tried powerpc64-linux cross at r20 where it ICEs even with ""
> and succeeds at r204000), so is this ok for trunk?
>
> Other option is to add { dg-final { dg-warning "..." { target ia32 } } }
> but that really doesn't scale to other targets, or -w.
>
> 2017-03-02  Jakub Jelinek  
>
> * gcc.dg/pr57134.c: Use empty inline asm string literal.

Looks obvious to me, and just the case we want to catch on x86_32.

Uros.

> --- gcc/testsuite/gcc.dg/pr57134.c.jj   2013-06-19 19:28:33.0 +0200
> +++ gcc/testsuite/gcc.dg/pr57134.c  2017-03-02 23:24:40.329317713 +0100
> @@ -18,7 +18,7 @@ static __inline__ __attribute__((always_
>  atomic64_read(const atomic64_t *v)
>  {
>   int64_t t;
> - __asm__ __volatile__("# %0, %1" : "=r"(t) : "m"(v->counter));
> + __asm__ __volatile__("" : "=r"(t) : "m"(v->counter));
>   return t;
>  }
>
>
>
> Jakub