[Bug c++/81032] New: [5/6/7/8 Regression] ICE with lambda and broken constexpr

[reichelt at gcc dot gnu.org]

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

Bug ID: 81032
   Summary: [5/6/7/8 Regression] ICE with lambda and broken
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 5.2.0
(when compiled with -std=c++1y):


template constexpr void foo(T t)
{
  constexpr int i = t;
  [=](auto){ return i; }(0);
}

void bar()
{
  foo(0);
}


bug.cc: In instantiation of 'constexpr void foo(T) [with T = int]':
bug.cc:9:8:   required from here
bug.cc:3:17: error: 't' is not a constant expression
   constexpr int i = t;
 ^
bug.cc: In instantiation of 'foo(T):: [with auto:1 = int; T =
int]':
bug.cc:4:25:   required from 'constexpr void foo(T) [with T = int]'
bug.cc:9:8:   required from here
bug.cc:4:24: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3003
   [=](auto){ return i; }(0);
^
0x63fa91 finish_member_declaration(tree_node*)
../../gcc/gcc/cp/semantics.c:3000
0x8b99bf add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/gcc/cp/lambda.c:591
0x8b9f6e add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/lambda.c:653
0x95bd2b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17821
0x944bf4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16521
0x943a23 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15781
0x9447d6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15998
0x9447d6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15998
0x971e2b instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:22963
0x89414e maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:4994
0x896248 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5094
0x7f6bcc build_over_call
../../gcc/gcc/cp/call.c:8102
0x804a03 build_op_call_1
../../gcc/gcc/cp/call.c:4509
0x804a03 build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4535
0x98d17d finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2496
0x95bae3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17414
0x944bf4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16521
0x943100 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15785
0x94315f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15771
0x9447d6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15998
Please submit a full bug report, [etc.]

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #4 from Yuri Gribov  ---
(In reply to rguent...@suse.de from comment #3)
> The various patches to
> lower bitfield accesses made this work automagically.  Thus this
> PR is probably a dup of some other(s).

Interestingly, a slightly different code works fine:
  return s->b || s->c;  // || instead of |
This happens because it compiles to
  (s->b != 0) || (s->c != 0)
Each component is converted to BIT_FIELD_REF by optimize_bit_field_compare and
results are folded to a single BIT_AND.

With original use-case this does not work because we don't know that result
will be NE-ed when trying to fold IOR in fold_binary_loc.

Ideally we want to detect generic patterns like
  (s->f1 | s->f2 | ... | s->fN | other unrelated conds) != 0  // Or &, or ==
sort fi's to groups according to their memory location and optimize from there.
This should probly go to reassoc? Or better keep it in folder?

[Bug target/80862] [x86] Wrong rounding results for some test cases

[julia.koval at intel dot com]

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

--- Comment #3 from Yulia Koval  ---
Fixed by https://gcc.gnu.org/viewcvs/gcc?view=revision=249009

[Bug middle-end/81030] New: ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[su at cs dot ucdavis.edu]

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

Bug ID: 81030
   Summary: ICE on valid code at -O1 (only) on x86_64-linux-gnu:
verify_flow_info failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a recent regression. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170609 (experimental) [trunk revision 249045] (GCC)
$
$ gcc-trunk -O0 small.c
$
$ gcc-trunk -O1 small.c
small.c: In function ‘main’:
small.c:26:1: error: verify_flow_info: REG_BR_PROB does not match cfg 3663 7327
 }
 ^
during RTL pass: expand
small.c:26:1: internal compiler error: verify_flow_info failed
0x7d9956 verify_flow_info()
../../gcc-source-trunk/gcc/cfghooks.c:259
0x1323c20 checking_verify_flow_info
../../gcc-source-trunk/gcc/cfghooks.h:198
0x1323c20 try_optimize_cfg
../../gcc-source-trunk/gcc/cfgcleanup.c:3039
0x1323c20 cleanup_cfg(int)
../../gcc-source-trunk/gcc/cfgcleanup.c:3203
0x7d6566 execute
../../gcc-source-trunk/gcc/cfgexpand.c:6485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$





void __assert_fail (const char *, const char *, unsigned int, const char *);

int a, b, c, d, e, f, h;
unsigned char g;

int main ()
{ 
  int i, *j = 
  if (a)
{ 
  if (h)
{ 
  int **k = 
  d = 0;
  *k = 
}
  else
for (b = 0; b > -28; b = g)
  ;
  c || !j ? : __assert_fail ("c || !j", "small.c", 20, "main");
  if (f)
for (i = 0; i < 1; i++)
  ;
}
  return 0;
}

[Bug other/81029] New: Compiling sketch with arduinodroid

[bcl45 at live dot fr]

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

Bug ID: 81029
   Summary: Compiling sketch with arduinodroid
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bcl45 at live dot fr
  Target Milestone: ---

Created attachment 41512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41512=edit
Compilation log

Hi
My sketch run correctly on the laptop.
But not on my smartphone Samsung S7 with arduinodroid.
Compilation error.
See attached file

Thanks

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
After a lot of head scratching I think I am changing my mind on this one.

If one tries to assign to a real variable as in:

program test_b_write_dt_mod

   use :: B_write_dt_mod
   implicit none

   type(B_type) :: x != B_type(20.0)
   real :: r

   r = B_type(20.0)

   write (unit=*, fmt="(f4.1)") B_type(20.0)
   !write (unit=*, fmt="(f4.1)") x

end program test_b_write_dt_mod

The effective item is of type B_type not real and the assignment to r is
rejected.

So I believe the effective type in the write statement is likewise derived type
ad not real.

My thinking is this PR is invalid.

[Bug target/80966] ICE with -fstack-limit-register and large frames

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Author: segher
Date: Fri Jun  9 03:46:08 2017
New Revision: 249046

URL: https://gcc.gnu.org/viewcvs?rev=249046=gcc=rev
Log:
rs6000: Don't add an immediate to r0 (PR80966)

If there is a large stack frame the rs6000 -fstack-limit code would
calculate the new stack pointer value using two insns (an addis and
an addi), with r0 as temporary.  Such instructions do not exist.

This patch changes add3 to expand using a different strategy in
such cases; to FAIL if there is no way to do it (namely, if the source
is r0 and there is no way to get a temporary reg); and it changes
rs6000_emit_allocate_stack to assert gen_add3_insn did in fact emit
instructions.


PR target/80966
* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Assert that
gen_add3_insn did not fail.
* config/rs6000/rs6000.md (add3): If asked to add a constant to
r0, construct that number in a temporary reg and add that reg to r0.
If asked to put the result in r0 as well, fail.

gcc/testsuite/
* gcc.target/powerpc/stack-limit.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/stack-limit.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52473] CSHIFT slow - inline it?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #6)
> Created attachment 41508 [details]
> What an unrolled cshift could look like
> 
> This is what an unrolled version of cshift could look like,
> for a simple one-dimensional case.
> 
> If the shifts are constants, all the if statements are
> optimized away at compile-time, so it is quite efficient.

How often or how important is this feature? Would it improve any known
benchmark or real world application in a significant manner?

[Bug c++/81028] GCC miscompiles placement new

[hstong at ca dot ibm.com]

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

Hubert Tong  changed:

   What|Removed |Added

   Keywords||wrong-code
Version|7.0 |8.0
Summary|miscompiles placement new   |GCC miscompiles placement
   ||new

--- Comment #1 from Hubert Tong  ---
In the following program, the only iteration of the loop increments the int
object pointed-to by p, and then replaces said object via q using
placement-new.

GCC miscompiles at -O2, at least with x86_64-pc-linux-gnu.

Online compiler: https://wandbox.org/permlink/ByNZmtd6oB6SgG0g

