[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
I am surprised, I thought we used to canonicalize bzero to memcpy...

[Bug debug/80938] New: [8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[asolokha at gmx dot com]

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

Bug ID: 80938
   Summary: [8 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2330
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20170528 snapshot ICEs when compiling the following snippet w/
-Os -g -fPIC:

void
xy (void);

void
j5 (f9)
{
  if (f9 != 0)
xy ();
  j5 ();
}

% powerpc-e500v2-linux-gnuspe-gcc-8.0.0-alpha20170528 -Os -g -fPIC -w -c
nghbxjig.c
nghbxjig.c: In function 'j5':
nghbxjig.c:10:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2330
 }
 ^
0x7f1a8b maybe_record_trace_start
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20170528/work/gcc-8-20170528/gcc/dwarf2cfi.c:2330
0x7f43e0 scan_trace
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20170528/work/gcc-8-20170528/gcc/dwarf2cfi.c:2512
0x7f4c72 create_cfi_notes
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20170528/work/gcc-8-20170528/gcc/dwarf2cfi.c:2666
0x7f4c72 execute_dwarf2_frame
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20170528/work/gcc-8-20170528/gcc/dwarf2cfi.c:3024
0x7f4c72 execute
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-8.0.0_alpha20170528/work/gcc-8-20170528/gcc/dwarf2cfi.c:3504

[Bug middle-end/57485] memcpy in aggregate return not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.1.0

--- Comment #3 from Martin Sebor  ---
Confirmed with 7.1 with the following test case.  The assembly shows the memcpy
(expanded  inline).

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
struct S { int a[100]; };
struct S f (void);

void g(struct S *p);

void h (void) {
struct S s = f();  // no local temporary
g();
}

void j (void) {
struct S s;
s = f();   // local temporary and memcpy
g();
}


;; Function h (h, funcdef_no=0, decl_uid=1799, cgraph_uid=0, symbol_order=0)

h ()
{
  struct S s;

   [100.00%]:
  s = f (); [return slot optimization]
  g ();
  s ={v} {CLOBBER};
  return;

}



;; Function j (j, funcdef_no=1, decl_uid=1803, cgraph_uid=1, symbol_order=1)

j ()
{
  struct S s;

   [100.00%]:
  s = f ();
  g ();
  s ={v} {CLOBBER};
  return;

}

[Bug tree-optimization/80937] redundant bcopy/memcpy/strcpy to a non-local object not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Martin Sebor  ---
A test case for the "unknown" destination is below.  In the memcpy case, the
second call is eliminated when the pointer arguments are declared restrict, but
in the strcpy case it doesn't matter.  I can't think of a reason why declaring
the caller's arguments restrict should affect the optimization: both memcpy's
and strcpy's arguments are declared restrict and both functions' behavior is
undefined when the copies overlap.

void memcpy_unknown (void *d, const void *s)
{
  __builtin_memcpy (d, s, 32);
  __builtin_memcpy (d, s, 32);// not eliminated
}

void strcpy_unknown (char* restrict d, const char* restrict s)
{
  __builtin_strcpy (d, s);
  __builtin_strcpy (d, s);// not eliminated
}


;; Function memcpy_unknown (memcpy_unknown, funcdef_no=0, decl_uid=1794,
cgraph_uid=0, symbol_order=0)

memcpy_unknown (void * d, const void * s)
{
   [100.00%]:
  __builtin_memcpy (d_2(D), s_3(D), 32);
  __builtin_memcpy (d_2(D), s_3(D), 32); [tail call]
  return;

}



;; Function strcpy_unknown (strcpy_unknown, funcdef_no=1, decl_uid=1798,
cgraph_uid=1, symbol_order=1)

strcpy_unknown (char * restrict d, const char * restrict s)
{
   [100.00%]:
  __builtin_strcpy (d_2(D), s_3(D));
  __builtin_strcpy (d_2(D), s_3(D)); [tail call]
  return;

}

[Bug tree-optimization/80937] New: redundant bcopy/memcpy/strcpy to a non-local object not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 80937
   Summary: redundant bcopy/memcpy/strcpy to a non-local object
not eliminated
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC eliminates redundant calls to bcopy and memcpy involving the same local
variable but doesn't eliminate redundant calls to the same two functions when
the target is the same global variable, or a pointer to some unknown variable. 
It does, however, eliminate calls to bzero and memset regardless of whether of
the storage duration of the target object.  This seems like a missed
optimization opportunity.

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
void sink (void*);

char a[33];

void memcpy_global (const void *s)
{
  __builtin_memcpy (a, s, sizeof a);
  __builtin_memcpy (a, s, sizeof a); 
  sink (a);
}

void bcopy_global (const void *s)
{
  __builtin_bcopy (s, a, sizeof a);
  __builtin_bcopy (s, a, sizeof a);   
  sink (a);
}

void memset_global (void)
{
  __builtin_memset (a, 0, sizeof a);
  __builtin_memset (a, 0, sizeof a);
  sink (a);
}

void bzero_global (void)
{
  __builtin_memset (a, 0, sizeof a);
  __builtin_memset (a, 0, sizeof a);
  sink (a);
}

void memcpy_local (const void *s)
{
  char a[33];
  __builtin_memcpy (a, s, sizeof a);
  __builtin_memcpy (a, s, sizeof a);
  sink (a);
}

void bcopy_local (const void *s)
{
  char a[33];
  __builtin_bcopy (s, a, sizeof a);
  __builtin_bcopy (s, a, sizeof a);
  sink (a);
}

void memset_local (void)
{
  char a[33];
  __builtin_memset (a, 0, sizeof a);
  __builtin_memset (a, 0, sizeof a);
  sink (a);
}

void bzero_local (void)
{
  char a[33];
  __builtin_memset (a, 0, sizeof a);
  __builtin_memset (a, 0, sizeof a);
  sink (a);
}


;; Function memcpy_global (memcpy_global, funcdef_no=0, decl_uid=1796,
cgraph_uid=0, symbol_order=1)

memcpy_global (const void * s)
{
   [100.00%]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})s_2(D)];
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})s_2(D)];
  sink (); [tail call]
  return;

}



;; Function bcopy_global (bcopy_global, funcdef_no=1, decl_uid=1799,
cgraph_uid=1, symbol_order=2)

bcopy_global (const void * s)
{
   [100.00%]:
  __builtin_bcopy (s_2(D), , 33);
  __builtin_bcopy (s_2(D), , 33);
  sink (); [tail call]
  return;

}



;; Function memset_global (memset_global, funcdef_no=2, decl_uid=1802,
cgraph_uid=2, symbol_order=3)

memset_global ()
{
   [100.00%]:
  __builtin_memset (, 0, 33);
  sink (); [tail call]
  return;

}



;; Function bzero_global (bzero_global, funcdef_no=9, decl_uid=1805,
cgraph_uid=3, symbol_order=4)

bzero_global ()
{
   [100.00%]:
  memset_global (); [tail call]
  return;

}



