[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[pavel at zhukoff dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

--- Comment #6 from Pavel Zhukov  ---
Checked. Standard'Bit_Order is correct. So should be fine. Thank you, Eric.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671

--- Comment #32 from rguenther at suse dot de  ---
On Tue, 7 Mar 2017, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> Jonathan Wakely  changed:
> 
>What|Removed |Added
> 
>  Resolution|INVALID |FIXED
> 
> --- Comment #30 from Jonathan Wakely  ---
> The code in comment 20 still fails even with attribute((may_alias)), so I'm 
> not
> sure how the boost code can be fixed:
> 
> inline void* operator new(__SIZE_TYPE__, void *p) { return p; }
> struct A { A (float x) : f (x) {} float f; };
> static_assert(sizeof(A) == sizeof(float), "");
> struct B
> {
>   int x;
>   union __attribute__((__may_alias__)) U
>   {
> int a;
> char b[sizeof (float)];
>   } u;
>   int y;
> };
> 
> __attribute__((noinline, noclone)) void
> bar (B &x, B &y)
> {
>   if (x.x != 0)
> __builtin_abort ();
>   if (x.y != 3)
> __builtin_abort ();
>   if (y.x != 0)
> __builtin_abort ();
>   if (y.y != 3)
> __builtin_abort ();
>   float f;
>   __builtin_memcpy (&f, x.u.b, sizeof (float));
>   if (f != 3.5f)
> __builtin_abort ();
>   __builtin_memcpy (&f, y.u.b, sizeof (float));
>   if (f != 3.5f)
> __builtin_abort ();
> }
> 
> __attribute__((noinline, noclone)) 
> B *
> baz (B &x)
> {
>   return &x;
> }
> 
> __attribute__((noinline, noclone)) void
> foo (float x)
> {
>   B b { 0, {}, 3 }, c;
>   B *p = baz (b);
>   new (b.u.b) A (x);

The issue is that while operator new takes a ref-all pointer here
it just returns void * which is then passed as this to A::A and thus
construction happens via a non-ref-all pointer.

That is, C++ abstraction comes in the way of may_alias (basically
casting that away again).

So you need to place may-alias at a point to make the following
stmt safe:

>   c = *p;

which means placing it on B, not only on the union (p is a B).

Thus do

struct B
{
  int x;
  union U
{
  int a;
  char b[sizeof (float)];
} u;
  int y;
} __attribute__((may_alias));

[Bug target/66024] Implement AddressSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66024

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
asan is enabled on S/390 now.

[Bug rtl-optimization/79456] [7 regression] Extra instruction emitted after LRA patch

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79456

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #1)
> I can not reproduce the bug on the fresh trunk any more.  I believe the
> problem is analogous to
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282
> 
> and it was solved last week.

Indeed. Thanks!

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  8 08:35:20 2017
New Revision: 245967

URL: https://gcc.gnu.org/viewcvs?rev=245967&root=gcc&view=rev
Log:
PR sanitizer/79904
* internal-fn.c (expand_vector_ubsan_overflow): If arg0 or arg1
is a uniform vector, use uniform_vector_p return value instead of
building ARRAY_REF on folded VIEW_CONVERT_EXPR to array type.

* gcc.dg/ubsan/pr79904.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr79904.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79920] Incorrect floating point results when compiling with -O3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79920

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Mar  8 08:50:01 2017
New Revision: 245968

URL: https://gcc.gnu.org/viewcvs?rev=245968&root=gcc&view=rev
Log:
2017-03-08  Richard Biener  

PR tree-optimization/79920
* tree-vect-slp.c (vect_create_mask_and_perm): Remove and inline
with ncopies == 1 to ...
(vect_transform_slp_perm_load): ... here.  Properly compute
all element loads by iterating VF times over the group.  Do
not handle ncopies (computed in a broken way) in
vect_create_mask_and_perm.

* gcc.dg/vect/pr79920.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr79920.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug tree-optimization/79946] Suboptimal code with AVX2 copying all arguments to stack

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79946

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Well, this is what we end up on the GIMPLE leve before RTL expansion:

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _30 = MEM[(struct vect3d[16] *)d_87(D)];
  dx[0] = _30;
  _27 = MEM[(struct vect3d[16] *)d_87(D) + 24B];
  dx[1] = _27;
  _14 = MEM[(struct vect3d[16] *)d_87(D) + 48B];
  dx[2] = _14;
  _11 = MEM[(struct vect3d[16] *)d_87(D) + 72B];
  dx[3] = _11;
  _367 = *d_87(D)[4].x;
  dx[4] = _367;
  _342 = MEM[(struct vect3d[16] *)d_87(D) + 120B];
  dx[5] = _342;
  _335 = MEM[(struct vect3d[16] *)d_87(D) + 144B];
  dx[6] = _335;
...
  vect__226.88_97 = MEM[(real(kind=8) *)&tmp];
  vect__233.91_91 = MEM[(real(kind=8) *)&dx];
  vect__233.92_88 = MEM[(real(kind=8) *)&dx + 32B];
  vect__233.93_85 = MEM[(real(kind=8) *)&dx + 64B];
  vect__233.94_81 = MEM[(real(kind=8) *)&dx + 96B];
...

which eventually is coming from the FE:

  if (S.0 > 4) goto L.2;
  {
integer(kind=8) S.1;
integer(kind=8) D.3520;
integer(kind=8) D.3521;

D.3520 = S.0 * 4 + -5;
D.3521 = S.0 * 4 + -5;
S.1 = 1;
while (1)
  {
if (S.1 > 4) goto L.1;
dx[S.1 + D.3521] = (*d)[S.1 + D.3520].x;
S.1 = S.1 + 1;
  }
L.1:;
  }
...

and we do not consider vectorizing this with AVX because of the large stride:

t.f90:14:0: note: Load permutation 0 3 6 9
t.f90:14:0: note: permutation requires at least three vectors _327 =
*d_87(D)[_326].x;
t.f90:14:0: note: Build SLP failed: unsupported load permutation dx[_326] =
_327;

and with SSE because

t.f90:14:0: note: Cost model analysis:
  Vector inside of loop cost: 14
  Vector prologue cost: 0
  Vector epilogue cost: 8
  Scalar iteration cost: 8
  Scalar outside cost: 0
  Vector outside cost: 8
  prologue iterations: 0
  epilogue iterations: 1
t.f90:14:0: note: cost model: the vector iteration cost = 14 divided by the
scalar iteration cost = 8 is greater or equal to the vectorization factor = 1.
t.f90:14:0: note: not vectorized: vectorization not profitable.
t.f90:14:0: note: not vectorized: vector version will never be profitable.

only late full unrolling exposes the fact that we could elide Dx completely
by say, SRA.

In this case the vectorizer could consider using strided loads (not sure
if the cost model would be favorably of that idea though).

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940

Richard Biener  changed:

   What|Removed |Added

   Keywords||openmp
   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar  8 09:08:54 2017
New Revision: 245970

URL: https://gcc.gnu.org/viewcvs?rev=245970&root=gcc&view=rev
Log:
PR ada/79945
* system-linux-ppc.ads (Default_Bit_Order): Use Standard's setting.

* system-linux-arm.ads (Default_Bit_Order): Likewise.
* system-linux-mips.ads (Default_Bit_Order): Likewise.
* system-linux-armeb.ads: Delete.
* system-linux-mipsel.ads: Likewise.
* gcc-interface/Makefile.in (MIPS/Linux): Adjust.
(ARM/Linux): Likewise.

Removed:
trunk/gcc/ada/system-linux-armeb.ads
trunk/gcc/ada/system-linux-mipsel.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
trunk/gcc/ada/system-linux-arm.ads
trunk/gcc/ada/system-linux-mips.ads
trunk/gcc/ada/system-linux-ppc.ads

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar  8 09:09:11 2017
New Revision: 245971

URL: https://gcc.gnu.org/viewcvs?rev=245971&root=gcc&view=rev
Log:
PR ada/79945
* system-linux-ppc.ads (Default_Bit_Order): Use Standard's setting.

Modified:
branches/gcc-6-branch/gcc/ada/ChangeLog
branches/gcc-6-branch/gcc/ada/system-linux-ppc.ads

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.4

--- Comment #9 from Eric Botcazou  ---
.

[Bug bootstrap/79956] New: [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

Bug ID: 79956
   Summary: [7 Regression] many new -Wmaybe-uninitialized warnings
with bootstrap-O3
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

There are numerous new -Wmaybe-uninitialized warnings when using bootstrap-O3
and -enable-languages=c,c++,fortran:



../../gcc/gcc/regrename.c:1557:28: warning: ‘old_dups’ may be used
uninitialized in this function [-Wmaybe-uninitialized] 
  [188/7403]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +16)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +24)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +32)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +40)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +48)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../gcc/gcc/regrename.c:1557:28: warning: ‘*((void*)& old_dups +8)’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgcc/../libdecnumber/decBasic.c:865:14: warning: ‘*((void
*)&accl+32)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgcc/../libdecnumber/decBasic.c:865:14: warning: ‘*((void
*)&accl+64)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/all_l16.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/all_l1.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/all_l2.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/all_l4.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/all_l8.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/any_l16.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/any_l1.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/any_l2.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/any_l4.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/any_l8.c:212:30: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/count_16_l.c:208:30: warning: ‘dstride[6]’
may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/count_1_l.c:208:30: warning: ‘dstride[6]’
may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/count_2_l.c:208:30: warning: ‘dstride[6]’
may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/count_4_l.c:208:30: warning: ‘dstride[6]’
may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/count_8_l.c:208:30: warning: ‘dstride[6]’
may be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i16.c:180:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i16.c:358:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i16.c:492:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i1.c:180:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i1.c:358:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i1.c:492:23: warning: ‘dstride[6]’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
../../../gcc/libgfortran/generated/iall_i2.c:180:23: warning: ‘dstride[6]’ may
be used uninitialized in 