### SOURCE ():
inline void* operator new(decltype(sizeof 0), void* __p) noexcept
{ return __p; }

extern "C" void abort();

typedef int A;
typedef float B;

B *qq;

void foo(A *p, A *q, long unk) {
   for (long i = 0; i < unk; ++i) {
  ++*p;
  qq = new (static_cast([i])) B(42);
   }
}

void (*volatile fp)(A *, A *, long);

int main(void) {
   union { A x; B f; } u = { 0 };
   fp = foo;
   fp(, , 1);
   if (*qq != 42) abort();
}


### COMMANDS TO REPRODUCE:
g++ -O2 -o ./a.out -x c++ -std=c++11 -
./a.out


### EXPECTED OUTPUT:
(rc=0)


### ACTUAL OUTPUT:
Aborted
(rc=134)


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170607 (experimental) (GCC)

[Bug c++/81028] New: miscompiles placement new

[hstong at ca dot ibm.com]

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

Bug ID: 81028
   Summary: miscompiles placement new
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

[Bug fortran/81027] New: Assumed-shape array reported as deferred.

[john.harper at vuw dot ac.nz]

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

Bug ID: 81027
   Summary: Assumed-shape array reported as deferred.
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program is bad because it has an assumed-shape array in an initialization
expression, but gfortran wrongly diagnoses it as a deferred array. Bug 46299
(in which gfortran accepted a bad program) may be related to this one, in which
a bad program was correctly rejected, but for the wrong reason. Here are the
program and what the compiler did with it.


cayley[~/Jfh] % cat badarray.f90
! is m assumed-shape or deferred-shape?
program badarray
  implicit none
  integer:: j(3) = [1,2,3]
  call doubling(j)
contains
  subroutine doubling(  n)
integer,intent(in)::n(:)
integer::m = size(n)
print *, m
  end subroutine doubling
end program badarray


cayley[~/Jfh] % gfortran -v -std=f2003 badarray.f90
Driving: gfortran -v -std=f2003 badarray.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.3.1 20170109 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=f2003' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/f951 badarray.f90 -quiet -dumpbase
badarray.f90 -mtune=generic -march=x86-64 -auxbase badarray -std=f2003 -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/finclude -o
/tmp/cctXeg2E.s
GNU Fortran (GCC) version 6.3.1 20170109 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.1 20170109, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2003 (GCC) version 6.3.1 20170109 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.1 20170109, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
badarray.f90:9:22:

 integer::m = size(n)
  1
Error: Deferred array ‘n’ at (1) is not permitted in an initialization
expression
badarray.f90:10:14:

 print *, m
  1
Error: Symbol ‘m’ at (1) has no IMPLICIT type
cayley[~/Jfh] %

[Bug ipa/81000] std::any improvement

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Marc Glisse from comment #2)
> (Of course, a different implementation of std::any might be easier to
> optimize)

>From a quick test, if instead of storing a pointer to _S_manage we store a
pointer to an array of function pointers (or a tuple so the types don't have to
be identical) where each function does only one of the tasks (clone, xfer,
etc), then with __attribute__(flatten) on f we manage to optimize to return 10.

I am not claiming that would be a better implementation, it is the first time I
take a look at std::any.

[Bug c++/81026] New: Lookup of dependent member template incorrectly finds non-member

[Casey at Carter dot net]

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

Bug ID: 81026
   Summary: Lookup of dependent member template incorrectly finds
non-member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

GCC 4/5/6/7/8 diagnose this correct program:

namespace std {
template struct extent;
}

using namespace std;

template 
struct S {
void f() { T{}.template extent<42>(); }
};

with:

prog.cc: In member function 'void S::f()':
prog.cc:9:38: error: type/value mismatch at argument 1 in template parameter
list for 'template struct std::extent'
 void f() { T{}.template extent<42>(); }
  ^
prog.cc:9:38: note:   expected a type, got '42'

[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863

[doug.gilmore at imgtec dot com]

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

--- Comment #3 from Doug Gilmore  ---
It appears that r248863 just tickles the bug.  With
the attached example produced by delta the failure mode
is exposed by r248862.With luck, I may be able to
bisect the problem to an earlier commit.

[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed for GCC 8:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=32b3df079a3af3933c2b137cb1f772e96ca9499d

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug target/81015] Bad codegen for __builtin_clz(unsigned short)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/81015] Bad codegen for __builtin_clz(unsigned short)

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jun  8 19:42:59 2017
New Revision: 249039

URL: https://gcc.gnu.org/viewcvs?rev=249039=gcc=rev
Log:
PR target/81015
Revert:
2016-12-14  Uros Bizjak  

PR target/59874
* config/i386/i386.md (*ctzhi2): New insn_and_split pattern.
(*clzhi2): Ditto.

testsuite/ChangeLog:

PR target/81015
* gcc.target/i386/pr59874-1.c (foo): Call __builtin_ctzs.
* gcc.target/i386/pr59874-2.c (foo): Call __builtin_clzs.
* gcc.target/i386/pr81015.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81015.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr59874-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr59874-2.c

[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jun  8 19:42:59 2017
New Revision: 249039

URL: https://gcc.gnu.org/viewcvs?rev=249039=gcc=rev
Log:
PR target/81015
Revert:
2016-12-14  Uros Bizjak  

PR target/59874
* config/i386/i386.md (*ctzhi2): New insn_and_split pattern.
(*clzhi2): Ditto.

testsuite/ChangeLog:

PR target/81015
* gcc.target/i386/pr59874-1.c (foo): Call __builtin_ctzs.
* gcc.target/i386/pr59874-2.c (foo): Call __builtin_clzs.
* gcc.target/i386/pr81015.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81015.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr59874-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr59874-2.c

[Bug rtl-optimization/80693] [6/7/8 Regression] wrong code with -O -fno-tree-coalesce-vars

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Zdenek Sojka from comment #0)
> Also, the costs dump in the first replacement looks wrong:
> original costs 0 + 4 + 4 = 0

This is correct: 0 means undefined.  You usually get it from a
parallel, like here.

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:23:34 2017
New Revision: 249038

URL: https://gcc.gnu.org/viewcvs?rev=249038=gcc=rev
Log:
PR c/81006
* c-typeck.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* semantics.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* c-c++-common/gomp/pr81006.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/gomp/pr81006.c
Modified:
branches/gcc-5-branch/gcc/c/ChangeLog
branches/gcc-5-branch/gcc/c/c-typeck.c
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/semantics.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:13:51 2017
New Revision: 249037

URL: https://gcc.gnu.org/viewcvs?rev=249037=gcc=rev
Log:
PR c/81006
* c-typeck.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* semantics.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* c-c++-common/gomp/pr81006.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/gomp/pr81006.c
Modified:
branches/gcc-6-branch/gcc/c/ChangeLog
branches/gcc-6-branch/gcc/c/c-typeck.c
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/semantics.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:12:38 2017
New Revision: 249036

URL: https://gcc.gnu.org/viewcvs?rev=249036=gcc=rev
Log:
PR c/81006
* c-typeck.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* semantics.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* c-c++-common/gomp/pr81006.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/gomp/pr81006.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-typeck.c
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/semantics.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:10:49 2017
New Revision: 249035

URL: https://gcc.gnu.org/viewcvs?rev=249035=gcc=rev
Log:
PR c/81006
* c-typeck.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* semantics.c (handle_omp_array_sections_1): Convert TYPE_MAX_VALUE
to sizetype before size_binop.

* c-c++-common/gomp/pr81006.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr81006.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:04:40 2017
New Revision: 249034

URL: https://gcc.gnu.org/viewcvs?rev=249034=gcc=rev
Log:
PR c++/81011
* cp-gimplify.c (cxx_omp_finish_clause): When changing clause
to OMP_CLAUSE_SHARED, also clear OMP_CLAUSE_SHARED_FIRSTPRIVATE
and OMP_CLAUSE_SHARED_READONLY flags.

* g++.dg/gomp/pr81011.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/gomp/pr81011.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/cp-gimplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 19:02:09 2017
New Revision: 249032

URL: https://gcc.gnu.org/viewcvs?rev=249032=gcc=rev
Log:
PR c++/81011
* cp-gimplify.c (cxx_omp_finish_clause): When changing clause
to OMP_CLAUSE_SHARED, also clear OMP_CLAUSE_SHARED_FIRSTPRIVATE
and OMP_CLAUSE_SHARED_READONLY flags.

* g++.dg/gomp/pr81011.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/gomp/pr81011.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/cp-gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 18:55:04 2017
New Revision: 249031

URL: https://gcc.gnu.org/viewcvs?rev=249031=gcc=rev
Log:
PR c++/81011
* cp-gimplify.c (cxx_omp_finish_clause): When changing clause
to OMP_CLAUSE_SHARED, also clear OMP_CLAUSE_SHARED_FIRSTPRIVATE
and OMP_CLAUSE_SHARED_READONLY flags.

* g++.dg/gomp/pr81011.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr81011.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81025] New: [MIPS] soft-float glibc build fails at r248863

