[Bug c++/71207] gcc 5.3 and 6.1 generates wrong code with -O2

[vladimir.simonov at acronis dot com]

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

Vladimir Simonov  changed:

   What|Removed |Added

   Severity|blocker |critical

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.0

[Bug c++/71209] [c++] erroneous 'is not a base class of' error

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ryan.burn at gmail dot com

--- Comment #2 from Markus Trippelsdorf  ---
*** Bug 71209 has been marked as a duplicate of this bug. ***

[Bug c++/70448] ICE on invalid code on x86_64-linux-gnu: unexpected expression ‘f’ of kind overload

[rippey.e at gmail dot com]

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

rippey.e at gmail dot com changed:

   What|Removed |Added

 CC||rippey.e at gmail dot com

--- Comment #5 from rippey.e at gmail dot com ---
I also ran into this on g++ 6.1.0 with the following code:

template
void f(){}

enum{n=f};

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---

This patch regression tests OK and fixes the namelist read.


diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index b8e174c5..6ea6007a 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -418,7 +418,7 @@ eat_spaces (st_parameter_dt *dtp)
   /* Now skip spaces, EOF and EOL are handled in next_char.  */
   do
 c = next_char (dtp);
-  while (c != EOF && (c == ' ' || c == '\t'));
+  while (c != EOF && (c == ' ' || c == '\t' || c == '\r'));

   unget_char (dtp, c);
   return c;

[Bug other/71212] New: Compilation of gcc (libstdc++) for foreign target platform problem.

[abominable-snowman at yandex dot ru]

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

Bug ID: 71212
   Summary: Compilation of gcc (libstdc++) for foreign target
platform problem.
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abominable-snowman at yandex dot ru
  Target Milestone: ---

gcc: git's tag gcc-6_1_0-release (c441d9e8e0438dcf54274ec7a3539859e94ad201)

Compilation of gcc for foreign target platform problem.

Host arch is x86_64, target arch is arm (arm32).

Configuration is:

(cd build-gcc && DESTDIR=${SYSROOT} \
AR_FOR_TARGET=${TARGET_CROSS_PREFIX}-ar \
AS_FOR_TARGET=${TARGET_CROSS_PREFIX}-as \
CC_FOR_TARGET=${TARGET_CROSS_PREFIX}-gcc \
CXX_FOR_TARGET=${TARGET_CROSS_PREFIX}-c++ \
CPP_FOR_TARGET=${TARGET_CROSS_PREFIX}-cpp \
LD_FOR_TARGET=${TARGET_CROSS_PREFIX}-ld \
../gcc/configure \
--prefix=/usr \
--host=${TARGET_CROSS} \
--target=${TARGET_OS} \
--enable-shared \
${MULTILIB} \
${_WITH_FLOAT} \
--disable-multiarch \
--with-arch=${TARGET_ARCH_AUX2} --with-tune=${TARGET_CPU} \
--enable-threads=posix \
--enable-__cxa_atexit \
--enable-c99 \
--enable-long-long \
--enable-clocale=gnu \
--enable-languages=c,c++ \
--disable-libstdcxx-pch \
--without-cloog \
--disable-bootstrap \
--disable-install-libiberty \
--with-system-zlib)


Problem is in libstdc++ building, and I suspend that problem come from
libtool:

make[7]: Entering directory
'/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX   --mode=compile
/export/staging/ptr/continuous/toolchain-arm-continuous-linux-gnueabi/bin/arm-continuous-linux-gnueabi-c++

-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include/arm-unknown-linux-gnueabi
-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include
-I/export/staging/ptr/continuous/development/gcc/libstdc++-v3/libsupc++
-I/usr/include   -std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=compatibility.lo -g -O2
-D_GNU_SOURCE  -c -o compatibility.lo
../../../../gcc/libstdc++-v3/src/c++98/compatibility.cc

...
libtool: compile: 
/export/staging/ptr/continuous/toolchain-arm-continuous-linux-gnueabi/bin/arm-continuous-linux-gnueabi-c++
-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include/arm-unknown-linux-gnueabi
-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include
-I/export/staging/ptr/continuous/development/gcc/libstdc++-v3/libsupc++
-I/usr/include -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=compatibility.lo -g -O2
-D_GNU_SOURCE -c ../../../../gcc/libstdc++-v3/src/c++98/compatibility.cc  -fPIC
-DPIC -D_GLIBCXX_SHARED -o .libs/compatibility.o
...

In file included from /usr/include/math.h:427:0,
 from
/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include/cmath:45,
 from