[Bug ada/79903] When building GCC-cross compiler for RTEMS/SPARC with Ada support, the build fails because of missing #ifdef

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79903

--- Comment #1 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar  8 09:20:17 2017
New Revision: 245972

URL: https://gcc.gnu.org/viewcvs?rev=245972&root=gcc&view=rev
Log:
PR ada/79903
* socket.c (__gnat_gethostbyaddr): Add missing test for __rtems__.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/socket.c

[Bug ada/79903] When building GCC-cross compiler for RTEMS/SPARC with Ada support, the build fails because of missing #ifdef

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79903

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Mar  8 09:20:35 2017
New Revision: 245973

URL: https://gcc.gnu.org/viewcvs?rev=245973&root=gcc&view=rev
Log:
PR ada/79903
* socket.c (__gnat_gethostbyaddr): Add missing test for __rtems__.

Modified:
branches/gcc-6-branch/gcc/ada/ChangeLog
branches/gcc-6-branch/gcc/ada/socket.c

[Bug ada/79903] When building GCC-cross compiler for RTEMS/SPARC with Ada support, the build fails because of missing #ifdef

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79903

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.4

--- Comment #3 from Eric Botcazou  ---
Thanks for reporting the problem and providing the fix.

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[aidan.chalk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940

--- Comment #4 from Aidan Chalk  ---
@Jakub ok - my bad, I had assumed the taskloop was a loop construct, but the
bug still exists with an omp single. Re: taskloop not being useful I made the
example to test syntax.

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79955

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed (testcase works on x86_64 with -m32).  We warn about an out-of-bound
access to

  wint_t str;

for which there is (obviously) no initialization.  The theory is that the
code is dead and never reached at runtime but of course the function
is gigantic and GCC wasn't able to prove this.

For similar cases we have path isolation which also (fortunately) runs after
the first VRP pass where we'd warn about out-of-bound array accesses.

So sth like the following fixes this warning (and it replaces the out-of-bound
access with a trap).  Note this is esp. tailored to the cases handled by
-Wuninitialized.

Index: gcc/gimple-ssa-isolate-paths.c
===
--- gcc/gimple-ssa-isolate-paths.c  (revision 245968)
+++ gcc/gimple-ssa-isolate-paths.c  (working copy)
@@ -502,6 +502,35 @@ find_explicit_erroneous_behavior (void)
  break;
}

+ /* Memory loads that are fully outside of an automatic
+variable are prone to cause -Wuninitialized warnings,
+prune them here by replacing them with a trap.  */
+ if (gimple_assign_load_p (stmt))
+   {
+ ao_ref ref;
+ ao_ref_init (&ref, gimple_assign_rhs1 (stmt));
+ tree base = ao_ref_base (&ref);
+ if (DECL_P (base)
+ && auto_var_in_fn_p (base, cfun->decl)
+ && ref.size != -1
+ && ref.max_size == ref.size
+ && (ref.offset + ref.size <= 0
+ || (ref.offset >= 0
+ && TREE_CODE (DECL_SIZE (base)) == INTEGER_CST
+ && compare_tree_int (DECL_SIZE (base),
+  ref.offset) <= 0)))
+   {
+ insert_trap (&si, null_pointer_node);
+ bb = gimple_bb (gsi_stmt (si));
+
+ /* Ignore any more operands on this statement and
+continue the statement iterator (which should
+terminate its loop immediately.  */
+ cfg_altered = true;
+ break;
+   }
+   }
+
  /* Detect returning the address of a local variable.  This only
 becomes undefined behavior if the result is used, so we do not
 insert a trap and only return NULL instead.  */

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79955

--- Comment #2 from Richard Biener  ---
Testcase that is fixed (at -O2, at -O1 we do not run isolate-paths...)

/* { dg-do compile } */
/* { dg-options "-O2 -Wmaybe-uninitialized" } */

int foo (int x)
{
  int y;
  if (x)
return *(&y + 1);  /* { dg-bogus "may be used uninitialized" } */
  return 0;
}

[Bug tree-optimization/79920] [6 Regression] Incorrect floating point results when compiling with -O3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79920

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1
Summary|Incorrect floating point|[6 Regression] Incorrect
   |results when compiling with |floating point results when
   |-O3 |compiling with -O3
  Known to fail|7.0.1   |

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 40921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40921&action=edit
gcc7-pr79940.patch

Untested fix.

Taskloop is a loop construct, but not a worksharing construct, i.e. every
(implicit) task encountering the construct will create the taskgroup (as
nogroup is not present) and create tasks for the taskloop iterations.