[doug.gilmore at imgtec dot com]

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

Bug ID: 81025
   Summary: [MIPS] soft-float glibc build fails at r248863
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

Created attachment 41509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41509=edit
CPP output file

Our ToT GLIBC soft-float builds are failing ToT, I bisected the
problem to r248863.

To reproduce the problem with minimum effort, configure and build via:

/configure --prefix=.../install-mips-mti-linux-gnu
--disable-libssp --disable-libmudflap --disable-decimal-float --with-mips-plt
--target=mips-mti-linux-gnu --enable-languages=c --without-headers
--disable-shared --disable-threads --disable-libquadmath --disable-libatomic
--with-sysroot=.../install-mips-mti-linux-gnu/sysroot
make maybe-all-gcc

I attached two patches:

One to restrict the number of multi-lib variants, which probably isn't
needed for maybe-all-gcc, but will speed full gcc build.

The other patch is a cherry pick of r248879 which is needed to build
r248863 for MIPS.


Build CPP file:

/gcc/xgcc -B/gcc -O2 -msoft-float -mabi=32 s_fmaf.i -c
-std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef -Wwrite-strings
-fmerge-all-constants -fno-stack-protector -frounding-math -g
-Wstrict-prototypes -Wold-style-definition


The CPP file compiles cleanly at r248862, but at r248863 with patch
for r248879 applied, the compile fails with:

during RTL pass: dwarf2
In file included from ../sysdeps/mips/ieee754/s_fmaf.c:4:0:
../soft-fp/fmasf4.c: In function '__fmaf':
../soft-fp/fmasf4.c:62:1: internal compiler error: in maybe_record_trace_start,
at dwarf2cfi.c:2330
0x74ab9f maybe_record_trace_start
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:2330
0x74af2f create_trace_edges
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:2426
0x74b0af scan_trace
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:2640
0x74bd16 create_cfi_notes
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:2666
0x74bd16 execute_dwarf2_frame
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:3024
0x74bd16 execute
/scratch/dgilmore/sgcc-pp5/src/gcc/gcc/dwarf2cfi.c:3504
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Applying -fdump-rtl-dwarf2 to the compilation line the associated
dump file contains:

Inconsistent CFI state!
SHOULD have:
.cfi_def_cfa 29, 0
DO have:
.cfi_def_cfa 29, 8
.cfi_offset 16, -4

The CPP file is quite complicated, I am investigating whether
a cut down example will reproduce the failure.

[Bug middle-end/81005] -fsanitize=null and -fsanitize=alignment doesn't check aggregate arguments of calls

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  8 18:53:16 2017
New Revision: 249030

URL: https://gcc.gnu.org/viewcvs?rev=249030=gcc=rev
Log:
PR middle-end/81005
* ubsan.c (instrument_null): Avoid pointless code temporary.
(pass_ubsan::execute): Instrument aggregate arguments of calls.

* c-c++-common/ubsan/align-10.c: New test.
* c-c++-common/ubsan/null-13.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/align-10.c
trunk/gcc/testsuite/c-c++-common/ubsan/null-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863

[doug.gilmore at imgtec dot com]

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

--- Comment #2 from Doug Gilmore  ---
Created attachment 41511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41511=edit
patch needed to build r248863 for MIPS

[Bug tree-optimization/81025] [MIPS] soft-float glibc build fails at r248863

[doug.gilmore at imgtec dot com]

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

--- Comment #1 from Doug Gilmore  ---
Created attachment 41510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41510=edit
Patch to constrain the number of multi-lib variants

[Bug sanitizer/81023] False positiv stack-use-after-scope (worked with GCC 6, fails with GCC 7)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
That's mine, I'll take a look.

[Bug target/81015] Bad codegen for __builtin_clz(unsigned short)

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jun  8 17:28:19 2017
New Revision: 249028

URL: https://gcc.gnu.org/viewcvs?rev=249028=gcc=rev
Log:
PR target/81015
Revert:
2016-12-14  Uros Bizjak  

PR target/59874
* config/i386/i386.md (*ctzhi2): New insn_and_split pattern.
(*clzhi2): Ditto.

testsuite/ChangeLog:

PR target/81015
* gcc.target/i386/pr59874-1.c (foo): Call __builtin_ctzs.
* gcc.target/i386/pr59874-2.c (foo): Call __builtin_clzs.
* gcc.target/i386/pr81015.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr81015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr59874-1.c
trunk/gcc/testsuite/gcc.target/i386/pr59874-2.c

[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++

[uros at gcc dot gnu.org]

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

--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jun  8 17:28:19 2017
New Revision: 249028

URL: https://gcc.gnu.org/viewcvs?rev=249028=gcc=rev
Log:
PR target/81015
Revert:
2016-12-14  Uros Bizjak  

PR target/59874
* config/i386/i386.md (*ctzhi2): New insn_and_split pattern.
(*clzhi2): Ditto.

testsuite/ChangeLog:

PR target/81015
* gcc.target/i386/pr59874-1.c (foo): Call __builtin_ctzs.
* gcc.target/i386/pr59874-2.c (foo): Call __builtin_clzs.
* gcc.target/i386/pr81015.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr81015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr59874-1.c
trunk/gcc/testsuite/gcc.target/i386/pr59874-2.c

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug c++/78620] C++11, Padding bytes not zero-intialized when POD is initialized with compiler generated default constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||aarch64-linux
 Status|WAITING |NEW
   Last reconfirmed|2016-12-01 00:00:00 |2017-6-8
  Known to fail||6.3.1

--- Comment #4 from Jonathan Wakely  ---
Confirmed on aarch64 with 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/6.3.1/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --disable-libmpx --enable-gnu-indirect-function
--build=aarch64-redhat-linux
Thread model: posix
gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC)


Tweaked testcase using the correct terminology:

#include 
#include 
#include 

#include 

void print(struct tm* tt) {
fprintf(stderr, "{%d, %d, %d, %d, %d, %d, %d, %d, %d, %ld, %p}\n", 
  tt->tm_sec,
  tt->tm_min,
  tt->tm_hour,
  tt->tm_mday,
  tt->tm_mon,
  tt->tm_year,
  tt->tm_wday,
  tt->tm_yday,
  tt->tm_isdst,
  tt->tm_gmtoff,
  tt->tm_zone);


  char* p = (char*)tt;
  fprintf(stderr, "%ld\n", sizeof(tm));
  for (size_t i = 0; i < sizeof(tm); ++i) {
fprintf(stderr, "%02x ", (unsigned char)p[i]);
  }
 fprintf(stderr, "\n");

}