;; Function memcpy_local (memcpy_local, funcdef_no=4, decl_uid=1808,
cgraph_uid=4, symbol_order=5)

memcpy_local (const void * s)
{
  char a[33];

   [100.00%]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})s_2(D)];
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function bcopy_local (bcopy_local, funcdef_no=11, decl_uid=1812,
cgraph_uid=5, symbol_order=6)

bcopy_local (const void * s)
{
   [100.00%]:
  memcpy_local (s_2(D)); [tail call]
  return;

}



;; Function memset_local (memset_local, funcdef_no=6, decl_uid=1816,
cgraph_uid=6, symbol_order=7)

memset_local ()
{
  char a[33];

   [100.00%]:
  __builtin_memset (, 0, 33);
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function bzero_local (bzero_local, funcdef_no=13, decl_uid=1820,
cgraph_uid=7, symbol_order=8)

bzero_local ()
{
   [100.00%]:
  memset_local (); [tail call]
  return;

}

[Bug tree-optimization/80934] bzero should be assumed not to escape pointer argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-01
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a simple patch.

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

--- Comment #5 from Keith Marshall  ---
(In reply to Eric Botcazou from comment #3)
> Probably the FIXME in libada/configure.ac then:
> 
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
>   # Note that build=target is almost certainly the wrong test; FIXME
>   default_gnatlib_target="gnatlib-shared"
> else
>   default_gnatlib_target="gnatlib-plain"
> fi
> AC_SUBST([default_gnatlib_target])
> 
> No idea why this was put in the first place but the first test should go...

Thanks.  That seems likely.

I have autoconf-2.69, not 2.64 (which your configuration requires), so I found
the corresponding fragment within libada/configure itself, and adjusted that:

# Determine what to build for 'gnatlib'
if test ${enable_shared} = yes ; then
  default_gnatlib_target="gnatlib-shared"
else
  default_gnatlib_target="gnatlib-plain"
fi

With that in place, a clean configure and build does now produce:

gcc/ada/rts/libgnarl-6.dll
gcc/ada/rts/libgnat-6.dll

but there are no accompanying import libraries, (as there are for other DLLs,
produced for other languages in the GCC suite).  Definitely an improvement, but
perhaps not quite the entire solution.

[Bug tree-optimization/80936] New: bcmp, bcopy, and bzero not declared nonnull

[msebor at gcc dot gnu.org]

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

Bug ID: 80936
   Summary: bcmp, bcopy, and bzero not declared nonnull
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wnonnull option is expected to trigger a warning when a null pointer is
being passed to a function known to require a non-null argument.  GCC issues
this warning for functions like memcmp, memcpy, and memset but fails to issue
it for calls to the similar bcmp, bcopy, and bzero functions.  It looks like
the latter three built-ins are not declared with the nonnull attribute in
builtins.def.

$ cat z.c && gcc -O2 -S -Wall -Wextra z.c
void zero0 (void *p, unsigned n)
{
  if (p == 0)
__builtin_memset (p, 0, n);   // warning, good
}

void zero1 (void *p, unsigned n)
{
  if (p == 0)
__builtin_bzero (p, n);   // missing warning
}

void copy0 (void *p, const void *q, unsigned n)
{
  if (p == 0)
__builtin_memcpy (p, q, n);   // warning, good
}

void copy1 (void *p, const void *q, unsigned n)
{
  if (q == 0)
__builtin_memcpy (p, q, n);   // warning, good
}

void copy2 (void *p, const void *q, unsigned n)
{
  if (p == 0)
__builtin_bcopy (q, p, n);   // missing warning
}

void copy3 (void *p, const void *q, unsigned n)
{
  if (q == 0)
__builtin_bcopy (q, p, n);   // missing warning
}

int cmp0 (const void *p, const void *q, unsigned n)
{
  if (p == 0)
return __builtin_memcmp (p, q, n);   // warning, good
  return 0;
}

int cmp1 (const void *p, const void *q, unsigned n)
{
  if (q == 0)
return __builtin_memcmp (p, q, n);   // warning, good
  return 0;
}

int cmp2 (const void *p, const void *q, unsigned n)
{
  if (p == 0)
   return  __builtin_bcmp (p, q, n);   // missing warning
  return 0;
}

int cmp3 (const void *p, const void *q, unsigned n)
{
  if (q == 0)
   return  __builtin_bcmp (p, q, n);   // missing warning
  return 0;
}

z.c: In function ‘zero0’:
z.c:4:5: warning: argument 1 null where non-null expected [-Wnonnull]
 __builtin_memset (p, 0, n);   // warning, good
 ^~
z.c:4:5: note: in a call to built-in function ‘__builtin_memset’
z.c: In function ‘copy0’:
z.c:16:5: warning: argument 1 null where non-null expected [-Wnonnull]
 __builtin_memcpy (p, q, n);   // warning, good
 ^~
z.c:16:5: note: in a call to built-in function ‘__builtin_memcpy’
z.c: In function ‘copy1’:
z.c:22:5: warning: argument 2 null where non-null expected [-Wnonnull]
 __builtin_memcpy (p, q, n);   // warning, good
 ^~
z.c:22:5: note: in a call to built-in function ‘__builtin_memcpy’
z.c: In function ‘cmp0’:
z.c:40:12: warning: argument 1 null where non-null expected [-Wnonnull]
 return __builtin_memcmp (p, q, n);   // warning, good
^~
z.c:40:12: note: in a call to built-in function ‘__builtin_memcmp’
z.c: In function ‘cmp1’:
z.c:47:12: warning: argument 2 null where non-null expected [-Wnonnull]
 return __builtin_memcmp (p, q, n);   // warning, good
^~
z.c:47:12: note: in a call to built-in function ‘__builtin_memcmp’

[Bug c++/80935] New: [C++1z] incorrect error 'uninitialized variable in constexpr function' when conditionally declaring variable inside lambda inside template class

[vis...@royal-caliber.com]

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

Bug ID: 80935
   Summary: [C++1z] incorrect error 'uninitialized variable in
constexpr function' when conditionally declaring
variable inside lambda inside template class
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vis...@royal-caliber.com
  Target Milestone: ---

Created attachment 41445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41445=edit
preprocessed file generated by g++ -std=c++1z -v -save-temps

The following code fails to compile with g++ 7.1.0 with flags -std=c++1z. It
compiles with -std=c++14 or -std=c++11. I believe expected behavior is to
compile cleanly. clang-4.0 also has no problem with this code.


struct S
{
  int x;
  int y;
};


template 
struct Foo
{
  void foo()
  {
auto f = [](int x)
{
  if (x)
  {
S s;
s.x = 20;
s.y = 10;
(void) s;
  }
};
f(10);
  }
};



int main()
{
  Foo f;
  f.foo();
}


When compiled with g++ -std=c++1z, the following error is raised:

test.cpp: In instantiation of ‘Foo::foo():: [with T = int]’:
test.cpp:26:15:   required from ‘struct Foo::foo() [with T =
int]::’
test.cpp:26:10:   required from ‘void Foo::foo() [with T = int]’
test.cpp:45:9:   required from here
test.cpp:30:11: error: uninitialized variable ‘s’ in ‘constexpr’ function
 S s;
   ^
test.cpp:14:8: note: ‘struct S’ has no user-provided default constructor
 struct S
^
test.cpp:16:7: note: and the implicitly-defined constructor does not initialize
‘int S::x’
   int x;


The gcc build information is as follows:

Using built-in specs.
COLLECT_GCC=g++-7.1
COLLECT_LTO_WRAPPER=/home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/vishal/localbuild
--enable-languages=c,c++ --program-suffix=-7.1 --disable-multilib
Thread model: posix
gcc version 7.1.0 (GCC)
COLLECT_GCC_OPTIONS='-std=c++1z' '-Wall' '-Wextra' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64
-auxbase test -Wall -Wextra -std=c++1z -version -o test.s
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

[Bug tree-optimization/80934] New: bzero should be assumed not to escape pointer argument

[msebor at gcc dot gnu.org]

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

Bug ID: 80934
   Summary: bzero should be assumed not to escape pointer argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similarly to a call to memset, a call to bzero can be assumed not to escape its
pointer argument.  GCC takes advantage of this knowledge by optimizing function
h() below but it doesn't do the same for function g(), even though it could. 
See also bug 80933 for another missed optimization related to bzero.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void f (void);

void g (void)
{
  char d[32];
  __builtin_bzero (d, sizeof d);
  f ();
  if (*d != 0)
__builtin_abort ();
}

void h (void)
{
  char d[32];
  __builtin_memset (d, 0, sizeof d);
  f ();
  if (*d != 0)
__builtin_abort ();
}



;; Function g (g, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

g ()
{
  char d[32];
  char _1;

   [100.00%]:
  __builtin_bzero (, 32);
  f ();
  _1 = d[0];
  if (_1 != 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  d ={v} {CLOBBER};
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1799, cgraph_uid=1, symbol_order=1)

h ()
{
   [100.00%]:
  f (); [tail call]
  return;

}

[Bug tree-optimization/80933] redundant bzero/bcopy calls not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-31
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a simple patch.

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #8)
> Appears to happen between

Sorry,

> 241323

does indeed fail.

Didn't run the test often enough...

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
Appears to happen between

241323 OK
241368 (not OK).

Could this be r241367?

[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.1, 6.3.1, 7.1.1

--- Comment #8 from Segher Boessenkool  ---
Fixed on trunk so far.

[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Wed May 31 21:09:41 2017
New Revision: 248764

URL: https://gcc.gnu.org/viewcvs?rev=248764=gcc=rev
Log:
Fix changelog of previous commit, the correct version is:

PR target/80618
* config/rs6000/vector.md (*vector_uneq): Write the nor in the
splitter result in the canonical way.

Modified:
trunk/gcc/ChangeLog

[Bug tree-optimization/80933] New: redundant bzero/bcopy calls not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 80933
   Summary: redundant bzero/bcopy calls not eliminated
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC eliminates redundant calls to memcpy, memmove, and memset, but it doesn't
do the same for redundant calls to bcopy and bzero.  The tree-ssa-dse.c pass
that performs the former optimization is missing any handling for the latter
pair of functions.

$ cat t.c && gcc -O2 -S -Wall -Wall -fdump-tree-optimized=/dev/stdout t.c
void sink (void*);

void f (void)
{
  char a[32];
  __builtin_memset (a, 0, sizeof a);
  __builtin_memset (a, 0, sizeof a);   // eliminated as expected
  sink (a);
}

void g (void)
{
  char a[33];
  __builtin_bzero (a, sizeof a);
  __builtin_memset (a, 0, sizeof a);   // not eliminated but could be
  sink (a);
}

void h (void)
{
  char a[33];
  __builtin_bzero (a, sizeof a);
  __builtin_bzero (a, sizeof a);   // not eliminated but could be
  sink (a);
}


;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

f ()
{
  char a[32];

   [100.00%]:
  __builtin_memset (, 0, 32);
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1799, cgraph_uid=1, symbol_order=1)

g ()
{
  char a[33];

   [100.00%]:
  __builtin_bzero (, 33);
  __builtin_memset (, 0, 33);
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function h (h, funcdef_no=2, decl_uid=1803, cgraph_uid=2, symbol_order=2)

h ()
{
  char a[33];

   [100.00%]:
  __builtin_bzero (, 33);
  __builtin_bzero (, 33);
  sink ();
  a ={v} {CLOBBER};
  return;

}

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #20 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

--- Comment #21 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #20 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

--- Comment #21 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

[Bug sanitizer/80932] New: UBSAN: false positive as a result of distribution: c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2

[babokin at gmail dot com]

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

Bug ID: 80932
   Summary: UBSAN: false positive as a result of distribution:
c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc trunk rev248580, x86_64.

Transformation causing troubles: const1 * (const2 * var1 - const3 * var2) =>
const1*const2*var1 - const3*var2;

> cat f.cpp

#include 
signed char var_10 = 77;
long long int var_13 = 1547580415367384384LL;

long foo() {
  long a = -6 *
// 0xbf8a6c24aa342bc0 = -4644781160949077056
   (long(16636733186465668563ULL * var_13 ) -
// 0xd4cdd0f8c2df13cf = -3112602000603278385
long(678280911954875019ULL * var_10));
  return a;
}

int main () {
long a = foo ();
std::cout << a << std::endl;
return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp; ./a.out

f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 -
228867929910118694 cannot be represented in type 'long int'
9193074962074792026

[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Wed May 31 20:58:59 2017
New Revision: 248763

URL: https://gcc.gnu.org/viewcvs?rev=248763=gcc=rev
Log:
rs6000: Don't write "nor" as (not (ior () ())) (PR80618)

The canonical RTL for "nor" is (and (not ()) (not ())), and that is
indeed what we use in boolccv2df3_internal1.  So, the splitter for
*vector_uneq should use that form, not (not (ior () ())), which
does not match any pattern.


PR target/80618
* config/rs6000/rs6000.md (*vector_uneq): Write the nor in the
splitter result in the canonical way.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vector.md

[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335

[dev-zero at gentoo dot org]

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

--- Comment #1 from Tiziano Müller  ---
It seems like I managed to mess up the output when copy Here it is
again from gfortran-6.3.0:

$ LC_ALL=C gfortran -c move_alloc_ice.f90 
move_alloc_ice.f90:29:0:

   call move_alloc(temp, this%keywords_)

internal compiler error: in gimplify_expr, at gimplify.c:11335
0x8f57be gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:11335
0x8fdc92 gimplify_modify_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:4707
0x8f5141 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10386
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f482b gimplify_statement_list
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1537
0x8f482b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10803
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f7940 gimplify_bind_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1142
0x8f3a94 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10585
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f482b gimplify_statement_list
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1537
0x8f482b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10803
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f41ea gimplify_and_add(tree_node*, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:425
0x8f41ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10725
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f7940 gimplify_bind_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1142
0x8f3a94 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10585
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f80da gimplify_body(tree_node*, bool)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:11532
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug fortran/80931] New: ICE on move_alloc in gimplify_expr, at gimplify.c:11335

[dev-zero at gentoo dot org]

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

Bug ID: 80931
   Summary: ICE on move_alloc in gimplify_expr, at
gimplify.c:11335
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dev-zero at gentoo dot org
  Target Milestone: ---

Created attachment 41444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41444=edit
minimal example for an ICE on move_alloc for deferred-length character strings

Building the attached file using `LC_ALL=C gfortran -c move_alloc_ice.f90` with
gfortran-6.3.0(-p1) and I get:

move_alloce_ice.f90:29:0:

   call move_alloc(temp, this%keywords_)

internal compiler error: in gimplify_expr, at gimplify.c:11335
0x8f57be gimplify_expr(tree_node**, gimple**, gimple**, bool (*)
It doesn't seem to be a regression since 5.4.0 exhibits the same error:

$ LC_ALL=C gfortran-5.4.0 -c move_alloc_ice.f90 
move_alloc_ice.f90:29:0:

   call move_alloc(temp, this%keywords_)
 ^
internal compiler error: in gimplify_expr, at gimplify.c:9084
0x92511d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
   
/var/tmp/paludis/sys-devel-gcc-5.4.0-r2/work/gcc-5.4.0/gcc/gimplify.c:9084
0x922271 gimplify_modify_expr
/var/tmp/paludis/sys-devel-gcc-5.4.0-r2(tree_node*), int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:11335
0x8fdc92 gimplify_modify_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:4707
0x8f5141 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10386
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f482b gimplify_statement_list
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1537
0x8f482b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10803
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f7940 gimplify_bind_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1142
0x8f3a94 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10585
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f482b gimplify_statement_list
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1537
0x8f482b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10803
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f41ea gimplify_and_add(tree_node*, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:425
0x8f41ea gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10725
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f7940 gimplify_bind_expr
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:1142
0x8f3a94 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:10585
0x8f6da5 gimplify_stmt(tree_node**, gimple**)
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:5687
0x8f80da gimplify_body(tree_node*, bool)
   
/var/tmp/paludis/sys-devel-gcc-6.3.0/work/gcc-6.3.0/gcc/gimplify.c:11532
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It has something to do with the Deferred-length character strings because when
I use fixed length characters, the ICE is gone and the code works as intended
(sort of, but that's my problem). Reducing the example to a simple program
didn't exhibit the ICE either, despite the Deferred-length character strings.

It doesn't seem to be a regression since 5.4.0 exhibits the same error:

$ LC_ALL=C gfortran-5.4.0 -c move_alloc_ice.f90 
move_alloc_ice.f90:29:0:

   call move_alloc(temp, this%keywords_)
 ^
internal compiler error: in gimplify_expr, at gimplify.c:9084
0x92511d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
   

[Bug c++/80179] [6/7/8 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed May 31 18:53:57 2017
New Revision: 248758

URL: https://gcc.gnu.org/viewcvs?rev=248758=gcc=rev
Log:
PR c++/80179 - ICE with initialized flexible array member.

* constexpr.c (verify_ctor_sanity): Handle flexible array members.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary24.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug c++/69698] [meta-bug] flexible array members

[jason at gcc dot gnu.org]

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

Bug 80179 Summary: [6/7/8 Regression] ICE initializing a static local object 
with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80179

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/80179] [6/7/8 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed for 6.4/7.2/8

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug c++/66297] [C++14] [DR 1684] constexpr non-static member functions of non-literal types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 7.2.

[Bug c++/80605] [7/8 Regression] Bad is_standard_layout result with empty base classes

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed.

[Bug c++/80856] [7/8 Regression] ICE from template local overload resolution

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/80840] [7/8 Regression] ICE in convert_nontype_argument reference to double

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Botcazou  ---
> There is not.  I see records of (successful) ar commands to build the static
> libraries, but no evidence at all of even any attempt to build shared; the
> build was configured with --enable-shared, and even explicit
> --enable-shared=libada makes no difference ... no shared Ada libraries are
> built, while shared libraries for C, C++, Fortran, ObjC, and other
> supporting components are.

Probably the FIXME in libada/configure.ac then:

# Determine what to build for 'gnatlib'
if test $build = $target \
   && test ${enable_shared} = yes ; then
  # Note that build=target is almost certainly the wrong test; FIXME
  default_gnatlib_target="gnatlib-shared"
else
  default_gnatlib_target="gnatlib-plain"
fi
AC_SUBST([default_gnatlib_target])

No idea why this was put in the first place but the first test should go...

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
Yes, there is quite a bit of difference especially starting in the function
read_asc20hmm.  There are a whole bunch of if/else ifs there using strncmp.

[Bug c++/80840] [7/8 Regression] ICE in convert_nontype_argument reference to double

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:53:20 2017
New Revision: 248755

URL: https://gcc.gnu.org/viewcvs?rev=248755=gcc=rev
Log:
PR c++/80840 - ICE with constexpr and reference

* pt.c (convert_nontype_argument): Don't test whether a decl is
value-dependent when binding to a reference.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/template/ref10.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/80856] [7/8 Regression] ICE from template local overload resolution

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:53:12 2017
New Revision: 248754

URL: https://gcc.gnu.org/viewcvs?rev=248754=gcc=rev
Log:
PR c++/80856 - ICE with local extern in template

* semantics.c (finish_call_expr): Replace a local extern overload
set in a template with the IDENTIFIER_NODE.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/template/local-fn2.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/semantics.c

[Bug c++/80605] [7/8 Regression] Bad is_standard_layout result with empty base classes

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:53:06 2017
New Revision: 248753

URL: https://gcc.gnu.org/viewcvs?rev=248753=gcc=rev
Log:
PR c++/80605 - __is_standard_layout and empty base

* class.c (check_bases): Ignore empty bases.
* class.c (check_bases): Use DECL_FIELD_IS_BASE.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/is_std_layout1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/is_std_layout2.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/class.c

[Bug c++/66297] [C++14] [DR 1684] constexpr non-static member functions of non-literal types

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:52:58 2017
New Revision: 248752

URL: https://gcc.gnu.org/viewcvs?rev=248752=gcc=rev
Log:
PR c++/66297, DR 1684 - literal class and constexpr member fns

* constexpr.c (is_valid_constexpr_fn): Only complain about
non-literal enclosing class in C++11.
* class.c (finalize_literal_type_property): Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-dr1684.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/class.c
branches/gcc-7-branch/gcc/cp/constexpr.c
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-data1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-diag1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-diag3.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-neg1.C

[Bug c++/80179] [6/7/8 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:52:44 2017
New Revision: 248751

URL: https://gcc.gnu.org/viewcvs?rev=248751=gcc=rev
Log:
PR c++/80179 - ICE with initialized flexible array member.

* constexpr.c (verify_ctor_sanity): Handle flexible array members.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/flexary24.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||shane at paga dot moe

--- Comment #9 from Martin Sebor  ---
*** Bug 80924 has been marked as a duplicate of this bug. ***

[Bug c/80924] [7/8 Regression] Value range prediction affected by optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Sebor  ---
The full output is the following (please include the full diagnostic in bug
reports, not just the notes):

a.c:4:34: warning: ‘snprintf’ output may be truncated before the last format
character [-Wformat-truncation=]
 snprintf(buf,5,"-%d",idx);
^
a.c:4:9: note: ‘__builtin_snprintf’ output between 3 and 6 bytes into a
destination of size 5
 snprintf(buf,5,"-%d",idx);
 ^

Compiling the test case with -fdump-tree-printf-return-value shows the
following:

a.c:4: __builtin_snprintf: objsize = 5, fmtstr = "-%d"
  Directive 1 at offset 0: "-", length = 1
Result: 1, 1, 1, 1 (1, 1, 1, 1)
  Directive 2 at offset 1: "%d"
Result: 1, 4, 4, 4 (2, 5, 5, 5)
  Directive 3 at offset 3: "", length = 1

(The Result: consists of the minimum, likely, maximum, and unlikely maximum
number of bytes output by each directive, with running totals for the four
counters in parentheses.)

The VR_RANGE reported by get_range_info() to the warning pass is [0, 1000].

(gdb) p min
$4 = { = {val = {0, 1000, 140737488345088}, len = 1,
precision = 32}, static is_sign_extended = true}
(gdb) p max
$5 = { = {val = {1000, 140737221856280, -1}, len = 1,
precision = 32}, static is_sign_extended = true}

I suspect the root cause is the same as in bug 78969 and this is a dupe of the
latter.  (Please reopen this bug if you think otherwise.)

*** This bug has been marked as a duplicate of bug 78969 ***

[Bug c++/80840] [7/8 Regression] ICE in convert_nontype_argument reference to double

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed May 31 17:11:17 2017
New Revision: 248749

URL: https://gcc.gnu.org/viewcvs?rev=248749=gcc=rev
Log:
PR c++/80840 - ICE with constexpr and reference

* pt.c (convert_nontype_argument): Don't test whether a decl is
value-dependent when binding to a reference.

Added:
trunk/gcc/testsuite/g++.dg/template/ref10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[lists at coryfields dot com]

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

Cory Fields  changed:

   What|Removed |Added

 CC||lists at coryfields dot com

--- Comment #9 from Cory Fields  ---
I assume based on the milestone that this will be backported to 7.2?

Boost's aligned_storage is affected as well, causing floods of warnings from
several of its containers (multi_index, at least) which use it.

[Bug middle-end/80930] New: REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

[sirl at gcc dot gnu.org]

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

Bug ID: 80930
   Summary: REE pass causes high memory usage via df_mir_alloc()
with ASAN+UBSAN turned on
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

We have an inhouse C source where the memory usage is excessive (> 88GB, then
OOM killed) with GCC-7/x86_64 (7.1.1@r248575). With GCC-6 (6.3.1@r248575) the
memory usage is a bit better, roughly 58GB.
When stopped in gdb shortly before OOM, the backtrace looks like this

(gdb) bt
#0  bitmap_elt_insert_after (indx=1076, elt=,
head=0x7fff3aa62bd0) at ../../gcc/bitmap.c:409
#1  bitmap_set_range(bitmap_head*, unsigned int, unsigned int) () at
../../gcc/bitmap.c:1233
#2  0x00c9827b in df_mir_alloc(bitmap_head*) () at
../../gcc/df-problems.c:1914
#3  0x00c8d454 in df_analyze_problem (n_blocks=299166,
postorder=0x17168b2e0, blocks_to_consider=, dflow=0x16b830fb0)
at ../../gcc/df-core.c:1165
#4  df_analyze_1 () at ../../gcc/df-core.c:1226
#5  df_analyze() () at ../../gcc/df-core.c:1294
#6  0x0109ab81 in find_and_remove_re () at ../../gcc/ree.c:1216
#7  rest_of_handle_ree () at ../../gcc/ree.c:1310
#8  (anonymous namespace)::pass_ree::execute(function*) () at
../../gcc/ree.c:1338
#9  0x00deace1 in execute_one_pass(opt_pass*) () at
../../gcc/passes.c:2465
#10 0x0062c20c in execute_pass_list_1 (pass=0x1c94570) at
../../gcc/passes.c:2554
#11 0x0062c1dc in execute_pass_list_1 (pass=0x1c943f0) at
../../gcc/passes.c:2555
#12 execute_pass_list_1 (pass=0x1c931d0) at ../../gcc/passes.c:2555
#13 execute_pass_list (fn=, pass=) at
../../gcc/passes.c:2565
#14 0x010fcb0d in cgraph_node::expand (this=0x7fffe8ccbcf0) at
../../gcc/cgraphunit.c:2042
#15 expand_all_functions () at ../../gcc/cgraphunit.c:2178
#16 symbol_table::compile() () at ../../gcc/cgraphunit.c:2535
#17 0x00c7973f in symbol_table::finalize_compilation_unit() () at
../../gcc/cgraphunit.c:2625
#18 0x0113b6b0 in compile_file() () at ../../gcc/toplev.c:492
#19 0x00bd2afb in do_compile () at ../../gcc/toplev.c:2000
#20 toplev::main(int, char**) () at ../../gcc/toplev.c:2134
#21 0x00bd439b in main (argc=177, argv=0x7fffcbd8) at
../../gcc/main.c:39

Using -fno-ree brings down memory usage to 7GB (GCC-7) and 5GB (GCC-6).
The relevant options for the compile are:
 -g -O2 -version -fsanitize=address -fstack-protector-strong
-fsanitize=undefined -fsanitize=bounds-strict -fno-omit-frame-pointer
-fno-common -ffunction-sections -fdata-sections -faggressive-loop-optimizations

I can provide more information and do other testing, but a public testcase will
likely be impossible.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
I see them still for r248738.

My configure is pretty simple:

--enable-languages=c,fortran,c++ --with-cpu=power8 --disable-bootstrap

and it's the same on both BE and LE.  I am using binutils 2.27 though I am not
sure that would matter.

[Bug tree-optimization/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #5 from Segher Boessenkool  ---
I have a patch.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
I quickly built trunk without bootstrap on power7 BE
("--enable-languages="c,c++,fortran" --disable-multilib --disable-bootstrap")
and still get no new fails.  Do I need other build parameters?  Meanwhile I got
access to a power8 LE machine and will check there.

r248678 definitely introduced fails but r248680 should actually get rid of
them.  I can't confirm for every one of these but [6/6] was made specifically
to address fails on power.  Are all of them still present after r248680?

[Bug tree-optimization/80898] [8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Created attachment 41443
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41443=edit
First fix

This patch fixes the issue, but I think I can now think of a slightly
more complicated scenario in which it would not be enough, I will try
to come up with a testcase and fix it too.

[Bug middle-end/80701] Option for generating link symbol for functions removed by DCE

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
While the statements after a RETURN are still there in the dump file *.007t.eh,
they are removed at *.008t.cfg

...
Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:  
undefined ();
...

So I am convinced that this PR should be marked as a duplicate of pr46476. If
for "good" reason (I don't understand) you want a special warning for procedure
removal, I think this should be asked in pr46476.

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to seurer from comment #5)
> The problem appears to be in compiling hmmio.c.  If I compile everything
> else with a compiler built from r248447 and hmmio.c from a compiler built
> with r248446 then the 456.hmmer test works.
> 
> (this is on powerpc64 LE)

Is there a meaningful difference in the tree dumps?

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from seurer at gcc dot gnu.org ---
Starting with r248678 these are the tests that fail on powerpc64 LE and BE
(power6,7, and 8):


FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++11  scan-tree-dump-times slp1 "basic
block vectorized" 1
FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++14  scan-tree-dump-times slp1 "basic
block vectorized" 1
FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++98  scan-tree-dump-times slp1 "basic
block vectorized" 1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect
"vectorization not profitable" 1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
"Alignment of access forced using peeling" 2
FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times vect
"Alignment of access forced using peeling" 2
FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-28.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-28.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-33-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-33-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 0
FAIL: gcc.dg/vect/vect-70.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-70.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-87.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-87.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-88.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-88.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-91.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 3
FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 3
FAIL: gcc.dg/vect/vect-93.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 1
FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 1
FAIL: gfortran.dg/vect/vect-3.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 1
FAIL: gfortran.dg/vect/vect-3.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 1
FAIL: gfortran.dg/vect/vect-4.f90   -O   scan-tree-dump-times vect "Alignment
of access forced using peeling" 1
FAIL: gfortran.dg/vect/vect-4.f90   -O   scan-tree-dump-times vect "Vectorizing
an unaligned access" 1

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

--- Comment #2 from Keith Marshall  ---
(In reply to Eric Botcazou from comment #1)
> Look into the compilation log, there must be an error reported in this case.

There is not.  I see records of (successful) ar commands to build the static
libraries, but no evidence at all of even any attempt to build shared; the
build was configured with --enable-shared, and even explicit
--enable-shared=libada makes no difference ... no shared Ada libraries are
built, while shared libraries for C, C++, Fortran, ObjC, and other supporting
components are.

[Bug middle-end/80926] [7/8 Regression] longjmp not treated as noreturn during CFG build

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> Were they supposed to be user visible or can we "rename" those?

They are user-visible and exercised in the C testsuite.

[Bug middle-end/80926] [7/8 Regression] longjmp not treated as noreturn during CFG build

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> We do have __builtin_longjmp/setjmp but those are not 1:1 longjmp/setjmp so
> adding a standard C builtin for longjmp and setjmp is difficult...  Eric, is
> that correct?

Yes, __builtin_longjmp/setjmp are something else.

[Bug middle-end/80926] [7/8 Regression] longjmp not treated as noreturn during CFG build

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 31 May 2017, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80926
> 
> --- Comment #3 from Eric Botcazou  ---
> > We do have __builtin_longjmp/setjmp but those are not 1:1 longjmp/setjmp so
> > adding a standard C builtin for longjmp and setjmp is difficult...  Eric, is
> > that correct?
> 
> Yes, __builtin_longjmp/setjmp are something else.

Were they supposed to be user visible or can we "rename" those?

[Bug middle-end/80929] New: [7/8 Regression] Division with constant no more optimized to mult highpart

[gjl at gcc dot gnu.org]

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

Bug ID: 80929
   Summary: [7/8 Regression] Division with constant no more
optimized to mult highpart
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Since PR79665, division with known denominator are no more optimized to
__umulhisi3 but transfomed to an expensive signed division instead.

unsigned scale255 (unsigned val)
{
return val / 255;
}

$ avr-gcc -O2 -mmcu=atmega328 -S ...

Reason is that PR79655 uses rtlanal.c::seq_cost() to compute the cost of
(un)signed division, and seq_cost assumes anything that's not a single_set has 
the very low cost of 1.

However avr BE, represents division as a PARALLEL, not as a single_set, i.e.
something like:

(insn 14 13 0 (parallel [
(set (reg:HI 52)
(div:HI (reg:HI 47)
(reg:HI 54)))
(set (reg:HI 53)
(mod:HI (reg:HI 47)
(reg:HI 54)))
(clobber (reg:QI 21 r21))
(clobber (reg:HI 22 r22))
(clobber (reg:HI 24 r24))
(clobber (reg:HI 26 r26))
]) "scale.c":7 -1
 (nil))

[Bug testsuite/80580] GIMPLEFE ICE on invalid code (fuzz testing)

[miyuki at gcc dot gnu.org]

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

--- Comment #5 from Mikhail Maltsev  ---
Author: miyuki
Date: Wed May 31 13:47:51 2017
New Revision: 248738

URL: https://gcc.gnu.org/viewcvs?rev=248738=gcc=rev
Log:
GIMPLEFE: Handle missing labels in goto statements

gcc/c/

PR testsuite/80580
* gimple-parser.c (c_parser_gimple_if_stmt): Check for empty labels.

gcc/testsuite/

PR testsuite/80580
* gcc.dg/gimplefe-error-7.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gimplefe-error-7.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #3 from rdapp at linux dot vnet.ibm.com ---
Strange, my tests didn't show new failures on Power7. I'll have a look, perhaps
the build settings were wrong.

[Bug tree-optimization/80928] SLP vectorization does not handle induction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-31
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug middle-end/80926] [7/8 Regression] longjmp not treated as noreturn during CFG build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
   Priority|P3  |P2
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |7.2

--- Comment #2 from Richard Biener  ---
Caused by r239092 (in itself a good change).

We do have __builtin_longjmp/setjmp but those are not 1:1 longjmp/setjmp so
adding a standard C builtin for longjmp and setjmp is difficult...  Eric, is
that correct?

[Bug tree-optimization/80928] New: SLP vectorization does not handle induction

[rguenth at gcc dot gnu.org]

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

Bug ID: 80928
   Summary: SLP vectorization does not handle induction
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

int a[1024];
void foo (int n)
{
  for (int i = 0; i < 1020; i += 5)
{
  a[i] = i;
  a[i+1] = i;
  a[i+2] = i;
  a[i+3] = i;
  a[i+4] = i;
}
}

is not vectorized.

t.c:4:3: note: === vect_analyze_slp ===
t.c:4:3: note: Build SLP for a[i_17] = i_17;
t.c:4:3: note: Build SLP for a[_1] = i_17;
t.c:4:3: note: Build SLP for a[_2] = i_17;
t.c:4:3: note: Build SLP for a[_3] = i_17;
t.c:4:3: note: Build SLP for a[_4] = i_17;
t.c:4:3: note: vect_is_simple_use: operand i_17
t.c:4:3: note: def_stmt: i_17 = PHI 
t.c:4:3: note: type of def: induction
t.c:4:3: note: Build SLP failed: illegal type of def i_17

that's because we do not handle inductions (neither during SLP discovery
nor later during code-gen).

  /* Check the types of the definitions.  */
  switch (dt)
{
case vect_constant_def:
case vect_external_def:
case vect_reduction_def:
  break;

case vect_internal_def:
  oprnd_info->def_stmts.quick_push (def_stmt);
  break;

default:
  /* FORNOW: Not supported.  */
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "Build SLP failed: illegal type of def ");
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM, oprnd);
  dump_printf (MSG_MISSED_OPTIMIZATION, "\n");
}

  return -1;
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/67683] Missed vectorization: shifts of an induction variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||35226

--- Comment #4 from Richard Biener  ---
Really similar to PR35226 - we do not handle inductions that are not SCEV
analyzable.  There's multiplications here's shifts / divisions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35226
[Bug 35226] Induction with multiplication are not vectorized

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
*** Bug 80927 has been marked as a duplicate of this bug. ***

[Bug testsuite/80927] vectorizer failures on ppc64le target

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Dup.

*** This bug has been marked as a duplicate of bug 80925 ***

[Bug testsuite/80927] New: vectorizer failures on ppc64le target

[marxin at gcc dot gnu.org]

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

Bug ID: 80927
   Summary: vectorizer failures on ppc64le target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: ppc64le-redhat-linux
Target: ppc64le-redhat-linux
 Build: ppc64le-redhat-linux

Starting from r248678 I see new vectorizer failures:

FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times vect
"Alignment of access forced using peeling" 2
FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
"Alignment of access forced using peeling" 2
FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 0
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 3
FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 1
FAIL: gcc.dg/vect/vect-28.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-28.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-33-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-33-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-70.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-70.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 0
FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
FAIL: gcc.dg/vect/vect-87.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-87.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-88.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 0
FAIL: gcc.dg/vect/vect-88.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 1
FAIL: gcc.dg/vect/vect-91.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Alignment of access forced using peeling" 3
FAIL: gcc.dg/vect/vect-93.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"Vectorizing an unaligned access" 1

[Bug middle-end/80926] [7/8 Regression] longjmp not treated as noreturn during CFG build

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-31
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New.

[Bug middle-end/80926] New: [7/8 Regression] longjmp not treated as noreturn during CFG build

[dje at gcc dot gnu.org]

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

Bug ID: 80926
   Summary: [7/8 Regression] longjmp not treated as noreturn
during CFG build
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

GCC 6 didn't add the fallthru edge and thus properly treated longjmp as
noreturn during CFG build.

void longjmp(); void __attribute__((noreturn)) foo () { longjmp (); }

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-31
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New.

[Bug tree-optimization/80925] New: [8 Regression] vect peeling failures

[dje at gcc dot gnu.org]

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

Bug ID: 80925
   Summary: [8 Regression] vect peeling failures
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: rdapp at linux dot vnet.ibm.com, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

The recent changes to the vect peeling cost model have introduced numerous
failures to powerpc vect testsuite.

[Bug c/80924] [7/8 Regression] Value range prediction affected by optimization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|Value range prediction  |[7/8 Regression] Value
   |affected by optimization|range prediction affected
   ||by optimization

--- Comment #2 from Martin Liška  ---
Started with r240298.

[Bug libstdc++/80893] std::vector creation dereferences null pointer

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed May 31 12:41:45 2017
New Revision: 248734

URL: https://gcc.gnu.org/viewcvs?rev=248734=gcc=rev
Log:
PR libstdc++/80893 Fix null dereference in vector

PR libstdc++/80893
* include/bits/stl_bvector.h (vector::_M_initialize): Avoid
null pointer dereference when size is zero.
* testsuite/23_containers/vector/bool/80893.cc: New.
* testsuite/util/testsuite_allocator.h (PointerBase::PointerBase):
Add non-explicit constructor from nullptr.
(PointerBase::derived() const): Add const-qualified overload.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/bool/80893.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_bvector.h
trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h

[Bug target/79155] Typo in cpuid.h comment

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.1.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far, queued for backporting.

[Bug target/80880] internal compiler error: in ix86_expand_builtin

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed May 31 12:09:51 2017
New Revision: 248731

URL: https://gcc.gnu.org/viewcvs?rev=248731=gcc=rev
Log:
2017-05-31  Richard Biener  

PR target/80880
* config/i386/i386.c (ix86_expand_builtin): Remove assert
for arg being an SSA name when expanding IX86_BUILTIN_BNDRET.

* gcc.target/i386/pr80880.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr80880.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80880] internal compiler error: in ix86_expand_builtin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[rguenth at gcc dot gnu.org]

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

Bug 80880 Summary: internal compiler error: in ix86_expand_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80880

   What|Removed |Added

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

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #17 from Daniel Santos  ---
> (In reply to Rainer Orth from comment #15)
>> Created attachment 41404 [details]
>> Switch ms-sysv to more regular dg functions
>
> You may be surprised to learn how many faulty assumptions you may have about
> how the gcc test harness works and manages parallelization.  I did try your
> patch and it didn't work.  I didn't go too deeply into trying to analyze the

I didn't even bother to try a parallel run before getting basic
functionality right!  Should have mentioned that explicitly.

> failures, but if you call dg-runtest, you are using gcc's hack-daptation of
> parallelization.  However, your patch doesn't remove *my* hack-daptation of
> parallelization, so we end up with two different parallelization schemes that
> step on each other's toes.
>
> Another problem with the already present parallelization is that it bunches
> tests into groups of 10 per job which will perform very poorly for these 
> tests.
>
> (https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/lib/gcc-defs.exp#L170).
>  I presume this is to reduce disk I/O and it makes sense from that standpoint
> (I don't want to know what it would take to get a ramdisk/tmpfs in a
> platform-neutral fashion.)

My basic point still stands: running your ms-sysv tests sequentially
takes just a few minutes even on an old and (by today's standards) slow
CPU, so there's absolutely no point investing lots of effort and
complexity to parallelize what already runs adequately fast sequentially!

> However, I'm learning a little more about how the test harness works, and it
> MAY be possible to call gcc_parallel_test_enable 0 at the start of ms-sysv.exp
> and be able to use all of the built-in dg-runtest, et. al. functions!  If I 
> can
> get this to work (and not break something else in the process), then we may be
> on to a pathway to clean up ms-sysv.exp a little bit -- that is except for a
> few outstanding (possibly surmountable) issues:
>
> 1.) Can the default time-out of 5 minutes be changed?  I need 20 minutes for
> the slowest processors and a whole HOUR when full tests are enabled.

Sure it can: for one there are dg-timeout (and preferably dg-timeout
factor) per testcase.  I still wonder why you'd need that, though: if
all your tests together take no more than a few minutes, why would you
need to increase the timeout at all?  Which processor would this be that
takes 20 minutes or even an hour to run the tests *and complete all
other tests well within the five minute timeout*?

In fact, every test that takes more than about a minute on a resonably
current CPU is frowned upon because under parallel testing/load such
tests tend to run into the timeout.

If your tests regularly exceed the timeout, there's something wrong with
them: you need to split the so individual tests complete within the
minute just mentioned.

If really necessary in a setup, it is possible to set
board_info(unix,gcc,timeout) in a global site.exp file, e.g. to deal
with really slow/ancient systems.  This would be necessary without your
test anyway.

> 2.) The test description should include the generator flags and not just the
> CFLAGS.  Is that possible from dg-runtest, et. al.?  I suppose it's always
> possible to add them to CFLAGS with -DGEN_FLAGS="-p0-12" as a hack.

That's a requirement actually: the summary lines for different runs of a
test must differ so you can tell them apart if one of them fails.  How
this is done in the end is primarily a cosmetic issue, though.

> I guess you can see why I said that I was "semi-content" to leave it like it
> is. :)  But I'm also glad to better understand how the test harness
> parallelization works.  Maybe it's possible to make a small modification to
> dg-defs.exp to get it to divvy out a single test per job instead of 10.

As I said: first get the sequential execution right and then, if really
really necessary (and I want proof for that) look at parallelization.
It may well be that the initial solution is to restrict the number and
size of tests run by everyone.  After all, this is just for a niche
feature of a single architecture/OS and there's no point in everyone
testing on x86 having to pay a massive penalty for that.

Rainer

[Bug target/79155] Typo in cpuid.h comment

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed May 31 11:40:13 2017
New Revision: 248729

URL: https://gcc.gnu.org/viewcvs?rev=248729=gcc=rev
Log:
Fix typo in a comment in cpuid.h (PR target/79155).

2017-05-31  Martin Liska  

PR target/79155
* config/i386/cpuid.h: Fix typo in a comment in cpuid.h.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #7 from James Greenhalgh  ---
Thanks for your help!

[Bug c/80924] Value range prediction affected by optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-31
 CC||msebor at gcc dot gnu.org
Version|unknown |7.1.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The warning is clearly wrong.  '-999\0' is only 5 chars.

   [99.00%]:
  # RANGE [0, 999] NONZERO 1023
  # idx_11 = PHI 
  # USE = nonlocal null { D.2288 } (escaped)
  # CLB = nonlocal null { D.2288 } (escaped)
  snprintf (, 5, "-%d", idx_11);

so it even gets correct range info... (not before VRP2 though)

[Bug c/80924] New: Value range prediction affected by optimization

[shane at paga dot moe]

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

Bug ID: 80924
   Summary: Value range prediction affected by optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shane at paga dot moe
  Target Milestone: ---

Created attachment 41442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41442=edit
The testing code

This simple c code can successfully compiled in -Wall -Werror
But not in -O2 -Wall -Werror
Here is the output:
 ‘snprintf’ output between 3 and 6 bytes into a destination of size 5

[Bug c++/80896] [[nodiscard]] is ignored for functions returning references

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-31
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Looks like a call of maybe_warn_nodiscard is missing from the main
convert_to_void switch.

[Bug tree-optimization/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.1.1
   Target Milestone|6.4 |7.2
  Known to fail||6.3.1, 7.1.0

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Created attachment 41441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41441=edit
patch

Patch I am testing, I finally managed to convince tailrecursion optimization to
handle the case in gcc.dg/tree-ssa/tailrecursion-6.c after the fix to the
folding.

If testing goes well I'll commit this to trunk.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to Dmitry Babokin from comment #16)
> Here's another test case with a contrary example, where a variable gets
> pulled into the braces and it also causes false positive. Transformation is:
> const1 * (const2 * var1 - const3 * var2) => const1*const2*var1 - const3*var2;
> 
> > cat f.cpp
> #include 
> signed char var_10 = 77;
> long long int var_13 = 1547580415367384384LL;
> 
> long foo() {
>   long a = -6 *
> // 0xbf8a6c24aa342bc0 = -4644781160949077056
>(long(16636733186465668563ULL * var_13 ) -
> // 0xd4cdd0f8c2df13cf = -3112602000603278385
> long(678280911954875019ULL * var_10));
>   return a;
> }
> 
> int main () {
> long a = foo ();
> std::cout << a << std::endl;
> return 0;
> }
> 
> > g++ -fsanitize=undefined -O0 f.cpp; ./a.out
> f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 -
> 228867929910118694 cannot be represented in type 'long int'
> 9193074962074792026
> 
> If it's unrelated issue, let me know and I'll file a separate bug for it.

Yes, that's an unrelated issue -- extract_muldiv likely.

[Bug tree-optimization/78869] [6/7/8 Regression] Strange __builtin_memcpy optimisations

[jamborm at gcc dot gnu.org]

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

Bug 80293 Summary: [6/7 Regression] unnecessary code at -O2 (-O1 is fine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293

   What|Removed |Added

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

[Bug tree-optimization/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Wed May 31 08:45:23 2017
New Revision: 248724

URL: https://gcc.gnu.org/viewcvs?rev=248724=gcc=rev
Log:
[PR 80293] Dont totally-scalarize char arrays

2017-05-31  Martin Jambor  

Backport from mainline
2017-04-24  Martin Jambor  

PR tree-optimization/80293
* tree-sra.c (scalarizable_type_p): New parameter const_decl, make
char arrays not totally scalarizable if it is false.
(analyze_all_variable_accesses): Pass correct value in the new
parameter.  Add a statistics counter.

testsuite/
* g++.dg/tree-ssa/pr80293.C: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/tree-ssa/pr80293.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-sra.c

[Bug tree-optimization/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Fixed on trunk and backported to 7.2.

[Bug tree-optimization/80906] [7 Regression] ICE in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2094

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |copy_loop_close_phi_args,   |copy_loop_close_phi_args,
   |at  |at
   |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple.
   |c:2094  |c:2094

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

[Bug c/80919] [7/8 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-31
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We do not track warning options (and thus optimize pragmas /
attributes) across LTO because they are not saved in the function specific
optimization flag section.

[Bug tree-optimization/80906] [7/8 Regression] ICE in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2094

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed May 31 07:09:21 2017
New Revision: 248722

URL: https://gcc.gnu.org/viewcvs?rev=248722=gcc=rev
Log:
2017-05-31  Richard Biener  

PR tree-optimization/80906
* graphite-isl-ast-to-gimple.c (copy_loop_close_phi_nodes): Get
and pass through iv_map.
(copy_bb_and_scalar_dependences): Adjust.
(translate_pending_phi_nodes): Likewise.
(copy_loop_close_phi_args): Handle code-generating IVs instead
of ICEing.

* gcc.dg/graphite/pr80906.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr80906.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/78049] [7 Regression] ICE in gcc/lto-streamer-in.c:901 when building Firefox with LTO and -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|7.0 |5.5