[Bug bootstrap/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The ‘dstride[6]’ cases are obviously the array-bound warnings we mitigated by
not warning from VRP2 which runs after complete peeling which is prone to
producing one iteration too much (even though it should have seen that
dstride[6] is out-of-bounds and thus eliminated the iteration via
__builtin_unreachable - not done
because this transform is restricted to one copy - I've analyzed this in
another PR once).

This also happens after path isolation.

So the only way to "fix" this is to either (finally) fix complete peeling or,
not warn for out-of-bound accesses in uninit warning.

I always prefer to not generate obviously dead code...

[Bug c++/79900] [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79900

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
reduced test case:

template  struct A;
template  struct B {
  long _M_off;
  int _M_state;
};
template <> struct A { typedef B pos_type; };
enum _Ios_Openmode {};
struct C {
  typedef _Ios_Openmode openmode;
};
template  struct D {
  typedef typename _Traits::pos_type pos_type;
  pos_type m_fn1(pos_type, C::openmode);
};
template class D>;
template 
typename D<_CharT, _Traits>::pos_type D<_CharT, _Traits>::m_fn1(pos_type,
C::openmode) {}

[Bug c++/79957] New: [C++] Zero-length array function parameters in templates should cause warning/substituion failure in pedantic mode

[felix.morgner at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79957

Bug ID: 79957
   Summary: [C++] Zero-length array function parameters in
templates should cause warning/substituion failure in
pedantic mode
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.morgner at gmail dot com
  Target Milestone: ---

According to ISO14882 [dcl.array] zero-length arrays are not allowed:

...
If the constant-expression (5.19) is present, it shall be a converted constant
expression of type std::size_t and its value shall be greater than zero.
...

GCC generally accepts zero-length arrays as an extension. However, it does
handle them inconsitently when compiling in pedantic mode. The following code
compiles fine in pedantic mode (for all code samples, the following flags are
used: -Wall -Wextra -Werror -pedantic-errors):

  template
  void fun(int [N] = {}) {
  }

  int main() {
fun<0>();
  }

even though the parameter of fun will be a zero-length array. On the other
hand, the following code does not compile in pedantic mode:

  void fun(int [0] = {}) {
  }

  int main() {
fun();
  }

with the expected error message:

  array.cpp:1:21: error: ISO C++ forbids zero-size array [-Wpedantic]
   void fun(int [0] = {}) {

Interestingly, the following code fails to compile as expected:

  template
  void fun(int (*)[N] = {}) {
  }

  int main() {
fun<0>();
  }

This incosistency leads to GCC interpreting the following code as being
ambiguous:

  template
  void fun(int [N + 1] = {}, int = 0) {
  }

  template
  void fun(int [N] = {}) {
  }

  int main() {
fun<0>();
  }

Handling zero-length array parameters in templates as invalid, when in pedantic
mode, would make GCC SFINAE away the second fun(...).

Both 'clang' and Microsoft's 'cl' handle zero-length arrays as expected.

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943

--- Comment #1 from Andrew Haley  ---
Author: aph
Date: Wed Mar  8 11:35:23 2017
New Revision: 245974

URL: https://gcc.gnu.org/viewcvs?rev=245974&root=gcc&view=rev
Log:
2017-03-08  Andrew Haley  

PR tree-optimization/79943
* tree-ssa-loop-split.c (compute_new_first_bound): When
calculating the new upper bound, (END-BEG) should be added, not
subtracted.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-split.c

[Bug bootstrap/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 40922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40922&action=edit
unreduced testcase

[Bug bootstrap/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #3 from Markus Trippelsdorf  ---
Testcase that only warns with -O3

int a, b, c;
void fn1() {
  int d[1];
  int e, n = a;
  for (; 0; n++)
;
  c = 1;
  while (c) {
if (a)
  for (;;)
;
while (d[0]) {
  e -= 0;
  if (b)
break;
}
  }
}

% gcc -c -Wall -Wextra -O2 parity_l8.i -Werror -Wfatal-errors
% gcc -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
parity_l8.i: In function ‘fn1’:
parity_l8.i:12:13: error: ‘d[0]’ is used uninitialized in this function
[-Werror=uninitialized]
 while (d[0]) {
~^~~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors

% clang -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
% clang --analyze -c -Wall -Wextra -O3 parity_l8.i -Werror -Wfatal-errors
parity_l8.i:4:14: warning: Value stored to 'n' during its initialization is
never read
  int e = 0, n = a;
 ^   ~
parity_l8.i:12:12: warning: Branch condition evaluates to a garbage value
while (d[0]) {
   ^~~~
2 warnings generated.

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jakub Jelinek  ---
Created attachment 40923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40923&action=edit
gcc7-pr79944.patch

Untested fix.

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-08
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg00334.html

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944

--- Comment #6 from Dmitry Vyukov  ---
Just build kernel with it. Boots fine and sustains some load now.
Did not do any positive tests, though.
Thanks for the quick fix!

[Bug c++/77772] Segmentation fault when running an application with gdb

[Jose.DiazdeGrenu at digi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2

--- Comment #7 from Jose.DiazdeGrenu at digi dot com ---
Seems like this has been fixed in gdb 7.11.

Could you point to the commit that fixes it? Has it been backported to gdb 7.9?

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|bootstrap   |libfortran
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
We do

  rank = GFC_DESCRIPTOR_RANK (array) - 1;
(expands to ((array)->dtype & 0x07) - 1 and thus is [-1, 6])

as result rank is one less than source rank(?) and

  for (n = 0; n < rank; n++)
{
  count[n] = 0;
  dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n);
  if (extent[n] <= 0)
return;
}

thus we initialize up to dstride[5] (and we figure that out, peeling the
init loop completely and never initializing dstride[5]).

The innermost loop



  n = 0;
  while (count[n] == extent[n])
{
  /* When we get to the end of a dimension, reset it and increment
 the next dimension.  */
  count[n] = 0;
  /* We could precalculate these products, but this is a less
 frequently used path so probably not worth it.  */
  base -= sstride[n] * extent[n];
  dest -= dstride[n] * extent[n];
  n++;
  if (n == rank)
{
  /* Break out of the look.  */
  continue_loop = 0;
  break;
}
  else
{
  count[n]++;
  base += sstride[n];
  dest += dstride[n];
}
}

is peeled completely as well but we somehow are not able to optimize the
remaining

  if (rank == 6)

test to true as the dominating tests are in loops forming

  if (rank == 1)
;
  else
if (rank == 2)
   ;
else
  if (rank == 3)
...
if (rank == 6)

and that's too complicated for us to analyze.

Note that with LIM enabled we run into the issue that LIM happily hoists
uninitialized reads (kind of PR39612).  So we'd have to optimize this
before LIM runs (VRP1) where we end up with

rank_396: [-1, 6]  EQUIVALENCES: { rank_111 rank_387 rank_391 rank_392 rank_393
rank_394 rank_395 } (7 elements)

which is ok (all equivalences have the same range).  Ideally it would be
[-1, 0] U [6, 6] but then the cases -1 and 0 still would not allow this to
be optimized.

Note that the retarray->base_addr == NULL case explicitely accesses
extent[rank - 1] which means that rank != 0 as well.  But nothing tells
GCC about this (retarray->base_addr may not actually be NULL).

Index: libgfortran/generated/parity_l8.c
===
--- libgfortran/generated/parity_l8.c   (revision 245968)
+++ libgfortran/generated/parity_l8.c   (working copy)
@@ -54,6 +54,8 @@ parity_l8 (gfc_array_l8 * const restrict
   /* Make dim zero based to avoid confusion.  */
   dim = (*pdim) - 1;
   rank = GFC_DESCRIPTOR_RANK (array) - 1;
+  if (rank < 1)
+runtime_error ("oops");

   len = GFC_DESCRIPTOR_EXTENT(array,dim);
   if (len < 0)

fixes this (and the warning).

Can fortran people please fix this?

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 8 Mar 2017, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956
> 
> --- Comment #3 from Markus Trippelsdorf  ---
> Testcase that only warns with -O3

It also warns with -O1 and -Os (but not -O2).  At -O2 the function is
optimized to just

fn1 ()
{
  int n;
  int d[1];

   [0.01%]:
  c = 1;

   [100.00%]:
  goto ; [100.00%]
}

at -O3 we have peeled one iteration and are left with

fn1 ()
{
  int n;
  int d[1];
  int b.1_1;
  int _2;

   [0.01%]:
  n_4 = a;
  c = 1;
  _2 = d[0];
  b.1_1 = b;
  goto ; [100.00%]
... (similar to above)

Note the testcase doesnt' capture the specific case of a bogus
warning as it is in parity_l8.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #6 from Richard Biener  ---
Index: libgfortran/generated/parity_l8.c
===
--- libgfortran/generated/parity_l8.c   (revision 245968)
+++ libgfortran/generated/parity_l8.c   (working copy)
@@ -167,7 +169,7 @@ parity_l8 (gfc_array_l8 * const restrict
  base -= sstride[n] * extent[n];
  dest -= dstride[n] * extent[n];
  n++;
- if (n == rank)
+ if (n >= rank)
{
  /* Break out of the look.  */
  continue_loop = 0;

also avoids the warning (== exit conditions are sometimes hard to analyze
for niter analysis)

[Bug tree-optimization/79943] Loop splitting breaks with loops of pointer type

[aph at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79943

Andrew Haley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Haley  ---
Fixed.

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79955

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Mar  8 14:10:47 2017
New Revision: 245976

URL: https://gcc.gnu.org/viewcvs?rev=245976&root=gcc&view=rev
Log:
2017-03-08  Richard Biener  

PR tree-optimization/79955
* tree-ssa-uninit.c (warn_uninitialized_vars): Do not warn
for accesses that are completely outside of the variable.

* gcc.dg/uninit-24.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/uninit-24.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug tree-optimization/79955] GLIBC build fails after r245840

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79955

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/79958] New: Missed tree DSE

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79958

Bug ID: 79958
   Summary: Missed tree DSE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

At -O3 in bar we have various dead temporaries, they don't have address taken
and so should be DSEd, but they aren't.  In foo which doesn't have the EH edges
this works well.

#include 
#include 
#include 

namespace
{
  struct bitarray
  {
bitarray(int i) : mSlice(i) {}
template
bitarray(const EXPR &expr) { mSlice = expr.slice(0); }
uint32_t
slice(ptrdiff_t index) const { if (index != 0) return 0; return mSlice; }
  private:
uint32_t mSlice;
  };
  template class OP>
  struct bit_binary_expr
  {
bit_binary_expr(const LEFT &left, const RIGHT &right) : mLeft(left),
mRight(right) {}
uint32_t slice(ptrdiff_t index) const { OP op; return
op(mLeft.slice(index), mRight.slice(index)); }
  private:
const LEFT &mLeft;
const RIGHT &mRight;
  };
  template
  bit_binary_expr
  operator &(const LEFT &left, const RIGHT &right) { return
bit_binary_expr(left, right); }
  template
  bit_binary_expr operator |(const LEFT &left,
const RIGHT &right)
  { return bit_binary_expr(left, right); }
  template
  struct bit_shift_left
  {
bit_shift_left(const OPERAND &operand, size_t nBits) : mOperand(operand),
mBits(nBits) {}
uint32_t slice(ptrdiff_t index) const
{
  const ptrdiff_t offset = mBits / 32;
  const size_t bits = mBits % 32;
  if (bits == 0)
return mOperand.slice(index - offset);
  else
return (mOperand.slice(index - offset) << bits) | (mOperand.slice(index
- offset - 1) >> (32 - bits));
}
  private:
const OPERAND &mOperand;
const size_t mBits;
  };
  template
  bit_shift_left operator <<(const OPERAND &operand, size_t nBits) {
return bit_shift_left(operand, nBits); }
}
struct Foo
{
  void write(const bitarray &);
};
void
foo(int i)
{
  Foo f;
  f.write(bitarray(( bitarray(i)  & bitarray(0x0001))) << 31) |
bitarray(0x4000)))
| bitarray(42) & bitarray(0x))) <<  8) |
bitarray(0x0080;
}
struct Bar
{
  ~Bar(void);
  void write(const bitarray &) /* throw() */;
};
void
bar(int i)
{
  Bar b;
  b.write(bitarray(( bitarray(i)  & bitarray(0x0001))) << 31) |
bitarray(0x4000)))
| bitarray(42) & bitarray(0x))) <<  8) |
bitarray(0x0080;
}

[Bug c++/79727] -Wimplicit-fallthrough=3 doesn't seem to match any comments

[peter at eisentraut dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79727

Peter Eisentraut  changed:

   What|Removed |Added

 CC||peter at eisentraut dot org

--- Comment #3 from Peter Eisentraut  ---
My general impression is that level =2 looks for substring matches, like

 /* fall through because this code is weird */

whereas level =3 only looks for some exact strings, like

/* FALLTHROUGH */

This could be made clearer in the documentation.

[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79347

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from amker at gcc dot gnu.org ---
> Fixed.  The failure on sparc-sun-solaris2.12 should be resolved by patch to
> PR77536.

It is indeed.

Thanks.
Rainer

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #1 from Jonathan Wakely  ---
The two cases are not equivalent, because the bounds of a[10] are known at
compile-time, but v.size() is not. The only way to know v.size() is with a
run-time check, which has a non-zero cost.

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67264

--- Comment #4 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Mar  8 14:28:38 2017
New Revision: 245978

URL: https://gcc.gnu.org/viewcvs?rev=245978&root=gcc&view=rev
Log:
Fix PR demangler/70909 and 67264 (endless demangler recursion)

ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * include/demangle.h: Add d_printing to struct demangle_component
   and pass struct demangle_component as non const.

libiberty/ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * cp-demangle.c: Fix endless recursion. Pass
   struct demangle_component as non const.
   (d_make_empty): Initialize variable.
   (d_print_comp_inner): Limit recursion.
   (d_print_comp): Decrement variable.
   * cp-demint.c (cplus_demangle_fill_component): Initialize
   variable.
   (cplus_demangle_fill_builtin_type): Likewise.
   (cplus_demangle_fill_operator): Likewise.
   * testsuite/demangle-expected: Add tests.

Modified:
trunk/ChangeLog
trunk/include/demangle.h
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/cp-demint.c
trunk/libiberty/testsuite/demangle-expected

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

--- Comment #44 from Markus Trippelsdorf  ---
Author: trippels
Date: Wed Mar  8 14:28:38 2017
New Revision: 245978

URL: https://gcc.gnu.org/viewcvs?rev=245978&root=gcc&view=rev
Log:
Fix PR demangler/70909 and 67264 (endless demangler recursion)

ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * include/demangle.h: Add d_printing to struct demangle_component
   and pass struct demangle_component as non const.

libiberty/ChangeLog:

   PR demangler/70909
   PR demangler/67264
   * cp-demangle.c: Fix endless recursion. Pass
   struct demangle_component as non const.
   (d_make_empty): Initialize variable.
   (d_print_comp_inner): Limit recursion.
   (d_print_comp): Decrement variable.
   * cp-demint.c (cplus_demangle_fill_component): Initialize
   variable.
   (cplus_demangle_fill_builtin_type): Likewise.
   (cplus_demangle_fill_operator): Likewise.
   * testsuite/demangle-expected: Add tests.

Modified:
trunk/ChangeLog
trunk/include/demangle.h
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/cp-demint.c
trunk/libiberty/testsuite/demangle-expected

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #45 from Markus Trippelsdorf  ---
Fixed.

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67264
Bug 67264 depends on bug 70909, which changed state.

Bug 70909 Summary: Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug demangler/67264] Infinite recursion of demangler on fuzzed input

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67264

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Markus Trippelsdorf  ---
Fixed.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #2 from Jonathan Wakely  ---
The C++ front-end could be taught about std::vector::size() as a special case,
but that would only help that special case, it wouldn't help for
std::deque::size(), or boost::vector::size() or other types.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #3 from Jonathan Wakely  ---
And for this example it's possible that g(int) modifies the vector that the
reference v is bound to, so the size could even change on every loop iteration.
So if we added some runtime checks to std::vector (maybe only enabled for
_FORTIFY_SOURCE) then the size() would need to be reloaded on every loop
iteration, it couldn't be hoisted out of the loop. So that also suggests it
would have to be a special case handled by the front end, just for
std::vector::size()

[Bug c++/79957] [C++] Zero-length array function parameters in templates should cause warning/substituion failure in pedantic mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79957

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I think the policy is that SFINAE contexts are always pedantic.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939

--- Comment #8 from Jonathan Wakely  ---
No, no change. I think we need to change the tuple_size specializations
to be incomplete when tuple_size is incomplete, even though that appears to
contradict the changes made by lwg 2770.

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

But this also affects C++11 mode, so I'm still trying to understand all the
consequences of such a change. At the least, some tests need changing:


FAIL: 20_util/pair/astuple/astuple.cc (test for excess errors)
FAIL: 20_util/tuple/cv_tuple_size.cc (test for excess errors)
UNRESOLVED: 20_util/tuple/cv_tuple_size.cc compilation failed to produce
executable
FAIL: 20_util/tuple/tuple_size.cc (test for excess errors)
FAIL: 23_containers/array/tuple_interface/tuple_size.cc (test for excess
errors)

These all fail for the same reason, and I think it's a FE bug.

[Bug c/79959] New: -Wimplicit-fallthrough doesn't recognize some more complex exit cases

[peter at eisentraut dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79959

Bug ID: 79959
   Summary: -Wimplicit-fallthrough doesn't recognize some more
complex exit cases
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at eisentraut dot org
  Target Milestone: ---

gcc-7 (Homebrew GCC 7-20170305_1) 7.0.1 20170305 (experimental)

Code:

#include 

int
main(int argc, char **argv)
{
switch (argc)
{
case 1:
do { if (__builtin_constant_p(20) && (20) >= 20) abort(); }
while(0);
default:
return 0;
}
}

gcc-7 -Wimplicit-fallthrough -O2 -c test.c
test.c: In function 'main':
test.c:9:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
   do { if (__builtin_constant_p(20) && (20) >= 20) abort(); } while(0);

I would expect no warning here.

This concoction is a macro expansion that intends to communicate "noreturn"
based on some constant argument value, and that generally works well for
avoiding uninitialized variable warnings and things like that, so the control
flow analysis is smart enough to recognize that this is an unconditional exit. 
But the fallthrough analysis doesn't appear to be that smart.  It only detects
a plain abort() or something like that.

[Bug c++/79960] New: [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960

Bug ID: 79960
   Summary: [5/6/7 Regression] Class template partial
specializations for const volatile types don't match
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

using size_t = decltype(sizeof(0));

template struct tuple_size;

template::value>
  using __has_tuple_size = T;

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple { };
template struct tuple_size> {
  static constexpr size_t value = sizeof...(T);
};

static_assert( tuple_size>::value == 0, "" );  // OK
static_assert( tuple_size>::value == 0, "" ); // OK
static_assert( tuple_size>::value == 0, "" ); // FAIL



GCC trunk fails to match the specialization:

cv.cc:27:50: error: ambiguous template instantiation for ‘struct
tuple_size >’
 static_assert( tuple_size>::value == 0, "" ); // FAIL
  ^~
cv.cc:8:29: note: candidates are: template struct
tuple_size<__has_tuple_size > [with T = volatile tuple<>]
 template struct tuple_size> {
 ^
cv.cc:12:29: note: template struct
tuple_size<__has_tuple_size > [with T = const tuple<>]
 template struct tuple_size> {
 ^~~~
cv.cc:16:29: note: template struct
tuple_size<__has_tuple_size > [with T = tuple<>]
 template struct tuple_size> {
 ^~
cv.cc:27:52: error: incomplete type ‘tuple_size >’ used
in nested name specifier
 static_assert( tuple_size>::value == 0, "" ); // FAIL
^

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> These all fail for the same reason, and I think it's a FE bug.

Reported as PR 79960 (seems to be a regression since 4.9)

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[a...@cloudius-systems.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

--- Comment #46 from Avi Kivity  ---
Hopefully, the fix can be propagated to gdb's demangler soon.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

--- Comment #47 from Markus Trippelsdorf  ---
(In reply to Avi Kivity from comment #46)
> Hopefully, the fix can be propagated to gdb's demangler soon.

Unfortunately binutils 2.28 was released a few days ago.
The next release will be in August and will include the fix.

[Bug target/70549] insn does not satisfy its constraints aarch64 gcc-4.8

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70549

--- Comment #8 from Jakub Jelinek  ---
Created attachment 40924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40924&action=edit
gcc48-pr70549.patch

Bernd came up with this untested fix.  Isn't that something that should be done
on the trunk too?
Side note, the i386 backend has r <- F alternative in movsf and in that case
just converts the floating point SFmode constant into integer.  If aarch64
isn't able to set GPRs from arbitrary 32-bit constants, perhaps you could have
some constraint that would represent just the SFmode const_double operands that
after converting them into their memory representation can be loaded into a
register using a single insn.

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960

--- Comment #1 from Jonathan Wakely  ---
It's possible this isn't a bug, and the partial specializations need to be
constrained to avoid the ambiguity (although both Clang trunk and EDG accept
the unconstrained cases, but Clang 3.x fails similarly to G++).

This works with any G++ version:

using size_t = decltype(sizeof(0));

struct true_type { static constexpr bool value = true; };
struct false_type { static constexpr bool value = false; };

template struct enable_if { };
template<> struct enable_if { using type = void; };
template using disable_if = typename enable_if::type;

template struct is_const : false_type { };
template struct is_const : true_type { };
template struct is_volatile : false_type { };
template struct is_volatile : true_type { };

template struct tuple_size;

template::value>
  using __has_tuple_size = T;

template
struct tuple_size>>> {
  static constexpr size_t value = tuple_size::value;
};

template
struct tuple_size>>> {
  static constexpr size_t value = tuple_size::value;
};

template
struct tuple_size> {
  static constexpr size_t value = tuple_size::value;
};

template struct tuple { };
template struct tuple_size> {
  static constexpr size_t value = sizeof...(T);
};

static_assert( tuple_size>::value == 0, "" );  // OK
static_assert( tuple_size>::value == 0, "" ); // OK
static_assert( tuple_size>::value == 0, "" ); // OK

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #4 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> And for this example it's possible that g(int) modifies the vector that the
> reference v is bound to

I doubt g can modify v.

Anyway, I think some progress could be made by finding the pattern

for (something = 0; something <= somethingElse.size(); ++ something)

at compile time, which is what the  static analyser 'cppcheck' seems to be
doing.

$ ~/cppcheck/trunk/cppcheck mar7a.cc
[mar7a.cc:22]: (error) Array 'a[10]' accessed at index 10, which is out of
bounds.
[mar7a.cc:12]: (error) When i==v.size(), v[i] is out of bounds.
$ 

No work required at run time, AFAIK.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

--- Comment #48 from Pedro Alves  ---
GDB is released separately from binutils though, and GDB 8.0 is going to branch
very soon.  IWBN to have this in the binutils-gdb repo by then.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939

--- Comment #10 from Jonathan Wakely  ---
This works around the ambiguity that PR 79960 describes:

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

I think this might be a workable solution.

If we don't like it for C++14 we could conditionally use it just for C++17 for
now.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78939

--- Comment #11 from Jonathan Wakely  ---
Oops, that was the previous diff, I meant to paste this (which constrains the
__enable_if_has_tuple_size to only be used when _Tp has no cv-quals, so we
avoid ambiguities):

--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -88,24 +88,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct tuple_size;

   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2313. tuple_size should always derive from integral_constant
   // 2770. tuple_size specialization is not SFINAE compatible
-  template
-struct __tuple_size_cv_impl { };

-  template
-struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
-: integral_constant::value> { };
+  template::type,
+  typename = typename enable_if::value>::type,
+  size_t = tuple_size<_Tp>::value>
+using __enable_if_has_tuple_size = _Tp;

-  // _GLIBCXX_RESOLVE_LIB_DEFECTS
-  // 2313. tuple_size should always derive from integral_constant
   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   template
-struct tuple_size : __tuple_size_cv_impl<_Tp> { };
+struct tuple_size>
+: public tuple_size<_Tp> { };

   /// Gives the type of the ith element of a given tuple type.
   template

[Bug c++/79961] New: Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

Bug ID: 79961
   Summary: Should diagnose when '__nonnull__' attribute is
applied to implicit this argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

struct A
{
  A (const char *arg) __attribute__ ((__nonnull__ (1)));
  void foo (const char *arg) __attribute__ ((__nonnull__ (1)));
};

Above, nonnull(1) should have been nonnull(2), since argument 1 is the implicit
"this" pointer (which is always non-NULL anyway).

Unfortunately, G++ fails to help find the bug.

With GNU C++14 (GCC) version 7.0.1 20170307 (experimental):

 $ /opt/gcc/bin/g++ nonnull.cc -o nonnull -g3 -O2 -c -Wall -Wextra
 (no warnings)

Note Clang 3.7:

 $ clang++ nonnull.cc -o nonnull -c
 nonnull.cc:3:39: error: '__nonnull__' attribute is invalid for the implicit
this argument
   A (const char *arg) __attribute__ ((__nonnull__ (1)));
   ^~
 nonnull.cc:4:46: error: '__nonnull__' attribute is invalid for the implicit
this argument
   void foo (const char *arg) __attribute__ ((__nonnull__ (1)));
  ^~
 2 errors generated.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #7 from Martin Liška  ---
I can also see profiledbootstrap failure in:

.././../gcc/simplify-rtx.c:6021:12: error: ‘result_s’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
 return result_s;
^~~~

It worked with a revision from 3.3.2017, is it the same issue as seen by
Markus?

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #5 from Jonathan Wakely  ---
(In reply to David Binderman from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > And for this example it's possible that g(int) modifies the vector that the
> > reference v is bound to
> 
> I doubt g can modify v.


Of course it can:


#include 

std::vector v;

void g(int i) {
  std::cout << i << '\n';
  if (i < 5)
v.push_back(i + 5);
}

int main()
{
  v = { 1, 10 };
  f1(v);
}

This is entirely valid. If linked to your code in comment 0 it has undefined
behaviour but that's because of your i <= size() not because of this code.



> Anyway, I think some progress could be made by finding the pattern
> 
> for (something = 0; something <= somethingElse.size(); ++ something)
> 
> at compile time, which is what the  static analyser 'cppcheck' seems to be
> doing.

That's what I said, it would have to be a special case built in to the
front-end.

[Bug c++/79950] G++ cannot detect simple off by one error in STL classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79950

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to David Binderman from comment #4)
> > Anyway, I think some progress could be made by finding the pattern
> > 
> > for (something = 0; something <= somethingElse.size(); ++ something)
> > 
> > at compile time, which is what the  static analyser 'cppcheck' seems to be
> > doing.
> 
> That's what I said, it would have to be a special case built in to the
> front-end.

And it has to be a lot smarter than that, as there's nothing wrong with:

  for (unsigned i = 0; i <= v.size(); ++i)
std::cout << i;

It's only a problem if you do v[i] when i == v.size()

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

--- Comment #1 from Jonathan Wakely  ---
IMHO it would be much, much better if the implicit 'this' wasn't counted and
nonnull(1) referred to 'arg' but maybe it's too late to change that.

[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Adding Richi to ask him for a smart advise :)

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

--- Comment #2 from Pedro Alves  ---
Yeah, I think it's too late, and it'd cause trouble with compatibility with
clang.

Note that the documentation for the attribute(format)

says:

"Since non-static C++ methods have an implicit this argument, the arguments of
such methods should be counted from two, not one, when giving values for
string-index and first-to-check."

but the documentation for the nonnull attribute doesn't say anything about it. 
Maybe that bit could be factored out somehow, or copied, or xrefed.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Yes, improving the docs would be a start. Issuing a warning like Clang does
would be ideal.

[Bug c++/79962] New: [7 Regression] ICE nonnull_check_p on a function template with a type-dependent attribute nonnull

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79962

Bug ID: 79962
   Summary: [7 Regression] ICE nonnull_check_p on a function
template with a type-dependent attribute nonnull
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Today's top of trunk fails with an ICE on the following test case.  r245606
compiles the test case successfully so this is a recent regression.

$ cat t.C && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc  -S -Wall
-Wextra -Wnonnull t.C
template 
void f (typename T::U) __attribute__ ((__nonnull__ (T::i)));

struct S { enum { i = 1 }; typedef void* U; };

void g ()
{
  f(0);
}

t.C: In function ‘void g()’:
t.C:8:9: internal compiler error: in nonnull_check_p, at
c-family/c-common.c:5423
   f(0);
 ^
0xb1ee7d nonnull_check_p
/ssd/src/gcc/git/gcc/c-family/c-common.c:5423
0xb1e843 check_function_nonnull
/ssd/src/gcc/git/gcc/c-family/c-common.c:5301
0xb1f811 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**)
/ssd/src/gcc/git/gcc/c-family/c-common.c:5661
0x7ea3b0 build_over_call
/ssd/src/gcc/git/gcc/cp/call.c:7917
0x7dbc4b build_new_function_call(tree_node*, vec**, bool, int)
/ssd/src/gcc/git/gcc/cp/call.c:4278
0xa0f3a4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/ssd/src/gcc/git/gcc/cp/semantics.c:2441
0x94c8f0 cp_parser_postfix_expression
/ssd/src/gcc/git/gcc/cp/parser.c:6994
0x94efe2 cp_parser_unary_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8102
0x94fe35 cp_parser_cast_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8780
0x94ff23 cp_parser_binary_expression
/ssd/src/gcc/git/gcc/cp/parser.c:8882
0x950c40 cp_parser_assignment_expression
/ssd/src/gcc/git/gcc/cp/parser.c:9170
0x950fdb cp_parser_expression
/ssd/src/gcc/git/gcc/cp/parser.c:9337
0x9542f8 cp_parser_expression_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10885
0x953c69 cp_parser_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10701
0x954847 cp_parser_statement_seq_opt
/ssd/src/gcc/git/gcc/cp/parser.c:11027
0x954742 cp_parser_compound_statement
/ssd/src/gcc/git/gcc/cp/parser.c:10981
0x968239 cp_parser_function_body
/ssd/src/gcc/git/gcc/cp/parser.c:21430
0x968402 cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/git/gcc/cp/parser.c:21466
0x971791 cp_parser_function_definition_after_declarator
/ssd/src/gcc/git/gcc/cp/parser.c:26254
0x971595 cp_parser_function_definition_from_specifiers_and_declarator
/ssd/src/gcc/git/gcc/cp/parser.c:26166
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #2 from Pat Haugen  ---
Reduced testcase.

pthaugen@pike:~/temp/creduce$ cat junk.cpp
typedef int V4i __attribute__((vector_size(16)));
void a(V4i ) {
  vector int b;
  a(b);
}

pthaugen@pike:~/temp/creduce$ ~/install/gcc/trunk/bin/g++ -S junk.cpp
junk.cpp: In function ‘void a(V4i)’:
junk.cpp:4:6: internal compiler error: canonical types differ for identical
types __vector(4) int and V4i {aka __vector(4) int}
   a(b);
  ^
0x1038318b comptypes(tree_node*, tree_node*, int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/typeck.c:1433
0x1019524f standard_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1187
0x101a6af3 implicit_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1839
...

[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681

[lopezibanez at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886

--- Comment #5 from Manuel López-Ibáñez  ---
The first one seems the right approach. It will also fix a number of
similar bugs in one go.The second one seems more fragile and it doesn't
help in decoupling ME from FE more than the first.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #8 from rguenther at suse dot de  ---
On March 8, 2017 4:43:05 PM GMT+01:00, "marxin at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956
>
>--- Comment #7 from Martin Liška  ---
>I can also see profiledbootstrap failure in:
>
>.././../gcc/simplify-rtx.c:6021:12: error: ‘result_s’ may be used
>uninitialized
>in this function [-Werror=maybe-uninitialized]
> return result_s;
>^~~~
>
>It worked with a revision from 3.3.2017, is it the same issue as seen
>by
>Markus?

I've run into this as well but it's slightly non reproducible (repeating the
compile command sometimes works, sometimes not).  From analyzing it looked
similar and/or threading related.

Richard.

[Bug c/79940] [6/7 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  8 17:21:06 2017
New Revision: 245980

URL: https://gcc.gnu.org/viewcvs?rev=245980&root=gcc&view=rev
Log:
PR c/79940
* gimplify.c (gimplify_omp_for): Replace index var in outer
taskloop statement with an artificial variable and add
OMP_CLAUSE_PRIVATE clause for it.

* testsuite/libgomp.c/pr79940.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr79940.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug c++/79900] [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79900

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug translation/79618] prevent missing space in multiline string literals

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Good idea.

We can't do it at run-time from inside the diagnostics subsystem, as the
line-breaking information is lost when the literal is compiled.

So from an implementation POV, I believe this would have to happen inside
xgettext when it scans the sources to create .pot files, so that it can enforce
one of the variants described in comment #1 (presumably as a new --check option
to xgettext).

In theory, we could do it with a compiler plugin that detects such strings, but
given that xgettext is scanning the strings already, presumably this would be
better implemented as an xgettext test.

Alternatively, I guess we could implement some kind of preprocessing hack to
run when generating the .pot files, but presumably other projects would find
this useful, so it seems to make more sense as an xgettext feature.

[Bug rtl-optimization/79806] [5/6/7 Regression] ICE error: unable to find a register to spill (in assign_by_spills, at lra-assigns.c:1457)

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79806

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #1 from Bernd Schmidt  ---
I'm tempted to classify this as unsupported. The testcase reserves edx, and the
alloca call includes a division operation which requires edx. Without
optimization, it remains until register allocation.

Global registers are somewhat fragile, and I think it's not worth it trying to
fix this. I'd put this at P4 at most.

[Bug target/79963] New: vec_eq_any extracts wrong CR bit when compiling with -mcpu=power9

[acsawdey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79963

Bug ID: 79963
   Summary: vec_eq_any extracts wrong CR bit when compiling with
-mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: meissner at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-* power9

Tested with trunk 245979:

gcc/xgcc -Bgcc ../trunk/gcc/testsuite/gcc.target/powerpc/altivec-12.c -maltivec
-lm -g -o ./altivec-12.exe

In test testsuite/gcc.target/powerpc/altivec-12.c line 50:

   CHECK_IF (vec_any_eq (h, addf1));

For power9 we generate this code:

.L17:
.loc 1 50 0 is_stmt 1
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
lxv 12,0(9)
addis 9,2,addf1@toc@ha
addi 9,9,addf1@toc@l
lxv 0,0(9)
xvcmpeqsp. 0,12,0
mfcr 9,2
rlwinm 9,9,25,1
xori 9,9,0x1
extsw 9,9
cmpdi 7,9,0
bne 7,.L18
.loc 1 50 0 is_stmt 0 discriminator 1
bl abort

In gdb I can see that h and addf1 are equal after loading, and the comparison
is correct, however we are extracting the wrong bit from the cr with the
rlwinm.

For power8 we generate this code:

.L17:
.loc 1 50 0 is_stmt 1
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
lxvd2x 0,0,9
xxpermdi 12,0,0,2
addis 9,2,addf1@toc@ha
addi 9,9,addf1@toc@l
lxvd2x 0,0,9
xxpermdi 0,0,0,2
xvcmpeqsp. 0,12,0
mfcr 9,2
rlwinm 9,9,27,1
xori 9,9,0x1
extsw 9,9
cmpdi 7,9,0
bne 7,.L18
.loc 1 50 0 is_stmt 0 discriminator 1
bl abort

which runs correctly.

[Bug target/79909] ICE error: invalid rtl sharing found in the insn on ppc64le

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79909

Pat Haugen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-08
 CC||pthaugen at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Pat Haugen  ---
Confirmed.

Reduced testcase.

// g++ -S -O1 -mxl-compat test.C
typedef float td __attribute__ ((mode (TD)));
td b, c, d, e, f, g;
void h (td, td, td, td, td, td);
void i ()
{
  h (e, b, f, c, g, d);
}

[Bug c/79940] [6 Regression] OpenMP pragma - internal compiler error with taskloop

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79940

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] OpenMP |[6 Regression] OpenMP
   |pragma - internal compiler  |pragma - internal compiler
   |error with taskloop |error with taskloop

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
We certainly should allow __attribute__((nonnull)) on methods, even when that
includes nonnull (implicit) also for this.  I find error on that weird, there
is nothing wrong specifying that this is non-null, so perhaps just warning (but
question is how to call it and under which of -Wall/-W or none of that enable
it).

[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r217250 aka DR1558 change.

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961

--- Comment #5 from Pedro Alves  ---
> We certainly should allow __attribute__((nonnull)) on methods, even when that 
> > includes nonnull (implicit) also for this. 

Yes, agreed, with implicit nonnull with no specified argument.

For the case of specifying an argument number with nonnull(N), I don't find the
error weird at all, because "this" can never be NULL.  Even without the
attribute, the compiler is already free to assume that.  Calling a method via a
null pointer is undefined behavior.  So __attribute__((nonnull(1))) on a
non-static method is _always_ a bug.

[Bug target/79964] New: Cortex A53 codegen still not optimal

[tulipawn at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79964

Bug ID: 79964
   Summary: Cortex A53 codegen still not optimal
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Two data points:

- the integer benchmark from PR79665 runs about 7% slower with -mcpu=cortex-a53
vs other targets, equalling generic codegen. It was still indistinguishable on
20170220, so the regression must have happened shortly after as per PR79665#c13

- c-ray again, wherein dispensing with -mfix-cortex-a53-843419 removes the
handicap, but e.g. A57 codegen produces the best result ever on this machine:

http://openbenchmarking.org/result/1703089-RI-1703040RI07

Coming from a Cortex A53 with 32kB of L1 cache.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #9 from Thomas Koenig  ---
Created attachment 40925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40925&action=edit
Patch to fix the libfortran issue

Based on Comment#6, this is a patch for the libfortran issue.
I am currently regression-testing.

Does this work for the libfortran issues?

[Bug target/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p

[kelvin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79395

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from kelvin at gcc dot gnu.org ---
Submitted patch resolves this issue.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956

--- Comment #10 from Markus Trippelsdorf  ---
Most of the warnings are gone due to the patch. These are the remaining ones:

libgfortran/generated/reshape_c16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_c4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_c8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_i8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r16.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r4.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/generated/reshape_r8.c:266:12: warning: ‘sstride[0]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/execute_command_line.c:162:16: warning: ‘estat’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/execute_command_line.c:191:16: warning: ‘estat’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
libgfortran/intrinsics/reshape_generic.c:253:21: warning: ‘sstride[0]’ may be
used uninitialized in this function [-Wmaybe-uninitialized]

[Bug c++/79797] [5/6/7 Regression] ICE with NSDMI, this pointer and constexpr

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79797

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug fortran/79965] New: [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

Bug ID: 79965
   Summary: [7 Regression] OpenMP simd, invalid instructions on
ia32 core2
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de
  Target Milestone: ---

Created attachment 40926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40926&action=edit
gfc-trunk -fopenmp gfcbug139.f90 -c -march=core2 -S -fverbose-asm

Hi,

the following code leads to invalid instructions on a dated machine
(arch=core2):

% cat gfcbug139.f90
pure real function add(a,b)
!$omp declare simd(add)
  real ,intent(in) :: a,b
  add=a+b
end function add

% gfc-trunk --version | head -1
GNU Fortran (GCC) 7.0.1 20170308 (experimental)

% gfc-trunk -fopenmp gfcbug139.f90 -c -march=core2
/tmp/cckyPHXa.s: Assembler messages:
/tmp/cckyPHXa.s:346: Error: no such instruction: `vmovdqu32 %zmm0,-192(%ebp)'
/tmp/cckyPHXa.s:347: Error: no such instruction: `vmovdqa64 %zmm1,%zmm0'
/tmp/cckyPHXa.s:348: Error: no such instruction: `vmovdqu32 %zmm0,-128(%ebp)'
/tmp/cckyPHXa.s:366: Error: bad register name `%zmm0'
/tmp/cckyPHXa.s:398: Error: no such instruction: `vmovdqu32 %zmm0,-192(%ebp)'
/tmp/cckyPHXa.s:399: Error: no such instruction: `vmovdqa64 %zmm1,%zmm0'
/tmp/cckyPHXa.s:400: Error: no such instruction: `vmovdqu32 %zmm0,-128(%ebp)'
/tmp/cckyPHXa.s:425: Error: bad register name `%zmm0'

See also attachment for the generated assembler.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

--- Comment #1 from Andrew Pinski  ---
Your binutils does not support AVX-2 ...

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

--- Comment #2 from Harald Anlauf  ---
(In reply to Andrew Pinski from comment #1)
> Your binutils does not support AVX-2 ...

No, it does not.   As I wrote, it's a dated machine.

But for -march=core2 there should be no AVX instructions anyway.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

--- Comment #3 from Andrew Pinski  ---
(In reply to Harald Anlauf from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Your binutils does not support AVX-2 ...
> 
> No, it does not.   As I wrote, it's a dated machine.
> 
> But for -march=core2 there should be no AVX instructions anyway.

>!$omp declare simd(add)

Causes all simd variants to be created IIRC.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Jakub Jelinek  ---
Yeah, and that is needed for ABI reasons.
In this case it doesn't seem to be missing AVX2 support, but missing AVX512F
support.
Anyway, just upgrade your binutils, or avoid using !$omp declare simd.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

--- Comment #5 from Harald Anlauf  ---
(In reply to Jakub Jelinek from comment #4)
> Yeah, and that is needed for ABI reasons.
> In this case it doesn't seem to be missing AVX2 support, but missing AVX512F
> support.
> Anyway, just upgrade your binutils, or avoid using !$omp declare simd.

Interesting.

The Intel compiler does not have this issue when this arch is selected.

[Bug target/79965] [7 Regression] OpenMP simd, invalid instructions on ia32 core2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79965

--- Comment #6 from Jakub Jelinek  ---
Yes, they chose to only do SSE2 and nothing else by default (and need to use
special clauses otherwise).  We chose to do SSE2, AVX, AVX2, AVX512F.  Of
course only for exported functions, for TU local ones it is just whatever arch
you optimize for.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79949

--- Comment #2 from Vladimir Makarov  ---
I've reproduced it and started to work on it.

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79949

--- Comment #3 from Vladimir Makarov  ---
The fix will be ready tomorrow.