int main(void) {
struct tm tt1;
fprintf(stderr, "default-initialization\n");
print();
struct tm tt2 = tm();
fprintf(stderr, "value-initialization\n");
print();
struct tm tt3{};
fprintf(stderr, "copy-list-initialization\n");
print();
struct tm tt4 = {};
fprintf(stderr, "value-list-initialization\n");
print();

{
char buf[sizeof(tm)];
memset(buf, 0xFF, sizeof(tm));
new (buf) tm;
fprintf(stderr, "placement new default-initialization\n");
print(reinterpret_cast(buf));
}
{
char buf[sizeof(tm)];
memset(buf, 0xFF, sizeof(tm));
new (buf) tm();
fprintf(stderr, "placement new with value-initialization\n");
print(reinterpret_cast(buf));
}
{
char buf[sizeof(tm)];
memset(buf, 0xFF, sizeof(tm));
new (buf) tm{};
fprintf(stderr, "placement new with list-initialization\n");
print(reinterpret_cast(buf));
}
}

aarch64 output:

default-initialization
{-1758476368, 127, 4197200, 0, 0, 0, -362443216, 127, -1758476340, 4197200,
(nil)}
56
b0 c7 2f 97 7f 00 00 00 50 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 30 8e
65 ea 7f 00 00 00 cc c7 2f 97 7f 00 00 00 50 0b 40 00 00 00 00 00 00 00 00 00
00 00 00 00 
value-initialization
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, (nil)}
56
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 
copy-list-initialization
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, (nil)}
56
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 
value-list-initialization
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, (nil)}
56
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 
placement new default-initialization
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0x}
56
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff 
placement new with value-initialization
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, (nil)}
56
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 
placement new with list-initialization
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, (nil)}
56
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 

The list-initialization cases zero the padding bytes, but t he
value-initialization cases don't.

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Created attachment 41508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41508=edit
What an unrolled cshift could look like

This is what an unrolled version of cshift could look like,
for a simple one-dimensional case.

If the shifts are constants, all the if statements are
optimized away at compile-time, so it is quite efficient.

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Fixed on trunk, I'm planning to backport it to the branches too.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
I thought this was fixed only for certain floating-point formats - and 
even for those, not globally for all targets (not for binary128 on 32-bit 
targets)?

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[matt at godbolt dot org]

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

--- Comment #2 from Matt Godbolt  ---
Thanks Martin!

[Bug c++/81024] ICE within convert_like_real with std::initializer_list

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|ICE within  |ICE within
   |convert_like_real   |convert_like_real with
   ||std::initializer_list

--- Comment #1 from David Malcolm  ---
Segfault is a read through NULL in convert_like_real at line 6805 here,
within the handling for:

  /* Conversion to std::initializer_list.  */

  (gdb) list
  6800  
  6801  /* Build up the initializer_list object.  */
  6802  totype = complete_type (totype);
  6803  field = next_initializable_field (TYPE_FIELDS (totype));
  6804  CONSTRUCTOR_APPEND_ELT (vec, field, array);
>>6805  field = next_initializable_field (DECL_CHAIN (field));
  6806  CONSTRUCTOR_APPEND_ELT (vec, field, size_int (len));
  6807  new_ctor = build_constructor (totype, vec);
  6808  return get_target_expr_sfinae (new_ctor, complain);
  6809}

  (gdb) p field
  $1 = 

[Bug middle-end/79988] [7/8 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851

[aivchenk at gcc dot gnu.org]

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

--- Comment #4 from Alexander Ivchenko  ---
Author: aivchenk
Date: Thu Jun  8 16:05:59 2017
New Revision: 249023

URL: https://gcc.gnu.org/viewcvs?rev=249023=gcc=rev
Log:

2017-06-08  Alexander Ivchenko  

   PR middle-end/79988
   * tree-chkp.c (chkp_gimple_call_builtin_p): Remove
   gimple_call_builtin_p call.

017-06-08  Alexander Ivchenko  

PR middle-end/79988
* gcc.target/i386/mpx/pr79988.c: New test.




Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr79988.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
If you undo that change then you can't link C++17 programs using std::string at
all, not just using LTO. That's why the change was done in the first place.

[Bug c++/81024] New: ICE within convert_like_real

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 81024
   Summary: ICE within  convert_like_real
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Found by Alec Teal; reported to me over IRC.

Seen with gcc 4.8 and with trunk (r248825).

$ cat main.cc
namespace std { 
template class initializer_list;
}
void WtfTest(int, const char*, const char*, const ::std::initializer_list&);
#define WTF(...) WtfTest(__LINE__,__FILE__,"potato",{__VA_ARGS__});
int main() { WTF("it","works") }

gcc main.cc
main.cc: In function ‘int main()’:
main.cc:5:66: internal compiler error: Segmentation fault
 #define WTF(...) WtfTest(__LINE__,__FILE__,"potato",{__VA_ARGS__});
  ^
main.cc:6:14: note: in expansion of macro ‘WTF’
 int main() { WTF("it","works") }
  ^~~
0xb7f806 crash_signal
../../src/gcc/toplev.c:338
0x60797d convert_like_real
../../src/gcc/cp/call.c:6805
0x6076bc convert_like_real
../../src/gcc/cp/call.c:6838
0x60a4cd build_over_call
../../src/gcc/cp/call.c:7840
0x61250e build_new_function_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c:4262
0x727d25 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2479
0x6c990d cp_parser_postfix_expression
../../src/gcc/cp/parser.c:6998
0x6d0446 cp_parser_unary_expression
../../src/gcc/cp/parser.c:8117
0x6d0f65 cp_parser_cast_expression
../../src/gcc/cp/parser.c:8796
0x6d1562 cp_parser_binary_expression
../../src/gcc/cp/parser.c:8898
0x6d1cb2 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9186
0x6d923a cp_parser_expression
../../src/gcc/cp/parser.c:9353
0x6da32a cp_parser_expression_statement
../../src/gcc/cp/parser.c:10912
0x6c5376 cp_parser_statement
../../src/gcc/cp/parser.c:10728
0x6c6377 cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:11054
0x6c642f cp_parser_compound_statement
../../src/gcc/cp/parser.c:11008
0x6e1330 cp_parser_function_body
../../src/gcc/cp/parser.c:21447
0x6e1330 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:21483
0x6e1b2e cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.c:26291
0x6e2a9c cp_parser_function_definition_from_specifiers_and_declarator
../../src/gcc/cp/parser.c:26203

[Bug sanitizer/80973] ICE with lambda and -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41507=edit
gcc8-pr80973.patch

Untested fix.

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[a3at.mail at gmail dot com]

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

--- Comment #12 from Azat  ---
> Started with r238959.

If you revert this then it fixes some of problems (even though this is a
temporary solution), but there are more, and now this is *only without -flto*
(i.e. -Wall "-Werror -Wunknown-pragmas -Wextra -Wwrite-strings -std=c++1z -g3
'-rdynamic"):

/usr/include/c++/7.1.1/bits/regex.h:235: undefined reference to
`std::__cxx11::basic_string::data()'
/usr/include/c++/7.1.1/bits/regex.h:235: undefined reference to
`std::__cxx11::basic_string::data()'

I will try to get a small reproducer later.

[Bug sanitizer/81023] New: False positiv stack-use-after-scope (worked with GCC 6, fails with GCC 7)

[d.frey at gmx dot de]

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

Bug ID: 81023
   Summary: False positiv stack-use-after-scope (worked with GCC
6, fails with GCC 7)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.frey at gmx dot de
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: ---

Created attachment 41506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41506=edit
Minimal program to reproduce the problem

I got a report from address sanitizer about a stack-use-after-scope, which I
believe is a false positive. I managed to shrink the code down to 99 lines, but
no further (that already took 2.5 days).

Code properties:

- No includes
- No templates
- No loops
- No recursion
- No heap allocations
- Compiles cleanly with -pedantic -Wall -Wextra -Werror

Problem properties:

- Using GCC 6 (and its address sanitizer) solves the problem, only GCC 7
reports it.
- Some flags like -O0 or -O3 solve the problem, -O1 still produces it.
- Using -fno-inline solves the problem.
- Almost every change to the code in order to simplify it will solve the
problem.

I'm at a total loss as to what is wrong and I am pretty sure the code itself it
not accessing the stack after the scope is gone.

The area I am suspicious about is: I'm throwing an exception and the destructor
of the class "marker" is writing some bytes (assignment of "iterator"). Is this
confusing the address sanitizer?

My system (g++ --version):

g++-7 (Ubuntu 7.1.0-5ubuntu2~14.04) 7.1.0

Output:

frey@vbox::~/work/test/address_sanitizer_false_positive$ g++-7 -std=c++14
-pedantic -Wall -Wextra -Werror -fsanitize=address -fuse-ld=gold -O1 -g t.cpp
-o t && ./t
=
==17925==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fff9bd67ef0 at pc 0x00401112 bp 0x7fff9bd67e80 sp 0x7fff9bd67e78
WRITE of size 24 at 0x7fff9bd67ef0 thread T0
#0 0x40 in marker::marker(iterator&)
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:22
#1 0x40 in input::mark()
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:59
#2 0x40 in rule::match(input&)
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:71
#3 0x40 in match(input&)
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:81
#4 0x40141f in verify_fail(char const*)
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:88
#5 0x4014c0 in main
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:97
#6 0x7f30c3f75f44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#7 0x400ca8 
(/home/frey/work/test/address_sanitizer_false_positive/t+0x400ca8)

Address 0x7fff9bd67ef0 is located in stack of thread T0 at offset 96 in frame
#0 0x400d66 in match(input&)
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:79

  This frame has 2 object(s):
[32, 64) 'm'
[96, 128) 'm' <== Memory access at offset 96 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
/home/frey/work/test/address_sanitizer_false_positive/t.cpp:22 in
marker::marker(iterator&)
Shadow bytes around the buggy address:
  0x1000737a4f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a4f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a4fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a4fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a4fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000737a4fd0: 00 00 f1 f1 f1 f1 00 00 00 00 f2 f2 f2 f2[f8]f8
  0x1000737a4fe0: f8 f8 f3 f3 f3 f3 00 00 00 00 00 00 f1 f1 f1 f1
  0x1000737a4ff0: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x1000737a5000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a5010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000737a5020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-08
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine, I'll take a look.

[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #5 from Carl Love  ---
Taking the bug, Fix has been submitted.

[Bug c++/81022] New: invalid address with pointer type casting

[vvsed at hotmail dot com]

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

Bug ID: 81022
   Summary: invalid address with pointer type casting
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vvsed at hotmail dot com
  Target Milestone: ---

Created attachment 41505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41505=edit
same source code

/*
D:\Tools\MinGW64\bin\g++.exe -m64 -O2 -Wall -save-temps gcerr_1.cpp
-ovx_class_gc

Compiler:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
MinGW 7.1 and below
OS: Windows 7 or Linux 64-bit on Intel x64

invalid address with pointer type casting
*/

#include 
#include 

typedef long long int   type;
typedst[2];

void srt(type *src)
{
type*p, t;

p = src + 1;
t = p[0];
p--;

if (src[1] < src[0])
{
p[1] = p[0];
p--;
}

#if __SSE2__
_mm_store_sd((double *)(p + 1), _mm_load_sd((double *)));
//invalid address
//  _mm_storel_epi64((__m128i *)(p + 1), _mm_loadl_epi64((__m128i
*)));   //ok
#else
p[1] = t;   //ok
#endif

dst[0] = src[0];
dst[1] = src[1];
}