../../../../gcc/libstdc++-v3/src/c++98/compatibility.cc:50:
/usr/include/bits/mathinline.h: In function ‘double __ceill_wrapper(double)’:
/usr/include/bits/mathinline.h:764:1: error: invalid 'asm': invalid operand for
code 'w'
 __inline_mathcodeNP (ceil, __x, \
 ^
Makefile:623: recipe for target 'compatibility.lo' failed


You see -I/usr/include, that cause problem. Compiler see in host's
/usr/include/math.h that has different from target arch. Without it compilation
is fine:

(cd development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/src && /bin/sh
../libtool --tag CXX   --mode=compile
/export/staging/ptr/continuous/toolchain-arm-continuous-linux-gnueabi/bin/arm-continuous-linux-gnueabi-c++

-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include/arm-unknown-linux-gnueabi
-I/export/staging/ptr/continuous/development/build-gcc/arm-unknown-linux-gnueabi/libstdc++-v3/include
-I/export/staging/ptr/continuous/development/gcc/libstdc++-v3/libsupc++
-std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once   -ffunction-sections
-fdata-sections  -frandom-seed=compatibility.lo -g -O2 -D_GNU_SOURCE  -c -o
compatibility.lo ../../../../gcc/libstdc++-v3/src/c++98/compatibility.cc)
libtool: compile: 

[Bug c++/71210] New: internal compiler error: in assign_temp, at function.c:961

[cas43 at cs dot stanford.edu]

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

Bug ID: 71210
   Summary: internal compiler error: in assign_temp, at
function.c:961
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cas43 at cs dot stanford.edu
  Target Milestone: ---

PROGRAM:


namespace std {class type_info { };}
[[noreturn]] void f1(const std::type_info& type);
struct S1{~S1();};
struct S2
{
virtual S1 f2() const { f1(typeid(*this)); } 
S1 f3() const { return f2(); } 
};
void f4() { S2 a; a.f3(); } 


RESULT:


prog.cpp: In function ‘void f4()’:
prog.cpp:7:31: internal compiler error: in assign_temp, at function.c:961
 S1 f3() const { return f2(); }
   ^
0xaa9163 assign_temp(tree_node*, int, int)
../../s-trunk/gcc/function.c:961
0x92fbb7 expand_call(tree_node*, rtx_def*, int)
../../s-trunk/gcc/calls.c:2569
0xa3fbcc expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../s-trunk/gcc/expr.c:10460
0x94069a expand_expr
../../s-trunk/gcc/expr.h:272
0x94069a expand_call_stmt
../../s-trunk/gcc/cfgexpand.c:2660
0x94069a expand_gimple_stmt_1
../../s-trunk/gcc/cfgexpand.c:3548
0x94069a expand_gimple_stmt
../../s-trunk/gcc/cfgexpand.c:3714
0x941d76 expand_gimple_basic_block
../../s-trunk/gcc/cfgexpand.c:5720
0x947ed6 execute
../../s-trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


HOW TO RUN:


g++ -c -O2 prog.cpp


NOTES:


No ICE with -O1.


COMPILER VERSION:

Using built-in specs.
COLLECT_GCC=/home/craig/new-gcc/i-trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../s-trunk/configure --prefix=/home/craig/new-gcc/i-trunk
Thread model: posix
gcc version 7.0.0 20160519 (experimental) (GCC)

[Bug c++/71209] New: [c++] erroneous 'is not a base class of' error

[ryan.burn at gmail dot com]

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

Bug ID: 71209
   Summary: [c++] erroneous 'is not a base class of' error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code compiles fine with clang and a version of gcc build from trunk
on 20160428, but with the trunk version from 20160519, it gives this bad error
message:

 B::B()
a.cpp:7:18: error: ‘A’ is not a base of ‘B’
   B() { this->A::table_clear; }

The bugs causing major libraries like intel's TBB not to compile.

//
class A {   
  int table_clear;  
};  

template
class B : T {   
  B() { this->A::table_clear; } 
};  

int main() {} 
//

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
GCC does think that some path may dereference a null pointer since this block
survives until the end:

;;   basic block 109, loop depth 0, count 0, freq 743, maybe hot
;;   Invalid sum of incoming frequencies 5, should be 743
;;prev block 108, next block 1, flags: (NEW, REACHABLE)
;;pred:   59 [15.0%]  (FALSE_VALUE,EXECUTABLE)
;;   starting at line 7841
  [pr71157.c:7841:12] # VUSE <.MEM_63>
  _402 ={v} [pr71157.c:7841:12] MEM[(charD.7 *)0B];
  # .MEM_388 = VDEF <.MEM_63>
  # USE = nonlocal null { D.5991 } (nonlocal, escaped)
  # CLB = nonlocal null { D.5991 } (nonlocal, escaped)
  __builtin_trapD.1024 ();
;;succ:

this is because it thinks skip_space() may return NULL:

;;   basic block 59, loop depth 2, count 0, freq 36, maybe hot
;;prev block 58, next block 60, flags: (NEW, REACHABLE)
;;pred:   57 [29.0%]  (TRUE_VALUE,EXECUTABLE)
;;   starting at line 7764, discriminator 2
  [pr71157.c:7764:133] # PT = nonlocal escaped null
  _200 = cp_11 + 12;
  [pr71157.c:7764:122] # VUSE <.MEM_63>
  # PT = nonlocal escaped null
  # USE = nonlocal escaped null
  cp_201 = skip_spacesD.5937 (_200);
  [pr71157.c:7764:122] if (cp_201 != 0B)
goto ;
  else
goto ;
;;succ:   61 [85.0%]  (TRUE_VALUE,EXECUTABLE)
;;109 [15.0%]  (FALSE_VALUE,EXECUTABLE)


The location shown is just an artifact of merging expressions and not
preserving the right locations. The middle-end is not very smart at that, this
is why middle-end warnings are often confusing.

The testcase is too large for me to analyze further.

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[eggert at gnu dot org]

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

--- Comment #4 from Paul Eggert  ---
I worked around the GCC bug by applying the attached file etags.c.patch to GNU
Emacs. etags.c.patch replaces some weird but valid C code (add a small constant
to a pointer and test whether the resulting pointer is non-null, a test that
always yields 1) with more-normal code (add a small constant to a pointer, then
yield 1). After preprocessing, this yields the attached file e-patched.i, and
the command 'gcc -O2 -S -Wnull-dereference e-patched.i' does not issue the
bogus warnings.

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[eggert at gnu dot org]

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

--- Comment #3 from Paul Eggert  ---
Created attachment 38532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38532=edit
patched version of e.i that avoids GCC bug

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[eggert at gnu dot org]

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

--- Comment #2 from Paul Eggert  ---
Created attachment 38531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38531=edit
GNU Emacs lib-src/etags.c patch to work around GCC bug

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
I am starting a bootstrap+regtest with:

 /* (X ^ Y) ^ (X ^ Z) -> Y ^ Z  */
 (simplify
  (bit_xor (convert1? (bit_xor:c @0 @1)) (convert2? (bit_xor:c @0 @2)))
  (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
   && tree_nop_conversion_p (type, TREE_TYPE (@2)))
-  (convert (bit_xor @1 @2
+  (bit_xor (convert @1) (convert @2

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I haven't yet started, so if you want to take it, it is all yours.

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
With -O:

int f(int d, unsigned b) {
int i2 = b ^ 1;
int i4 = d ^ 1;
return i2 ^ i4;
}

An extra (convert ...) should do it I guess.

[Bug target/71208] New: [6 regression] mmix: C++ code fails to link

[yselkowi at redhat dot com]

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

Bug ID: 71208
   Summary: [6 regression] mmix: C++ code fails to link
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yselkowi at redhat dot com
  Target Milestone: ---
  Host: x86_64-cygwin
Target: mmix-knuth-mmixware
 Build: x86_64-cygwin

Created attachment 38530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38530=edit
Test case

Even simple C++ code fails to link when compiled with mmix g++ 6.1.0, binutils
2.26 and newlib 2.4.0:

$ mmix-g++ hello.cc
/usr/lib/gcc/mmix/6.1.0/../../../../mmix/bin/ld: BFD (GNU Binutils)
2.26.20160125 internal error, aborting at bfd/elf64-mmix.c:1043 in
mmix_elf_perform_relocation

Compiling with 5.3.0 (and the same binutils and newlib) succeeds.

[Bug c++/71207] gcc 5.3 and 6.1 generates wrong code with -O2

[vladimir.simonov at acronis dot com]

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

Vladimir Simonov  changed:

   What|Removed |Added

Version|unknown |5.3.0

--- Comment #1 from Vladimir Simonov  ---
TBD, here is full output from Fedora 24 gcc 5.3.1
.file   "qq.cpp"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  _Z9Function2v
.type   _Z9Function2v, @function
_Z9Function2v:
.LFB1:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movq%rsp, %rdi
call_ZN6Class4C1Ev
.cfi_endproc
.LFE1:
.size   _Z9Function2v, .-_Z9Function2v
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.3.1 20160406 (Red Hat 5.3.1-6)"
.section.note.GNU-stack,"",@progbits

[Bug c++/70494] [5 regression] Internal Compiler Error: Capturing an array of vectors in a lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 5.4.

[Bug c++/71207] New: gcc 5.3 and 6.1 generates wrong code with -O2

[vladimir.simonov at acronis dot com]

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

Bug ID: 71207
   Summary: gcc 5.3 and 6.1 generates wrong code with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.simonov at acronis dot com
  Target Milestone: ---

Hi,

Quite simple and common pattern:
class Class1
{
public:
  Class1();
  virtual ~Class1();

protected:
  unsigned Field1;
};

class Class2 : public virtual Class1
{
};

class Class3 : public virtual Class1
{
public:
  virtual void Method1() = 0;

  void Method2()
  {
Method1();
  }
};

class Class4 : public Class2, public virtual Class3
{
public:
  Class4();
  virtual void Method1();
};

void Function1();

void Function2()
{
  Class4 var1;
  var1.Method2();
  Function1();
}

gcc 5.3 and 6.1 for x86_64/i686 with -O2 produces:
.Ltext0:
Function2():
.LFB1:
subq$40, %rsp
movq%rsp, %rdi
callClass4::Class4()
.LVL0:
.LFE1:
.Letext0:
...

var1.Method2() and Function1() calls are not generated.

I've tried both 5.3.0 and 6.1
Please see:
https://gcc.godbolt.org/#compilers:!((compiler:g6,options:'-O2',sourcez:MYGwhgzhAEDC5QIwCgDeyAOBXARiAlsAFzLRwISIAUAlANynQBu%2BATgC5ZgjQB%2B8kSrQaZWAe3YBTYFIAmJMlgB2EfAHMlk2dABi%2BSSFmIGAXxGhB5QQCZoRaNjyFmbTtytI0yM8mQWoHhAAzHYOuATALhxcPAKe6I4RClFuPExi%2BNoAspLsABZiRrTQALzQAAwiZOmZ0Dn5hda0jOhkZPUFRfSMJt7mFIEALKGJznEQ1gA0YU6RLNHu40Feo8SM44PCjPOpzBnZuZ3U3T7INdo6yjL4YkrHIue6V%2Bw3Sk00XmQbzGCsxtu/RAAOg6jS2ZEuSmut3u3mQQAA)),filterAsm:(commentOnly:!t,directives:!t),version:3


Thank you
Vladimir

[Bug tree-optimization/71206] [7 Regression] ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||jakub at gcc dot gnu.org
Version|6.0 |7.0
   Target Milestone|--- |7.0
Summary|ICE on valid code at all|[7 Regression] ICE on valid
   |optimization levels in both |code at all optimization
   |32-bit and 64-bit modes on  |levels in both 32-bit and
   |x86_64-linux-gnu.   |64-bit modes on
   |(verify_gimple failed)  |x86_64-linux-gnu.
   ||(verify_gimple failed)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r236103.  I'll have a look.

[Bug tree-optimization/71206] New: ICE on valid code at all optimization levels in both 32-bit and 64-bit modes on x86_64-linux-gnu. (verify_gimple failed)

[chengniansun at gmail dot com]

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

Bug ID: 71206
   Summary: ICE on valid code at all optimization levels in both
32-bit and 64-bit modes on x86_64-linux-gnu.
(verify_gimple failed)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes the trunk at all optimization levels in both 32-bit
and 64-bit modes on x86_64-linux-gnu. 


$: 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/7.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 7.0.0 20160519 (experimental) [trunk revision 236439] (GCC)
$:
$: gcc-trunk -O0 small.c
small.c: In function ‘fn1’:
small.c:4:6: error: type mismatch in binary expression
 void fn1() { fn1(b ^ (2 || c) ^ ((a || 3) ^ d)); }
  ^~~
unsigned int

unsigned int

int

_3 = b.0_1 ^ d.1_2;
small.c:4:6: internal compiler error: verify_gimple failed
0xbdf79d verify_gimple_in_seq(gimple*)
../../gcc-source-trunk/gcc/tree-cfg.c:4833
0x950c71 gimplify_body(tree_node*, bool)
../../gcc-source-trunk/gcc/gimplify.c:11548
0x9510a6 gimplify_function_tree(tree_node*)
../../gcc-source-trunk/gcc/gimplify.c:11636
0x7b62f7 cgraph_node::analyze()
../../gcc-source-trunk/gcc/cgraphunit.c:625
0x7b951b analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1086
0x7ba09c symbol_table::finalize_compilation_unit()
../../gcc-source-trunk/gcc/cgraphunit.c:2543
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$:
$: cat small.c
char a;
unsigned b;
int c, d;
void fn1() { fn1(b ^ (2 || c) ^ ((a || 3) ^ d)); }

int main() {}

[Bug rtl-optimization/71148] [7 Regression] Compile time hog w/ -O3 -funroll-loops

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Fixed by r236460.

Thanks.  Please add a reference to the PR in the ChangeLog next time, this will
automatically add a cross-reference in the audit trail.

[Bug c/71171] [6/7 Regression] Conditional jump or move depends on uninitialised value(s) in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed on both trunk and gcc-6-branch.

[Bug c/71171] [6/7 Regression] Conditional jump or move depends on uninitialised value(s) in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu May 19 20:33:51 2016
New Revision: 236489

URL: https://gcc.gnu.org/viewcvs?rev=236489=gcc=rev
Log:
PR c/71171: Fix uninitialized source_range in c_parser_postfix_expression

A common way for a c_expr to have an uninitialized src_range is in
error-handling, where the "value" field is set to error_mark_node
without touching the src_range, leading to complaints from valgrind.

This patch introduces a new method c_expr::set_error which sets
the value to error_mark_node whilst initializing the src_range to
UNKNOWN_LOCATION.

This fixes the valgrind issue seen in PR c/71171, along with various
other related issues seen when running the testsuite using the
checker patch I posted here:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00887.html
(this checker still doesn't fully work yet, but it seems to be good
for easily detecting these issues without needing Valgrind).

gcc/c/ChangeLog:
Backport from trunk r236488.
PR c/71171
* c-parser.c (c_parser_generic_selection): Use c_expr::set_error
in error-handling.
(c_parser_postfix_expression): Likewise.
* c-tree.h (c_expr::set_error): New method.
* c-typeck.c (parser_build_binary_op): In error-handling, ensure
that result's range is initialized.


Modified:
branches/gcc-6-branch/gcc/c/ChangeLog
branches/gcc-6-branch/gcc/c/c-parser.c
branches/gcc-6-branch/gcc/c/c-tree.h
branches/gcc-6-branch/gcc/c/c-typeck.c

[Bug c/71171] [6/7 Regression] Conditional jump or move depends on uninitialised value(s) in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Thu May 19 20:29:07 2016
New Revision: 236488

URL: https://gcc.gnu.org/viewcvs?rev=236488=gcc=rev
Log:
PR c/71171: Fix uninitialized source_range in c_parser_postfix_expression

A common way for a c_expr to have an uninitialized src_range is in
error-handling, where the "value" field is set to error_mark_node
without touching the src_range, leading to complaints from valgrind.

This patch introduces a new method c_expr::set_error which sets
the value to error_mark_node whilst initializing the src_range to
UNKNOWN_LOCATION.

This fixes the valgrind issue seen in PR c/71171, along with various
other related issues seen when running the testsuite using the
checker patch I posted here:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00887.html
(this checker still doesn't fully work yet, but it seems to be good
for easily detecting these issues without needing Valgrind).

gcc/c/ChangeLog:
PR c/71171
* c-parser.c (c_parser_generic_selection): Use c_expr::set_error
in error-handling.
(c_parser_postfix_expression): Likewise.
* c-tree.h (c_expr::set_error): New method.
* c-typeck.c (parser_build_binary_op): In error-handling, ensure
that result's range is initialized.


Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c

[Bug c++/71075] Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
Forgotten to mention subcases :

$ cat z3a.f90
program p
   character(3), parameter :: a(4) = ' '
   character(*), parameter :: x(*) = a(1:2)(3:1)
end

$ gfortran-6 z3a.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory
corruption: 0x02873390 ***



$ cat z3b.f90
program p
   character(3), parameter :: a(4) = ' '
   character(*), parameter :: x(*) = a(2:2)(3:0)
end

$ gfortran-6 z3b.f90
f951: out of memory allocating 18446744073709551612 bytes after a total of
634880 bytes

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[fdumont at gcc dot gnu.org]

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

--- Comment #4 from François Dumont  ---
I guess you are talking about 61667.

I think this report is quite new. At the moment reserve is implemented as
proposed by the Standard but I agree with Alexey that demonstrated behavior is
counterintuitive. I will propose a patch soon.

[Bug c++/71075] Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 19 20:23:52 2016
New Revision: 236487

URL: https://gcc.gnu.org/viewcvs?rev=236487=gcc=rev
Log:
PR c++/71075
* pt.c (unify_template_argument_mismatch): Use %qE instead of %qD.

* g++.dg/diagnostic/pr71075.C: New test.

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

[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #3 from Gerhard Steinmetz  
---
Another situation :

$ cat z4.f90
program p
   character(3) :: a(2) = ['abc', 'xyz']
   character(3) :: b(1,2) = ' '
   equivalence (b, a)
end

$ gfortran-6 z4.f90
internal compiler error: in gfc_encode_character, at
fortran/target-memory.c:227

---

Interestingly, this works without initializer of b :

$ cat z5.f90
program p
   character(3) :: a(2) = ['abc', 'xyz']
   character(3) :: b(1,2)
   equivalence (b, a)
   print *, b
end

$ gfortran-6 z5.f90
$ a.out
 abcxyz


Even more, with option -finit-character/-finit-local-zero :

$ gfortran-6 -g -O0 -Wall -fcheck=all -finit-character=7 z5.f90
$ a.out
 abcxyz

[Bug c++/71205] New: c++14 wrong constructor resolution

[dushistov at mail dot ru]

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

Bug ID: 71205
   Summary: c++14 wrong constructor resolution
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

#include 
#include 

#define SHOW std::cout << __PRETTY_FUNCTION__ << "\n"

struct Foo {
Foo() { SHOW; }
Foo(const Foo &) { SHOW; }
Foo(Foo &&) { SHOW; }

Foo(std::initializer_list) { SHOW; }
};

int main() {
Foo b;
Foo x = Foo { b };
}

accroding to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1467
and
http://en.cppreference.com/w/cpp/language/list_initialization

If T is a class type and the initializer list has a single element of the same
or derived type (possibly cv-qualified), the object is initialized from that
element (by copy-initialization for copy-list-initialization, or by
direct-initialization for direct-list-initialization).

This code should print:
Foo::Foo()
Foo::Foo(const Foo &)

clang (3.8.0) and mvsc++ print lines above, but
gcc (5.2, 6.1.1) print (g++ -std=c++14 -pedantic test.cpp):

Foo::Foo()
Foo::Foo(const Foo&)
Foo::Foo(std::initializer_list)


which is wrong

[Bug c++/71075] Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0

[Bug rtl-optimization/71148] [7 Regression] Compile time hog w/ -O3 -funroll-loops

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Fixed by r236460.

[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes

[jason at gcc dot gnu.org]

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

--- Comment #39 from Jason Merrill  ---
Author: jason
Date: Thu May 19 19:20:40 2016
New Revision: 236486

URL: https://gcc.gnu.org/viewcvs?rev=236486=gcc=rev
Log:
Fix handling of non-dependent calls with default template args.

PR c++/10200
* pt.c (fn_type_unification): Add outer template args if needed.
(type_unification_real): Handle getting full args.

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

[Bug fortran/71204] [5/6/7 Regression] ICE with -O0 in expand_expr_real_1, at expr.c:9651

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||jakub at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
   Target Milestone|--- |5.4
Summary|ICE with -O0 in |[5/6/7 Regression] ICE with
   |expand_expr_real_1, at  |-O0 in expand_expr_real_1,
   |expr.c:9651 |at expr.c:9651
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
ICE started with r219195.

[Bug fortran/71204] New: ICE with -O0 in expand_expr_real_1, at expr.c:9651

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71204
   Summary: ICE with -O0 in expand_expr_real_1, at expr.c:9651
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Full reduction and simplification from a production code base
results in the following reproducer, aborting at -O0 :


$ cat z1.f90
module m
   character(10), allocatable :: z(:)
end module

subroutine s1
   use m
   z(2) = z(1)
end

subroutine s2
   use m
   z(2) = z(1)
end


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]

$ gfortran-6 -O2 -c z1.f90
$ gfortran-6 -O1 -c z1.f90
$ gfortran-6 -O0 -c z1.f90
z1.f90:12:0:

z(2) = z(1)

internal compiler error: in expand_expr_real_1, at expr.c:9651

[Bug c++/71184] ICE on "operator new["

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed on both trunk and gcc-6-branch

[Bug c++/71184] ICE on "operator new["

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Thu May 19 18:56:47 2016
New Revision: 236485

URL: https://gcc.gnu.org/viewcvs?rev=236485=gcc=rev
Log:
PR c++/71184: Fix NULL dereference in cp_parser_operator

The source-range handling for the array form of operator
new/delete erroneously assumed that the "]" was present,
leading to a dereference of NULL when it's absent.

Fix it thusly.

gcc/cp/ChangeLog:
Backport from trunk r236483.
PR c++/71184
* parser.c (cp_parser_operator): For array new/delete, check that
cp_parser_require returned a non-NULL token before dereferencing
it.

gcc/testsuite/ChangeLog:
Backport from trunk r236483.
PR c++/71184
* g++.dg/pr71184.C: New test case.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71184.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/71203] New: ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71203
   Summary: ICE in add_init_expr_to_sym, at fortran/decl.c:1512
and :1564
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

While exploring "source space" around pr68019 and pr68154,
another issue came into focus :


$ cat z1.f90
program p
   character(3), parameter :: a(4) = ' '
   character(*), parameter :: x(0) = a(2:1)
end

$ gfortran-6 z1.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1512



$ cat z2.f90
program p
   character(3), parameter :: a(4) = ' '
   character(*), parameter :: x(*) = a(2:1)
end

$ gfortran-6 z2.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1512



$ cat z3.f90
program p
   character(*), parameter :: a(4) = ' '
   character(*), parameter :: x(*) = a(1:2)(3:1)
end

$ gfortran-6 z3.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': malloc(): memory
corruption: 0x032ff390 ***

[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
$ cat z4.f90
program p
   integer :: i
   integer, parameter :: x(2) = 0
   integer, parameter :: y(*) = [(x(i:i), i=1,2)]
end

$ gfortran-6 z4.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1564



$ cat z5.f90
program p
   integer :: i
   integer, parameter :: x(2,2) = 0
   integer, parameter :: y(*) = [(x(i:i,i), i=1,2)]
end

$ gfortran-6 z5.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1564

[Bug bootstrap/71198] [7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> PR71148?

Patch in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71148#c4

fixed the bootstrap.

[Bug bootstrap/71198] [7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #3 from H.J. Lu  ---


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

[Bug rtl-optimization/71148] [7 Regression] Compile time hog w/ -O3 -funroll-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 71198 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71031] [6 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #16 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/71031] [6 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 19 18:42:31 2016
New Revision: 236484

URL: https://gcc.gnu.org/viewcvs?rev=236484=gcc=rev
Log:
PR tree-optimization/71031
* tree-vrp.c (extract_range_from_binary_expr_1): Turn assert into a
condition and adjust the code a bit.

* gcc.dg/tree-ssa/vrp100.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/vrp100.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-vrp.c

[Bug c++/71184] ICE on "operator new["

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu May 19 18:10:30 2016
New Revision: 236483

URL: https://gcc.gnu.org/viewcvs?rev=236483=gcc=rev
Log:
PR c++/71184: Fix NULL dereference in cp_parser_operator

The source-range handling for the array form of operator
new/delete erroneously assumed that the "]" was present,
leading to a dereference of NULL when it's absent.

Fix it thusly.

gcc/cp/ChangeLog:
PR c++/71184
* parser.c (cp_parser_operator): For array new/delete, check that
cp_parser_require returned a non-NULL token before dereferencing
it.

gcc/testsuite/ChangeLog:
PR c++/71184
* g++.dg/pr71184.C: New test case.


Added:
trunk/gcc/testsuite/g++.dg/pr71184.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70865] [cilkplus] errors when using cilk features with precompiled headers

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #1 from Jeffrey A. Law  ---
Should be fixed by Ryan's patch on the trunk.

[Bug other/69582] [meta-bug] Cilk+

[law at redhat dot com]

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

Bug 70865 Summary: [cilkplus] errors when using cilk features with precompiled 
headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70865

   What|Removed |Added

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

[Bug c/71202] GCC's -funsigned-char ignored by -Wpointer-sign

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
There are three distant types for char:
char, unsigned char, signed char.

-funsigned-char/-fsigned-char just changes the signedness of the pain char
type, it does not change the type of char to be one of the other types.

[Bug c/71202] New: GCC's -funsigned-char ignored by -Wpointer-sign

[ideasman42 at gmail dot com]

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

Bug ID: 71202
   Summary: GCC's -funsigned-char ignored by -Wpointer-sign
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ideasman42 at gmail dot com
  Target Milestone: ---

Created attachment 38529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38529=edit
Source file to reproduce the bug.

When passing `char *` arguments to functions which take a `unsigned char *`,
this raises a -Wpointer-sign warning, even when `-funsigned-char` is used.

Attached source file:

Compile with:

  gcc -funsigned-char -Wall foo.c

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[manu at gcc dot gnu.org]

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

--- Comment #23 from Manuel López-Ibáñez  ---
(In reply to shatz from comment #22)
> It sucks. The software can't be changed after release, for obvious reasons,
> but docs are not software. 
> If it's impossible to change the policy about not fixing mistakes in docs,
> then, may be, it is possible to add documentation errata?

Once it is out there, we cannot change every possible copy of a released
version. We can change the docs for future releases, but we do not make new
releases just for small documentation changes, it has wait (like actual
important bugs) for the normal release schedule:
https://gcc.gnu.org/develop.html

You can always use directly the SVN/Git version of one of the stable branches.
If you wish to see more frequent releases or backport a particular change to a
stable branch, I encourage you to take a more active role (which is the beauty
of free software as opposed to proprietary): 
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

We do what we can with the time that we have.

[Bug c++/71197] for range loop causes an error with inline function references

[heirecka at exherbo dot org]

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

Heiko Becker  changed:

   What|Removed |Added

 CC||heirecka at exherbo dot org

--- Comment #2 from Heiko Becker  ---
I think I'm seeing the same with this code:

https://git.exherbo.org/paludis/paludis.git/tree/paludis/resolver/collect_depped_upon.cc#n242

collect_depped_upon.cc: In function 'const std::shared_ptr >
paludis::resolver::dependent_upon(const paludis::Environment*, const
std::shared_ptr&, const std::shared_ptr >&, const
std::shared_ptr
>&, const std::shared_ptr > >&)':
collect_depped_upon.cc:243:131: internal compiler error: in add_expr, at
tree.c:7870
 for (auto& fn : { ::build_dependencies_key,
::run_dependencies_key, ::post_dependencies_key })

[Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to georg.bugzilla from comment #0)

> module ice
> 
> type substructure_
>integer :: id
>character(16) :: value
> end type substructure_
> 
> type structure_
>type(substructure_) :: element
> end type structure_
> 
> type(structure_) :: structure
> 
> DATA structure%element%id / 1 /
> DATA structure%element%value / "test" /
> 
> end module ice

As a workaround you can invert the order of components
in substructure_, so try

type substructure_
   character(16) :: value
   integer :: id
end type substructure_

Another workaround would be to use a structure constructor
in the DATA statement.  With you original example, you can
do

DATA structure%element / substructure_(1,"test") /

Yet, another workaround would be use of explicit initialization
in the declaration, but it's a little ugly

type(structure_) :: structure = structure_(substructure_(1,"test"))

[Bug tree-optimization/71031] [6 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |extract_range_from_binary_e |extract_range_from_binary_e
   |xpr_1, at tree-vrp.c:2535   |xpr_1, at tree-vrp.c:2535
   |w/ -Os  |w/ -Os

--- Comment #14 from Marek Polacek  ---
Fixed on the trunk so far.

[Bug tree-optimization/71031] [6/7 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 19 15:45:35 2016
New Revision: 236477

URL: https://gcc.gnu.org/viewcvs?rev=236477=gcc=rev
Log:
PR tree-optimization/71031
* tree-vrp.c (extract_range_from_binary_expr_1): Turn assert into a
condition and adjust the code a bit.

* gcc.dg/tree-ssa/vrp100.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp100.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #40 from Martin Jambor  ---
Fixed on all branches.

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #39 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 15:19:59 2016
New Revision: 236476

URL: https://gcc.gnu.org/viewcvs?rev=236476=gcc=rev
Log:
Respect --param ipa-max-agg-items=0

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-prop.c (determine_locally_known_aggregate_parts): Bail out early
if parameter PARAM_IPA_MAX_AGG_ITEMS is zero.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ipa-prop.c

[Bug c++/71075] Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
This should fix it:

--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1269,6 +1269,14 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
   dump_type (pp, t, flags);
   break;

+case VOID_CST:
+case INTEGER_CST:
+case REAL_CST:
+case STRING_CST:
+case COMPLEX_CST:
+  pp->constant (t);
+  break;
+
 default:
   pp_unsupported_tree (pp, t);
   /* Fall through to error.  */

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #38 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 15:17:10 2016
New Revision: 236475

URL: https://gcc.gnu.org/viewcvs?rev=236475=gcc=rev
Log:
[PR 70646] Store size to inlining predicate conditions

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-inline.h (condition): New field size.
* ipa-inline-analysis.c (add_condition): New parameter SIZE, use it
for comaprison and store it into the new condition.
(evaluate_conditions_for_known_args): Use condition size to check
access sizes for all but CHANGED conditions.
(unmodified_parm_1): New parameter size_p, store access size into it.
(unmodified_parm): Likewise.
(unmodified_parm_or_parm_agg_item): Likewise.
(eliminated_by_inlining_prob): Pass NULL to unmodified_parm as size_p.
(set_cond_stmt_execution_predicate): Extract access sizes and store
them to conditions.
(set_switch_stmt_execution_predicate): Likewise.
(will_be_nonconstant_expr_predicate): Likewise.
(will_be_nonconstant_predicate): Likewise.
(inline_read_section): Stream condition size.
(inline_write_summary): Likewise.
* lto-streamer.h (LTO_minor_version): Bump.
* ipa-prop.c (ipa_load_from_parm_agg): Added size_p parameter, pass it
to ipa_load_from_parm_agg_1.
* ipa-prop.h (ipa_load_from_parm_agg): Update declaration.

testsuite/
* gcc.dg/ipa/pr70646.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/ipa/pr70646.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ipa-inline-analysis.c
branches/gcc-4_9-branch/gcc/ipa-inline.h
branches/gcc-4_9-branch/gcc/ipa-prop.c
branches/gcc-4_9-branch/gcc/ipa-prop.h
branches/gcc-4_9-branch/gcc/lto-streamer.h
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/71075] Broken diagnostic: 'integer_cst' not supported by 'dump_decl'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I see, thanks for confirming.  Closing thus.

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #37 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 15:10:50 2016
New Revision: 236474

URL: https://gcc.gnu.org/viewcvs?rev=236474=gcc=rev
Log:
Respect --param ipa-max-agg-items=0

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-prop.c (determine_locally_known_aggregate_parts): Bail out early
if parameter PARAM_IPA_MAX_AGG_ITEMS is zero.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ipa-prop.c

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

[mar...@mpa-garching.mpg.de]

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

--- Comment #3 from Martin Reinecke  ---
In fact, the problem seems to have been patched away very recently.
With a fresh checkout of gcc trunk the test case compiles fine. Sorry for the
noise!

Should I close the bug as resolved/fixed?

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #36 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 15:09:21 2016
New Revision: 236473

URL: https://gcc.gnu.org/viewcvs?rev=236473=gcc=rev
Log:
[PR 70646] Store size to inlining predicate conditions

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-inline.h (condition): New field size.
* ipa-inline-analysis.c (add_condition): New parameter SIZE, use it
for comaprison and store it into the new condition.
(evaluate_conditions_for_known_args): Use condition size to check
access sizes for all but CHANGED conditions.
(unmodified_parm_1): New parameter size_p, store access size into it.
(unmodified_parm): Likewise.
(unmodified_parm_or_parm_agg_item): Likewise.
(eliminated_by_inlining_prob): Pass NULL to unmodified_parm as size_p.
(set_cond_stmt_execution_predicate): Extract access sizes and store
them to conditions.
(set_switch_stmt_execution_predicate): Likewise.
(will_be_nonconstant_expr_predicate): Likewise.
(will_be_nonconstant_predicate): Likewise.
(inline_read_section): Stream condition size.
(inline_write_summary): Likewise.
* lto-streamer.h (LTO_minor_version): Bump.

testsuite/
* gcc.dg/ipa/pr70646.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/ipa/pr70646.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ipa-inline-analysis.c
branches/gcc-5-branch/gcc/ipa-inline.h
branches/gcc-5-branch/gcc/lto-streamer.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/71201] PowerPC XXPERM instruction fails on ISA 3.0 system.

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
>From what I can see, the left-shifted piece of this is not being computed
properly. Looks like maybe register allocation is getting confused and not
treating v17/vs49 as the same thing? Hard to follow this with all these xxlor
moving stuff around.

  wc[0] = 0x73;
  for (t = 0; t < 256; ++t)
rc[t] = (wc[t] >> 5) | (wc[t] << (sizeof (wc[0]) * __CHAR_BIT__ - 5));

rc[0] ends up with value 3, which is 0x73>>5. 

Here's the trail of breadcrumbs I tried to follow forward

/home/sawdey/src/gcc/pre-gcc7/pre-gcc7/gcc/testsuite/gcc.c-torture/execute/pr56866.c:31
10001924:   fd ff a2 3f addis   r29,r2,-3
10001928:   fd ff 62 3d addis   r11,r2,-3
1000192c:   59 1d e1 f7 lxv vs63,7504(r1)
10001930:   e9 1d 21 f5 lxv vs41,7648(r1)
10001934:   4c 03 60 11 vspltish v11,0
10001938:   8c 03 83 11 vspltisw v12,3
1000193c:   70 be fd 38 addir7,r29,-16784
10001940:   80 be 8b 3b addir28,r11,-16768
10001944:   21 1d 41 f4 lxv vs2,7456(r1)  load wc[t]
here
10001948:   21 1d 61 f4 lxv vs3,7456(r1)

100019a0:   d6 38 4b f0 xxperm  vs2,vs43,vs39  but then
write over it here? 
100019a4:   d6 50 6b f0 xxperm  vs3,vs43,vs42

10001eac:   29 1d 21 f6 lxv vs49,7456(r1)  
load wc[t] again here

10001f04:   04 fa b1 10 vsrbv5,v17,v31 
shift right piece now in vs37
10001f90:   0e 18 24 12 vpkuhum v17,v4,v3write
over v17/vs49
10002000:   96 8c d1 f3 xxlor   vs30,vs49,vs49  trying
to copy wc[t] to vs30? It's 0 here already

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

--- Comment #22 from shatz at dsit dot co.il ---
(In reply to Jakub Jelinek from comment #21)
> It can't be changed in those manuals, ever, both 6.1 and 5.3 releases have
> already been released, their documentation, including online docs, is what
> has been released at that point.

It sucks. The software can't be changed after release, for obvious reasons, but
docs are not software. 
If it's impossible to change the policy about not fixing mistakes in docs,
then, may be, it is possible to add documentation errata?

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
For atomic Clang rejects use of its builtin with a void*:

/usr/local/libcxx-head/include/c++/v1/atomic:1081:40: error: incomplete type
'void' where a complete type is required

But it allows the function pointer case.

Arguably it makes sense for __atomic_fetch_add etc. to do the checking,
although the fact that GCC does allow arithmetic on void* complicates that.

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #34 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 14:56:35 2016
New Revision: 236462

URL: https://gcc.gnu.org/viewcvs?rev=236462=gcc=rev
Log:
[PR 70646] Store size to inlining predicate conditions

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-inline.h (condition): New field size.
* ipa-inline-analysis.c (add_condition): New parameter SIZE, use it
for comaprison and store it into the new condition.
(evaluate_conditions_for_known_args): Use condition size to check
access sizes for all but CHANGED conditions.
(unmodified_parm_1): New parameter size_p, store access size into it.
(unmodified_parm): Likewise.
(unmodified_parm_or_parm_agg_item): Likewise.
(eliminated_by_inlining_prob): Pass NULL to unmodified_parm as size_p.
(set_cond_stmt_execution_predicate): Extract access sizes and store
them to conditions.
(set_switch_stmt_execution_predicate): Likewise.
(will_be_nonconstant_expr_predicate): Likewise.
(will_be_nonconstant_predicate): Likewise.
(inline_read_section): Stream condition size.
(inline_write_summary): Likewise.
* lto-streamer.h (LTO_minor_version): Bump.

testsuite/
* gcc.dg/ipa/pr70646.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/ipa/pr70646.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-inline-analysis.c
branches/gcc-6-branch/gcc/ipa-inline.h
branches/gcc-6-branch/gcc/lto-streamer.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71201] PowerPC XXPERM instruction fails on ISA 3.0 system.

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #1 from acsawdey at gcc dot gnu.org ---
The symptom I observed was that a large number of xxlor were generated moving
stuff back and forth between register sets. I didn't quite figure out where the
problem was but the generated code also failed when run on the power9
simulator.

[Bug tree-optimization/69068] [6/7 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
Between 20160513 and 20160519, a new testsuite failure occured on Solaris/SPARC
(32- and 64-bit):

FAIL: gfortran.dg/graphite/pr68279.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr68279.f90   -O  (test for excess errors)

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/graphite/pr68279.f90:8:0:
internal compiler error: in bb_contains_loop_phi_nodes, at
graphite-isl-ast-to-gimple.c:1078
0xf176f7 bb_contains_loop_phi_nodes
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:1078
0xf1ed23
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec<tree_node*, va_heap, vl_ptr>)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:2730
0xf1f41f
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:936
0xf1fafb translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:965
0xf2066f graphite_regenerate_ast_isl(scop*)
/vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:3186
0xf16f03 graphite_transform_loops()
/vol/gcc/src/hg/trunk/local/gcc/graphite.c:329
0xf174cb graphite_transforms
/vol/gcc/src/hg/trunk/local/gcc/graphite.c:356
0xf174cb execute
/vol/gcc/src/hg/trunk/local/gcc/graphite.c:433

This is a regression from gcc-6 and seems to be the same issue.

  Rainer

[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function

[jamborm at gcc dot gnu.org]

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

--- Comment #35 from Martin Jambor  ---
Author: jamborm
Date: Thu May 19 15:00:12 2016
New Revision: 236463

URL: https://gcc.gnu.org/viewcvs?rev=236463=gcc=rev
Log:
Respect --param ipa-max-agg-items=0

2016-05-19  Martin Jambor  

PR ipa/70646
* ipa-prop.c (determine_locally_known_aggregate_parts): Bail out early
if parameter PARAM_IPA_MAX_AGG_ITEMS is zero.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-prop.c

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
The original issue goes away with -fno-declone-ctor-dtor.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "" 1

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #11 from Rainer Orth  ---
Between 20160513 and 20160519, the following failures started to appear
on sparc*-*-solaris2.*, both 32- and 64-bit:

FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times optimized "" 1
FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times optimized "" 1
FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times optimized "" 1

This is a regression from gcc-6.

  Rainer

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The same problem exists for std::atomic

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
No, I'm not aware of one.

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

[mar...@mpa-garching.mpg.de]

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

--- Comment #2 from Martin Reinecke  ---
I'm not sure why, but on a different machine I get a more detailed error
output, which might help locating the problem:

martin@noemi-laptop ~/Downloads $ g++ -v -O3 -c testcase.ii 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/codes/gccgit/configure --disable-bootstrap
--disable-multilib --prefix=/home/martin/codes/utrunk
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/martin/codes/utrunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed testcase.ii -quiet -dumpbase testcase.ii -mtune=generic
-march=x86-64 -auxbase testcase -O3 -version -o /tmp/cchF6iTX.s
GNU C++14 (GCC) version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.0.0 20160517 (experimental) [trunk revision
28adcc2:7f958dd:77d095c0eb3dcdf4ceca108d745301e8b29fefde] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5994b8b14bc318f7362472a1db0f260c
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc: In function ‘void
{anonymous}::prepPolyHelper(const std::vector&, const
std::vector&, std::vector&, bool)’:
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc:275:6: internal compiler
error: Segmentation fault
0xb1972f crash_signal
/home/martin/codes/gccgit/gcc/toplev.c:333
0xc18091 find_uses_to_rename_use
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:379
0xc18311 find_uses_to_rename_use
/home/martin/codes/gccgit/gcc/gimple-expr.h:109
0xc18311 find_uses_to_rename_bb
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:451
0xc1a1d0 find_uses_to_rename
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:479
0xc1a1d0 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/home/martin/codes/gccgit/gcc/tree-ssa-loop-manip.c:642
0xb8b74e execute
/home/martin/codes/gccgit/gcc/tree-loop-distribution.c:1830
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71200] [7 regression] ICE (segfault) with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce with
$ ./cc1plus -quiet testcase.ii -O3

[Bug target/71201] PowerPC XXPERM instruction fails on ISA 3.0 system.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-19
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/71201] New: PowerPC XXPERM instruction fails on ISA 3.0 system.

[meissner at gcc dot gnu.org]

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

Bug ID: 71201
   Summary: PowerPC XXPERM instruction fails on ISA 3.0 system.
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

GCC 6.1 added support for the XXPERM instruction for the PowerPC ISA 3.0.  The
XXPERM instruction is essentially a 4 operand instruction, with only 3 operands
in the instruction (the target register overlaps with the first input
register).  The Power9 hardware has fusion support where if the instruction
that precedes the XXPERM is a XXLOR move instruction to set the first input
argument, it is fused with the XXPERM.  I added code to support this fusion.

Unfortunately, in running the testsuite on the power9 simulator, we discovered
that the test gcc.c-torture/execute/pr56866.c would fail because the fusion
alternatives confused the register allocator and/or the passes after the
register allocator.

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Yup, they both use the do_copy_file function to do the work.

I'll see what I can do about tweaking the configure test next week.

[Bug libstdc++/70975] experimental/filesystem/operations/copy.cc FAILs on Solaris 12

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
The new experimental/filesystem/operations/copy_file.cc test suffers from the
same problem.

  Rainer

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c++ |target

--- Comment #2 from Marek Polacek  ---
Must be target-specific.

[Bug c++/71200] New: [7 regression] ICE (segfault) with -O3

[mar...@mpa-garching.mpg.de]

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

Bug ID: 71200
   Summary: [7 regression] ICE (segfault) with -O3
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 38528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38528=edit
test case

Current trunk crashes with a segmentation fault when compiling the attached
test case:

/afs/mpa/data/martin/lsnew/build.linux_gcc/Healpix_cxx>g++ -v -O3 -c
testcase.ii 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap
--prefix=/afs/mpa/home/martin/utrunk --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /afs/mpa/home/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed testcase.ii -quiet -dumpbase testcase.ii -mtune=generic
-march=x86-64 -auxbase testcase -O3 -version -o /tmp/ccSEE7Bb.s
GNU C++14 (GCC) version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.0.0 20160518 (experimental) [trunk revision
918cd90:e1d3be4:ab297b31366aae41396b333bbe2d7bc9a408ba13] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 658ce67c6356d3ab5653424abae932e8
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc: In function 'void
{anonymous}::prepPolyHelper(const std::vector&, const
std::vector&, std::vector&, bool)':
/afs/mpa/data/martin/lsnew/Healpix_cxx/moc_query.cc:275:6: internal compiler
error: Segmentation fault
 void prepPolyHelper (const vector , const vector ,
  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

With -O2 the code is comiled without complaint.
Also the head of the current 6.1 branch can compile the code with -O3.

I'm sorry, but I currently don't have the time to produce a minimal test case.

[Bug c++/71164] tree check fail at cp/pt.c:12961

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

--- Comment #6 from Ray Strode  ---
i do indeed seem to have ccache installed, thanks.

[Bug c/71199] Support overloadable attribute in GNU C front-end

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
How does _Generic interact with C++ if one includes the same header file in
either language?

[Bug c/71199] Support overloadable attribute in GNU C front-end

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
_Generic requires manual mangling.  It might be sufficient.

Compatibility with Clang in this useful area also would be good.

[Bug bootstrap/71198] [7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #1 from Richard Biener  ---
PR71148?

[Bug c/71199] Support overloadable attribute in GNU C front-end

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Doesn't C have generics for this now?

[Bug c/71199] New: Support overloadable attribute in GNU C front-end

[dje at gcc dot gnu.org]

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

Bug ID: 71199
   Summary: Support overloadable attribute in GNU C front-end
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Support C++ function overloading in C using the overloadable attribute.  The
appropriate function is invoked based on the function parameters.  This feature
is defined in the Clang documentation and implemented in Clang.

http://clang.llvm.org/docs/AttributeReference.html#overloadable

The functionality for GNU C is helpful to implement overloaded intrinsic /
built-in functions, such as Altivec vec_add, as inlined functions.

[Bug c/71199] Support overloadable attribute in GNU C front-end

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 Ever confirmed|0   |1

[Bug middle-end/71177] Spurious -Waggressive-loop-optimizations warning

[tavianator at gmail dot com]

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

--- Comment #4 from Tavian Barnes  ---
> I remember seeing a similar bugreport.

PR57199 is very similar, pretty much an exact dupe actually.

[Bug target/71056] [6/7 Regression] __builtin_bswap32 NEON instruction error with -O3

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May 19 13:43:58 2016
New Revision: 236459

URL: https://gcc.gnu.org/viewcvs?rev=236459=gcc=rev
Log:
[ARM] PR target/71056: Don't use vectorized builtins when NEON is not available

PR target/71056
* config/arm/arm-builtins.c (arm_builtin_vectorized_function): Return
NULL_TREE early if NEON is not available.  Remove now redundant check
in ARM_CHECK_BUILTIN_MODE.

* gcc.target/arm/pr71056.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr71056.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/71198] New: [7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

Bug ID: 71198
   Summary: [7 Regression] LTO profiledbootstrap failure
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, as of r236364, LTO profiledbootstrap never finishes:

 2582 intel64+  20   0  321800 122844   1244 R 100.0  2.0 569:45.60 lto1-ltrans 
 8829 intel64+  20   0  305380 164368  32228 R 100.0  2.7  60:04.33 lto1-ltrans 
29027 intel64+  20   0  305116  0  0 R 100.0  0.0   1069:12 lto1-ltrans 

x00921b8c in et_recomp_min (occ=0x3fcbe38)
at ../../src-trunk/gcc/et-forest.c:120
120   || (occ->next
  File "/usr/share/gdb/auto-load/usr/lib64/libisl.so.13.1.0-gdb.py", line 67
print "No isl printer for this type"
   ^
SyntaxError: Missing parentheses in call to 'print'
  File "/usr/share/gdb/auto-load/usr/lib64/libisl.so.13.1.0-gdb.py", line 67
print "No isl printer for this type"
   ^
SyntaxError: Missing parentheses in call to 'print'
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.22-16.0.fc23.x86_64 gmp-6.0.0-12.0.fc23.x86_64 isl-0.14-4.0.fc23.x86_64
libmpc-1.0.2-4.fc23.x86_64 mpfr-3.1.3-2.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
(gdb) bt
#0  0x00921b8c in et_recomp_min (occ=0x3fcbe38)
at ../../src-trunk/gcc/et-forest.c:120
#1  et_splay (occ=occ@entry=0x3fcbe38) at ../../src-trunk/gcc/et-forest.c:427
#2  0x009229b2 in et_split (t=t@entry=0x4068a68)
at ../../src-trunk/gcc/et-forest.c:580
#3  0x00922d7d in et_free_tree (t=0x4068a68)
at ../../src-trunk/gcc/et-forest.c:487
#4  0x0086644d in delete_from_dominance_info (
dir=dir@entry=CDI_DOMINATORS, bb=bb@entry=0x7fffe9bcdc98)
at ../../src-trunk/gcc/dominance.c:1418
#5  0x007a9105 in delete_basic_block (bb=bb@entry=0x7fffe9bcdc98)
at ../../src-trunk/gcc/cfghooks.c:613
#6  0x01988e74 in try_optimize_cfg (mode=96)
at ../../src-trunk/gcc/cfgcleanup.c:2731
#7  cleanup_cfg (mode=96, mode@entry=64)
at ../../src-trunk/gcc/cfgcleanup.c:3151
#8  0x019da45c in rest_of_handle_cse2 ()
at ../../src-trunk/gcc/cse.c:7637
#9  (anonymous namespace)::pass_cse2::execute (this=)
at ../../src-trunk/gcc/cse.c:7679
#10 0x00d67427 in execute_one_pass (pass=pass@entry=0x35b83b0)
at ../../src-trunk/gcc/passes.c:2344
#11 0x00d68407 in execute_pass_list_1 (pass=0x35b83b0)
---Type  to continue, or q  to quit---
   k/gcc/passes.c:2428
#12 0x00d683ce in execute_pass_list_1 (pass=0x35b7ab0, 
pass@entry=0x35b4570) at ../../src-trunk/gcc/passes.c:2429
#13 0x00d6849e in execute_pass_list (fn=0x7fffe9937e70, pass=0x35b4570)
at ../../src-trunk/gcc/passes.c:2439
#14 0x007ff5b4 in cgraph_node::expand (this=this@entry=0x7fffef9fd000)
at ../../src-trunk/gcc/cgraphunit.c:1983
#15 0x0080245f in expand_all_functions ()
at ../../src-trunk/gcc/cgraphunit.c:2119
#16 symbol_table::compile (this=0x7fffefbff0a8)
at ../../src-trunk/gcc/cgraphunit.c:2475
#17 0x006ebede in lto_main () at ../../src-trunk/gcc/lto/lto.c:3328
#18 0x00ed8bab in compile_file () at ../../src-trunk/gcc/toplev.c:463
#19 0x006a10f1 in do_compile () at ../../src-trunk/gcc/toplev.c:1987
#20 toplev::main (this=this@entry=0x7fffb5d0, argc=, 
argc@entry=33, argv=, argv@entry=0x7fffb6d8)
at ../../src-trunk/gcc/toplev.c:2095
#21 0x006a452f in main (argc=33, argv=0x7fffb6d8)
at ../../src-trunk/gcc/main.c:39
(gdb) 

It happened between r236358 and r236364.

[Bug c/71157] -Wnull-dereference false alarm in wrong function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Interesting that with -fno-inline I see

q.i: In function ‘Ruby_functions’:
q.i:7840:12: warning: potential null pointer dereference [-Wnull-dereference]
if (*cp != '#')
^~~

[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[jrtc27 at jrtc27 dot com]

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

--- Comment #4 from James Clarke  ---
Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01487.html

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
It can't be changed in those manuals, ever, both 6.1 and 5.3 releases have
already been released, their documentation, including online docs, is what has
been released at that point.

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

--- Comment #20 from shatz at dsit dot co.il ---
(In reply to Marek Polacek from comment #19)
> Markus recently committed a patch (r235580) that points out that this
> attribute should only be used for debugging.

3 weeks after the patch I see no changes in official gcc-6.1.0 and gcc-5.3.0
manuals. Was it rejected by higher authority or the process is just slow?

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Created attachment 38527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38527=edit
Draft patch for the PR

This regtests OK on 7.0.0.

I want to check if there is a more elegant way of fixing the problem before I
submit and, of course, there is the testcase to write!

Cheers

Paul