int main()
{
typesrc[2] = {1, 0};

srt(src);

fprintf(stdout, "%lld %lld", dst[0], dst[1]);   //prints "1 1" instead
of "0 1"
return 0;
}

[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #6 from Carl Love  ---
Fix submitted upstream

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

[aivchenk at gcc dot gnu.org]

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

Bug 79990 Summary: [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79990

   What|Removed |Added

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

[Bug middle-end/79990] [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790

[aivchenk at gcc dot gnu.org]

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

Alexander Ivchenko  changed:

   What|Removed |Added

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

--- Comment #3 from Alexander Ivchenko  ---
Fixed with r249015:


Author: aivchenk 
Date:   Thu Jun 8 14:07:21 2017 +

gcc/ChangeLog:

2017-05-09  Alexander Ivchenko  

* tree-chkp.c (chkp_get_hard_register_var_fake_base_address):
New function.
(chkp_get_hard_register_fake_addr_expr): Ditto.
(chkp_build_addr_expr): Add check for hard reg case.
(chkp_parse_array_and_component_ref): Ditto.
(chkp_find_bounds_1): Ditto.
(chkp_process_stmt): Don't generate bounds store for
hard reg case.

[Bug sanitizer/81021] New: stack-use-after-scope false positive error with exceptions

[matt at godbolt dot org]

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

Bug ID: 81021
   Summary: stack-use-after-scope false positive error with
exceptions
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
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 7.1 compiled from source, testing on Ubuntu and Arch linux.

The following minimal reproduction code:

---snip---
#include 

struct ConfigFile {
ConfigFile(std::string filename, std::string delimiter) { throw "error"; }
};

struct Configuration {
ConfigFile _configFile;

Configuration(const std::string , const char *baseName) 
: _configFile(root + baseName, "=") { }
};


void test() {
std::string root("etc");
try {
Configuration config(root, "notthere");
}
catch (...) {
// exception is thrown, caught here and ignored...
}
Configuration config(root, "sample"); // ASAN error during constructor here
}

int main(int argc, const char *argv[]) {
test();
}
---snip---

when compiled and run with the address sanitizer with `g++ -fsanitize=address
test.cc -o test` gives the following apparent false positive.

=
==44114==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7ffd3b2bf6f0 at pc 0x004fa7bf bp 0x7ffd3b2bf660 sp 0x7ffd3b2bf658
WRITE of size 32 at 0x7ffd3b2bf6f0 thread T0
#0 0x4fa7be in
Configuration::Configuration(std::__cxx11::basic_string const&, char const*)
(/home/mgodbolt/dev/gcc7-bug/test+0x4fa7be)
#1 0x4fa4b9 in test() (/home/mgodbolt/dev/gcc7-bug/test+0x4fa4b9)
#2 0x4fa5de in main (/home/mgodbolt/dev/gcc7-bug/test+0x4fa5de)
#3 0x2b6b74945f44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#4 0x405ebb  (/home/mgodbolt/dev/gcc7-bug/test+0x405ebb)

Address 0x7ffd3b2bf6f0 is located in stack of thread T0 at offset 96 in frame
#0 0x4fa689 in
Configuration::Configuration(std::__cxx11::basic_string const&, char const*)
(/home/mgodbolt/dev/gcc7-bug/test+0x4fa689)

  This frame has 3 object(s):
[32, 33) ''
[96, 128) '' <== Memory access at offset 96 is inside this
variable
[160, 192) ''
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
(/home/mgodbolt/dev/gcc7-bug/test+0x4fa7be) in
Configuration::Configuration(std::__cxx11::basic_string const&, char const*)
Shadow bytes around the buggy address:
  0x10002764fe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764fe90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764fea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764feb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764fec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10002764fed0: 00 00 f1 f1 f1 f1 01 f2 f2 f2 f2 f2 f2 f2[f8]f8
  0x10002764fee0: f8 f8 f2 f2 f2 f2 f8 f8 f8 f8 f3 f3 f3 f3 00 00
  0x10002764fef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764ff00: 00 00 f8 00 00 00 00 00 00 00 01 00 00 00 00 00
  0x10002764ff10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002764ff20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Reducing the file further (removing the apparently unnecessary std::strings)
prevents this issue from being flagged up.

[Bug tree-optimization/81009] missing aliasing optimization for const restrict pointers

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Yes, the constness can be cast away without changing the effect of the rule.

Similar to the C++ rule we discussed in bug 80794 I feel that constness is an
underappreciated opportunity to generate better code in both languages.  I
agree that constness alone is not sufficient to rely on for optimization
because it can be cast away and the object modified, but in conjunction with
restrict in C and with other rules in C++ (as discussed in bug 80794) I think
it's worth looking into.

[Bug rtl-optimization/81020] New: [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp

[zsojka at seznam dot cz]

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

Bug ID: 81020
   Summary: [6/7/8 Regression] wrong code with -O
-fno-tree-bit-ccp -fno-tree-coalesce-vars
-fno-tree-vrp
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 41504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41504=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-bit-ccp -fno-tree-coalesce-vars
-fno-tree-vrp testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-248824-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-248824-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 8.0.0 20170602 (experimental) (GCC)

[Bug rtl-optimization/81019] New: [6/7/8 Regression] wrong code with -O -fno-tree-ccp

[zsojka at seznam dot cz]

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

Bug ID: 81019
   Summary: [6/7/8 Regression] wrong code with -O -fno-tree-ccp
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 41503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41503=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-ccp testcase.c
$ ./a.out 
Aborted

$ /repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-248824-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-248824-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 8.0.0 20170602 (experimental) (GCC)

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Jun  8 14:27:45 2017
New Revision: 249018

URL: https://gcc.gnu.org/viewcvs?rev=249018=gcc=rev
Log:
PR libstdc++/81017 add noexcept to std::function move operations

PR libstdc++/81017
* include/bits/std_function.h (function::function(function&&))
(function::operator=(funtion&&)): Add noexcept.
* testsuite/20_util/function/assign/move.cc: Check for noexcept.
* testsuite/20_util/function/cons/move.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/std_function.h
trunk/libstdc++-v3/testsuite/20_util/function/assign/move.cc
trunk/libstdc++-v3/testsuite/20_util/function/cons/move.cc

[Bug sanitizer/80973] ICE with lambda and -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Looking at this.

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[Sagar2.shah at citi dot com]

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

--- Comment #5 from Sagar Shah  ---
(In reply to Jonathan Wakely from comment #4)
> Yes, and the move assignment operator.

cool.. thanks!

[Bug sanitizer/80973] ICE with lambda and -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amker at gcc dot gnu.org

--- Comment #3 from amker at gcc dot gnu.org ---
Sorry for disturbing, I will do investigation.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Hmm, for the original example in comment 0 we do use build_value_init, but this
branch is not taken:

  else if (TYPE_HAS_COMPLEX_DFLT (type))
{
  /* This is a class that needs constructing, but doesn't have
 a user-provided constructor.  So we need to zero-initialize
 the object and then call the implicitly defined ctor.
 This will be handled in simplify_aggr_init_expr.  */
  AGGR_INIT_ZERO_FIRST (ctor) = 1;
  return ctor;
}

But for my example in comment 1 there is no call to build_value_init, even
though X() should perform value-initialization. So maybe these are two separate
bugs.

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Caused by

r248965 | amker | 2017-06-07 13:31:44 +0200 (Wed, 07 Jun 2017) | 2 lines

* passes.def (pass_iv_canon): Move before pass_loop_distribution.

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Also seen on darwin with -m64.

[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Sorry, that was intended to be a PM...

[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[wschmidt at linux dot vnet.ibm.com]

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

--- Comment #3 from wschmidt at linux dot vnet.ibm.com ---
Hi Carl,

Just FYI, now that you've fixed the bug, and there are no plans to backport the
patch, you should go ahead and set the status of the bug to RESOLVED FIXED.  I
know this differs from community to community, so wanted to let you know how we
do it.

Thanks for the quick attention to the bug report!  

Bill

> On Jun 7, 2017, at 5:04 PM, carll at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80982
> 
> --- Comment #2 from Carl Love  ---
> Author: carll
> Date: Wed Jun  7 22:03:48 2017
> New Revision: 248997
> 
> URL: https://gcc.gnu.org/viewcvs?rev=248997=gcc=rev
> Log:
> gcc/ChangeLog:
> 
> 2017-06-07  Carl Love  
> 
>PR target/80982
>* config/rs6000/altivec.md (double2): Fix the implementation of
>for BE.
> 
> Modified:
>trunk/gcc/ChangeLog
>trunk/gcc/config/rs6000/altivec.md
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2015-04-20 00:00:00 |2017-6-8

--- Comment #1 from Jonathan Wakely  ---
Probably not related to constructor delegation, because we also don't zero-init
the object in this case:

inline void* operator new(decltype(sizeof(0)), void* p) noexcept { return p; }
inline void operator delete  (void*, void*) noexcept { }

struct X {
  int i;

  X() = default;

  X(int) { }
};

struct Y : X {
  Y() : X() { }
};

int main()
{
  alignas(Y) char buf[sizeof(Y)] = { 1, 1, 1, 1 };
  ::new(buf) Y;
  if (buf[0] || buf[1] || buf[2] || buf[3])
throw 1;
}

If the unused X(int) constructor isn't provided then we get the zero-init, so
it seems that the presence of *any* user-provided constructor affects the
interpretation of [dcl.init] p8, but it should only be affected by a
user-provided *default* constructor:

To value-initialize an object of type T means:
 — if T is a (possibly cv-qualified) class type (Clause 12) with either no
default constructor (15.1) or a default constructor that is user-provided or
deleted, then the object is default-initialized;
 — if T is a (possibly cv-qualified) class type without a user-provided or
deleted default constructor, then the object is zero-initialized and the
semantic constraints for default-initialization are checked, and if T
has a non-trivial default constructor, the object is default-initialized;


In the example that delegates to the default ctor there must be a user-provided
ctor to do the delegation, so it hits this bug.

This seems to be present in all GCC releases.

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes, and the move assignment operator.

[Bug c/81006] ICE with zero-size array and #pragma omp task depend

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41502=edit
gcc8-pr81006.patch

The testcase is not valid.

Anyway, here is the untested fix.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jun  8 12:38:27 2017
New Revision: 249010

URL: https://gcc.gnu.org/viewcvs?rev=249010=gcc=rev
Log:
PR sanitize/80932
* c-c++-common/ubsan/pr80932.c: Test with ints, not with long ints.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/pr80932.c

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41501=edit
gcc8-pr81011.patch

Untested fix.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Reproduced with -m32 on x86_64.  Silly me.  Will fix.

pr80932.c:10:88: runtime error: signed integer overflow: -413853711 * -6 cannot
be represented in type 'long int'

[Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2016-09-05 00:00:00 |2017-6-8
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
Reconfirmed.

[Bug tree-optimization/61171] vectorization fails for a reduction in presence of subtraction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2015-04-29 00:00:00 |2017-6-8
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
Reconfirmed, mine.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Maxim Ostapenko  ---
[...]
> For ODR violation bug we have a local patch in libsanitizer. Could you check
> whether you applied all local patches listed in libsanitizer/LOCAL_PATCHES
> file?

excellent, I totally missed that.  As the saying goes: a day of
debugging can save you an hour in the library ;-)

With those patches applied (two of them have already been integrated
upstream, r241978 and r243014), the ODR violation failures are gone.

Thanks a lot.

Rainer

[Bug target/73350] AVX512: GCC optimizes away rounding flags

[kyukhin at gcc dot gnu.org]

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

--- Comment #8 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Jun  8 11:24:50 2017
New Revision: 249009

URL: https://gcc.gnu.org/viewcvs?rev=249009=gcc=rev
Log:
[PR73350][PR80862] Improve subst for RC-capable insns.

PR target/73350,80862
gcc/
* config/i386/subst.md (round): Fix round pattern.
* config/i386/i386.c (ix86_erase_embedded_rounding):
Fix erasing rounding for the fixed pattern.

gcc/testsuite/
* gcc.target/i386/pr73350.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr73350.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/subst.md
trunk/gcc/testsuite/ChangeLog

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

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
trunk (checking=release):

trippels@gcc67 gcc % gcc -O0 -fsanitize=undefined
./gcc/testsuite/c-c++-common/ubsan/pr80932.c
trippels@gcc67 gcc % ./a.out
gcc/testsuite/c-c++-common/ubsan/pr80932.c:10:88: runtime error: signed integer
overflow: -9024801181724640896 - 228867929910118694 cannot be represented in
type 'long int'

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

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
https://gcc.gnu.org/ml/gcc-regression/2017-06/msg00104.html
https://gcc.gnu.org/ml/gcc-regression/2017-06/msg00105.html
https://gcc.gnu.org/ml/gcc-regression/2017-06/msg00107.html

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[Sagar2.shah at citi dot com]

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

--- Comment #3 from Sagar Shah  ---
thanks for taking a look at this.

Are we going to have noexcept added in the function move ctor.?

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Can't reproduce.  What arch, is that gcc or g++, ...

[Bug c/80959] -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Can be also simulated with ObjC:

$ cat /tmp/objc.m
volatile int i;

int
foo (void)
{
  @try {
switch (i)
  {
  case 1:
switch (i)
  {
  default:
return 0;
  }
break;
  default:
return 0;
  }
  }
  @finally {
i = 2;
  }
}

$ gcc /tmp/objc.m -fobjc-exceptions -c -Wall 
/tmp/objc.m: In function ‘foo’:
/tmp/objc.m:23:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

But as the function decide_copy_try_finally depends on optimization level:

$ gcc /tmp/objc.m -fobjc-exceptions -c -Wall -O1
[nothing]

[Bug tree-optimization/81003] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in optimize_range_tests_to_bit_test, at tree-ssa-reassoc.c:2782

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41500=edit
gcc8-pr81003.patch

We can't allow ->op to be something other than SSA_NAME or NULL (the latter
means GIMPLE_COND at the end of some bb), because we need e.g. corresponding
stmt iterator to know where to insert related stuff.
The reason why we get an integer in ->op is that there is almost no cleanup
after cunroll pass before reassoc is invoked, so gimple fold during
force_gimple_operand_gsi is successful in optimizing it into a constant.

This untested patch ensures we have an SSA_NAME and therefore also stmt
iterator for it.

[Bug c/80959] -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
So there's explanation what happens:

1) w/o -fsanitize=address:

decide_copy_try_finally returns true and so that we copy BB that contains
finally statement:

foo ()
{
  int n;
  int D.1806;

  bar ();
  i.0_1 = i;
  switch (i.0_1) , case 1: >
  :
  i.1_2 = i;
  switch (i.1_2) >
  :
  D.1806 = 0;
  goto ;
  goto ;
  :
  D.1806 = 0;
  goto ;
  :
  n = {CLOBBER};
  goto ;
  :
  n = {CLOBBER};
  goto ;
  :
  return;
  :
  return D.1806;
}

then CFG pass removes the dead BBs. All works fine.

2) w/ -fsanitize=address the decide_copy_try_finally returns false and thus we
create switch to dispatch
from the finally statement:

foo ()
{
  int finally_tmp.2;
  int n;
  int D.2128;

  ASAN_MARK (UNPOISON, , 4);
  bar ();
  i.0_1 = i;
  switch (i.0_1) , case 1: >
  :
  i.1_2 = i;
  switch (i.1_2) >
  :
  D.2128 = 0;
  finally_tmp.2 = 0;
  goto ;
  goto ;
  :
  D.2128 = 0;
  finally_tmp.2 = 0;
  goto ;
  :
  finally_tmp.2 = 1;
  :
  ASAN_MARK (POISON, , 4);
  switch (finally_tmp.2) , case 1: >
  :
  goto ;
  :
  goto ;
  :
  return;
  :
  return D.2128;
}

Then CFG removes:

Removing basic block 7
;; basic block 7, loop depth 0
;;  pred:   5
finally_tmp.2 = 1;
;;  succ:   8

now   finally_tmp.2 can have only one value, but the switch statement,
as well as the problematic return BB are not removed.

[Bug sanitizer/80963] UBSAN false positive with visibility=hidden

[jengelh at inai dot de]

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

--- Comment #5 from Jan Engelhardt  ---
>Where would those magic numbers come from?  We don't have anything like that.

Maybe something similar to .build-id?, i.e. randomly-generated IDs (per .so)
that merely serve to distinguish two structs.


>>some -f option to always make UBSAN treat same-name classes as the same thing 
>>irrespective of visibility.

I think I now found that as -fvisibility-ms-compat.


>By using visibility other than default, you intentionally depart from the C++ 
>ODR rules

I see. Then however the manpage should perhaps be updated to sport some
stronger language, since it currently rather encourages the use of visibility
and even lists the few conditions that need to be met.

"""It is strongly recommended that you use this in any shared objects you
distribute."""
"""-fvisibility does affect C++ vague linkage entities. This means that, for
instance, an exception class that is be thrown between DSOs must be explicitly
marked with default visibility so that the type_info nodes are unified between
the DSOs."""

[Bug tree-optimization/81018] [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/81018] New: [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 81018
   Summary: [8 regression] gfortran.dg/graphite/pr14741.f90 FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.12, sparc-sun-solaris2.12,
x86_64-pc-linux-gnu, x86_64-unknown-freebsd12.0

Between 20170606 (r248925) and 20170607 (r248990), a testsuite regression
appeared:

+FAIL: gfortran.dg/graphite/pr14741.f90   -O   scan-tree-dump graphite "tiled
by"

I'm seeing it on Solaris/x86 and Solaris/SPARC, 64-bit only, and according
to gcc-testresults it happens on Linux/x86_64 and FreeBSD/x86_64, too.

  Rainer

[Bug sanitizer/80963] UBSAN false positive with visibility=hidden

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jan Engelhardt from comment #3)
> The question is more like - can it be made to work even if (In reply to
> Andrew Pinski from comment #1)
> > 
> > That is Archive in the shared library and in the main executable are
> > considered two different classes.
> 
> If that is how UBSAN thinks, then it should say so by uniquely identifying
> each "distinct" class, e.g.:
> 
> main.cpp:3:16: runtime error: member call on address 0x00dcfc20 which
> does not point to an object of type 'Archive.1234'
> 0x00dcfc20: note: object is of type 'ArchiveImpl' [Archive.5678]

Where would those magic numbers come from?  We don't have anything like that.

> Secondly, I think that considering them two different classes is only valid
> in C, but not under the ODR rules of C++.

By using visibility other than default, you intentionally depart from the C++
ODR rules, it is an extension and the classes are not the same anymore in
different shared libraries.

> Finally, nonwithstanding all the above, it would be nice to have some -f
> option to always make UBSAN treat same-name classes as the same thing
> irrespective of visibility. Reason: to make UBSAN "work" with this example
> meant having to edit configure.ac+Makefile.am (of the particular real-world
> program) to not use "-Wl,--version-script=foo.sym -fvisiblity=hidden" at
> all, and that was a little more work than just slapping another -f into
> CXXFLAGS.

The point of UBSAN is to diagnose UB, and your testcase has UB.  If you want
some -f option, that option is -fvisibility=default, which will make the code
well defined and ubsan will not complain about it.

[Bug debug/81001] incorrect debug info for parameter that is const pointer to typedef of array

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This might be related to const don't applies to the array itself but to the
type which the array is of in both c and c++ .

[Bug sanitizer/80963] UBSAN false positive with visibility=hidden

[jengelh at inai dot de]

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

--- Comment #3 from Jan Engelhardt  ---
The question is more like - can it be made to work even if (In reply to Andrew
Pinski from comment #1)
> 
> That is Archive in the shared library and in the main executable are
> considered two different classes.

If that is how UBSAN thinks, then it should say so by uniquely identifying each
"distinct" class, e.g.:

main.cpp:3:16: runtime error: member call on address 0x00dcfc20 which does
not point to an object of type 'Archive.1234'
0x00dcfc20: note: object is of type 'ArchiveImpl' [Archive.5678]


Secondly, I think that considering them two different classes is only valid in
C, but not under the ODR rules of C++.


Finally, nonwithstanding all the above, it would be nice to have some -f option
to always make UBSAN treat same-name classes as the same thing irrespective of
visibility. Reason: to make UBSAN "work" with this example meant having to edit
configure.ac+Makefile.am (of the particular real-world program) to not use
"-Wl,--version-script=foo.sym -fvisiblity=hidden" at all, and that was a little
more work than just slapping another -f into CXXFLAGS.

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
#include 
#include 
#include 

struct Foo {
std::vector vec;
std::function f;
};

int main()
{
std::vector vec;
vec.reserve(10);
}

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-08
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
We're missing noexcept on function(function&&)

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
It goes from:

_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev/37 (__comp_dtor )
@0x7f9a6e65eb80 
  Type: function definition analyzed alias 
   
 Visibility: externally_visible prevailing_def public weak
comdat comdat_group:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED5Ev
one_only visibility_specified
  Same comdat group as:
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev/36
  Address is taken. 
  References: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev/36
(alias) 
  Referring:
_ZN5boost15program_options17get_single_stringIcEEvSt1AINSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_.isra.0/59
(addr)
  Read from file: /tmp/cc8JHtNO.o   
  Availability: available  
   
 First run: 0  
   
Function flags:
   
   Called by:  
   
 
Calls:  
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev/36 (__base_dtor )
@0x7f9a6e65ea10
 Type: function definition analyzed 
  Visibility: externally_visible public weak comdat
comdat_group:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED5Ev one_only
visibility_specified   
  Same comdat group as:
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev/37
  Address is taken. 
  References:   
  Referring: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev/37
(alias) 
  Read from file: /tmp/cc8JHtNO.o   
  Availability: available   
  First run: 0  
  Function flags:   
  Called by:
  Calls: 

to:
Optimized Symbol table:
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev/37 (__comp_dtor )
@0x7f9a6e65eb80 
  Type: function definition analyzed alias  
  Visibility: externally_visible prevailing_def 
  Address is taken. 
  References: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev/36
(alias) 
  Referring:
_ZN5boost15program_options17get_single_stringIcEEvSt1AINSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_.isra.0/59
(addr)
  Read from file: /tmp/cc8JHtNO.o   
  Availability: available   
  First run: 0  
  Function flags:   
  Called by:
  Calls:
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev/36 (__base_dtor )
@0x7f9a6e65ea10 
  Type: function definition analyzed
  Visibility: prevailing_def_ironly 
  Address is taken. 
  References:  

[Bug c++/81007] [7/8 Regression] ICE with virtual function in broken class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
(gdb) p debug_tree (field)
 
nonlocal VOID file t.ii line 3 col 5
align 1 offset_align 1 context  chain
>
(gdb) up
#5  0x00edadbd in ipa_polymorphic_call_context::restrict_to_inner_class
(this=0x7fffcca0, otr_type=, 
consider_placement_new=false, consider_bases=false)
at /space/rguenther/src/svn/early-lto-debug/gcc/ipa-polymorphic-call.c:273
273   pos = int_bit_position (fld);
(gdb) l
268   for (fld = TYPE_FIELDS (type); fld; fld = DECL_CHAIN (fld))
269 {
270   if (TREE_CODE (fld) != FIELD_DECL)
271 continue;
272
273   pos = int_bit_position (fld);

I don't think we should try to deal with error stuff in optimization so...

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 249003)
+++ gcc/gimplify.c  (working copy)
@@ -3067,6 +3067,10 @@ gimplify_arg (tree *arg_p, gimple_seq *p
 static bool
 maybe_fold_stmt (gimple_stmt_iterator *gsi)
 {
+  /* Do not fold if we may have invalid IL somewhere.  */
+  if (seen_error ())
+return false;
+
   struct gimplify_omp_ctx *ctx;
   for (ctx = gimplify_omp_ctxp; ctx; ctx = ctx->outer_context)
 if ((ctx->region_type & (ORT_TARGET | ORT_PARALLEL | ORT_TASK)) != 0)

which delays the ICE until cgraphbuild...  (pass_build_cgraph_edges).  So ...

Index: gcc/cgraphbuild.c
===
--- gcc/cgraphbuild.c   (revision 249003)
+++ gcc/cgraphbuild.c   (working copy)
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
 #include "gimple-walk.h"
 #include "ipa-utils.h"
 #include "except.h"
+#include "diagnostic-core.h"

 /* Context of record_reference.  */
 struct record_reference_ctx
@@ -305,6 +306,7 @@ public:
   /* opt_pass methods: */
   virtual unsigned int execute (function *);

+  virtual bool gate (function *) { return ! seen_error (); }
 }; // class pass_build_cgraph_edges

 unsigned int

[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 #28 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> Besides, can you *pretty please* concentrate on the issue at hand in
> this PR, i.e. the failing tests on i?86 -m64?  Most/all of your
> cleanups, nice as they may be on their own, have nothing to do with the
> PR and just distract from the main issue.

I've also included your patches in yesterday night's full bootstraps and
found an additional issue: with -j96 (sparc-sun-solaris2.12) resp. -j24
(i386-pc-solaris2.12), I get many (74 resp. 100) instances of

WARNING: dg_set_test_count should be called prior to running any test.

in mail-report.log.

As I've said before, the parallelization of ms-sysv.exp runs may be a
bonus, but is certainly separate from this PR and thus should be split
out: a sequential run of ms-sysv.exp (-m64/-m32) on x86_64-pc-linux-gnu
takes just 3m36 on a 2.67 GHz Xeon X7542 with default checking options;
nothing to worry about for the common case.

Rainer

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |lto

--- Comment #10 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #8)
> Started with r238959.

The point of this change is that the explicit instantiations do not include the
new C++17-only functions, because they're compiled with -std=gnu++11. I didn't
want to instantiate and export new experimental C++17 symbols until we know
they're stable.

But it shouldn't matter, the files compiled as C++17 should implicitly
instantiate everything they need, so if those symbols go missing that's a bug
in the compiler or LTO plugin, not libstdc++.

[Bug c++/81016] [7/8 Regression] ICE: segfault with template struct specialisation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.2

[Bug c++/81011] [6/7/8 Regression] ICE with #pragma omp task and inaccessible copy-constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |6.1.0
   Target Milestone|--- |6.4

[Bug c++/81013] [7/8 Regression] ICE with invalid union in class hierarchy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |7.1.0
   Target Milestone|--- |7.2