[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[chefmax at gcc dot gnu.org]

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

--- Comment #32 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Fri Feb  3 07:17:38 2017
New Revision: 245144

URL: https://gcc.gnu.org/viewcvs?rev=245144=gcc=rev
Log:
PR lto/79061
* asan.c (asan_add_global): Force has_dynamic_init to zero in LTO mode.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/asan.c

[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
The data dependence relations are dumped in the output of
-fdump-tree-graphite-all.
graphite-dependences.c contains the code for the data dependence computations.
Looking at the gimple code it seems like a trivial write after write
dependence.

Do we have a reduced testcase for this problem?

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[meissner at linux dot vnet.ibm.com]

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

--- Comment #7 from Michael Meissner  ---
On Fri, Feb 03, 2017 at 01:41:44AM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354
> 
> --- Comment #3 from Jakub Jelinek  ---
> Created attachment 40661
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40661=edit
> gcc7-pr79354.patch
> 
> Untested fix.

Yes, this looks right.

[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch submitted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00233.html

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
Regression tested powerpc64le-linux successfully.

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #5 from Alan Modra  ---
It looked good to me too, enough that I'm bootstrapping and regression testing.

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
That looks good to me.  Mike, to you too?

[Bug middle-end/79275] [7 Regression] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r245142.

[Bug middle-end/79275] [7 Regression] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Feb  3 02:18:59 2017
New Revision: 245142

URL: https://gcc.gnu.org/viewcvs?rev=245142=gcc=rev
Log:
PR middle-end/79275 -  -Wformat-overflow false positive exceeding INT_MAX in
glibc sysdeps/posix/tempname.c

gcc/testsuite/ChangeLog:

PR middle-end/79275
* gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: New test.
* gcc.dg/tree-ssa/pr79275.c: New test.

gcc/ChangeLog:

PR middle-end/79275
* gimple-ssa-sprintf.c (get_string_length): Set lower bound to zero.
(format_string): Tighten up the range of output for non-constant
strings and correct the expected range for wide non-constant strings.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79275.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Looking at tmp-mddump.md, the only other insn that emits the stxssp instruction
is movsf_hardfloat and that uses wb constraint for the input_operand and only
uses wu constraint for stxsspx, while movsi_from_sf uses wu constraint for both
stxssp and stxsspx.
Using wb instead of wu for movsi_from_sf constraint on the stxssp alternative
fixes the bug.

[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Variant patch: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00156.html

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Perhaps add also foo (); below foo (); to avoid any kind of IPA thinking
the memcpy is useless.

It is apparently the movsi_from_sf instruction that has this, added by Michael
in r244279.  TARGET_NO_SF_SUBREG can be enabled already for power8:
rs6000.h:#define TARGET_NO_SF_SUBREGTARGET_DIRECT_MOVE_64BIT
rs6000.h:#define TARGET_DIRECT_MOVE_64BIT   (TARGET_DIRECT_MOVE
\
rs6000.h-&& TARGET_P8_VECTOR   
\
rs6000.h-&& TARGET_POWERPC64   
\
rs6000.h-&& TARGET_UPPER_REGS_DI   
\
rs6000.h-&&
(rs6000_altivec_element_order != 2))
so if some alternatives of the insn are power9 insns, those should be either
disabled through constraints, or enabled attribute, or we need
to have multiple movsi_from_sf instructions depending on the ISA.
enabled attribute doesn't seem to be deployed in the rs6000 backend, the
alternative uses wu constraint which is also enabled
for power8.  So, perhaps we need a wu-like constraint that is only enabled for
power9?

[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug target/79343] [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[amodra at gmail dot com]

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

--- Comment #4 from Alan Modra  ---
Followup here:
https://github.com/xianyi/OpenBLAS/issues/1078

[Bug target/66144] vector element operator produces very bad code

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Created attachment 40660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40660=edit
Replacement proposed patch

[Bug rtl-optimization/79279] combine/simplify_set: wrong call to REG_CANNOT_CHANGE_MODE_P

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-02-03
 Resolution|WONTFIX |---
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
See https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00224.html for
some discussion.

[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-03
 CC||amodra at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug target/79354] New: [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux

[jakub at gcc dot gnu.org]

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

Bug ID: 79354
   Summary: [7 Regression] -mcpu=power8 -O2 generates power9
instruction on powerpc64le-linux
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int b, f, g;
float e;
unsigned long d;

__attribute__((noinline, noclone)) void
foo (int *a)
{
  for (g = 0; g < 32; g++)
if (f)
  {
e = d;
__builtin_memcpy (, , sizeof (float));
b = *a;
  }
}

int
main ()
{
  int h = 5;
  f = 1;
  asm volatile ("" : : : "memory");
  foo ();
  return 0;
}

compiled with -O2 -mcpu=power8 actually emits a power9 stxssp instruction.

[Bug target/79353] New: ICE in curr_insn_transform, at lra-constraints.c:3773

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 79353
   Summary: ICE in curr_insn_transform, at lra-constraints.c:3773
   Product: gcc
   Version: 7.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-7
rch=sparc64=7-20170129-1=1485857763=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: doko at gcc dot gnu.org, jemarch at gnu dot org, jrtc27 at 
jrtc27 dot com
  Target Milestone: ---
Target: sparc*-*-*

Trying to build gcc-7 (snapshot 20170128) on Debian sparc64 fails with:

libtool: compile:  /<>/build/./gcc/xgcc
-B/<>/build/./gcc/ -B/usr/sparc64-linux-gnu/bin/
-B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem
/usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include
-m32 -DHAVE_CONFIG_H -I. -I../../../../src/libgo -I
../../../../src/libgo/runtime -I../../../../src/libgo/../libffi/include
-I../libffi/include -pthread -fexceptions -fnon-call-exceptions
-fplan9-extensions -fno-stack-protector -Wall -Wextra -Wwrite-strings
-Wcast-qual -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../../src/libgo/../libgcc -I ../../../../src/libgo/../libbacktrace -I
../../../gcc/include -g -O2 -m32 -MT thread-linux.lo -MD -MP -MF
.deps/thread-linux.Tpo -c ../../../../src/libgo/runtime/thread-linux.c -o
thread-linux.o >/dev/null 2>&1
/bin/bash ./libtool --tag=CC   --mode=compile /<>/build/./gcc/xgcc
-B/<>/build/./gcc/ -B/usr/sparc64-linux-gnu/bin/
-B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem
/usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include 
-m32 -DHAVE_CONFIG_H -I. -I../../../../src/libgo  -I
../../../../src/libgo/runtime -I../../../../src/libgo/../libffi/include
-I../libffi/include -pthread  -fexceptions -fnon-call-exceptions
-fplan9-extensions -fno-stack-protector  -Wall -Wextra -Wwrite-strings
-Wcast-qual-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../../src/libgo/../libgcc -I ../../../../src/libgo/../libbacktrace -I
../../../gcc/include -g -O2  -m32 -c -o syscall/errno.lo
../../../../src/libgo/go/syscall/errno.c
/bin/bash ./libtool --tag=CC   --mode=compile /<>/build/./gcc/xgcc
-B/<>/build/./gcc/ -B/usr/sparc64-linux-gnu/bin/
-B/usr/sparc64-linux-gnu/lib/ -isystem /usr/sparc64-linux-gnu/include -isystem
/usr/sparc64-linux-gnu/sys-include -isystem /<>/build/sys-include 
-m32 -DHAVE_CONFIG_H -I. -I../../../../src/libgo  -I
../../../../src/libgo/runtime -I../../../../src/libgo/../libffi/include
-I../libffi/include -pthread  -fexceptions -fnon-call-exceptions
-fplan9-extensions -fno-stack-protector  -Wall -Wextra -Wwrite-strings
-Wcast-qual-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../../src/libgo/../libgcc -I ../../../../src/libgo/../libbacktrace -I
../../../gcc/include -g -O2  -m32 -c -o syscall/signame.lo
../../../../src/libgo/go/syscall/signame.c
../../../../src/libgo/runtime/parfor.c: In function 'runtime_parfordo':
../../../../src/libgo/runtime/parfor.c:194:1: error: unable to generate reloads
for:
 }
 ^
(insn 260 259 261 29 (set (mem/v:DI (reg/v/f:SI 157 [ me ]) [-1  S8 A64])
(unspec:DI [
(mem/c:DI (plus:SI (reg/f:SI 101 %sfp)
(const_int -8 [0xfff8])) [14 %sfp+-8 S8
A64])
] UNSPEC_ATOMIC)) "../../../../src/libgo/runtime/parfor.c":157 796
{atomic_storedi_1}
 (nil))
../../../../src/libgo/runtime/parfor.c:194:1: internal compiler error: in
curr_insn_transform, at lra-constraints.c:3773

Currently don't have the preprocessed as this was a build on a buildd. But I
can do a manual build easily and provide the preprocessed source if necessary.

[Bug target/69992] test case gcc.dg/sms-4.c fails

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Digging deeper, if i is not 64-bit, we don't choose it as one of the IVs, and
the loop iteration test gets converted based on ap instead. Then the math in
iv_number_of_iterations decides that it might be an infinite loop somehow. As a
result, doloop conversion isn't done, then later doloop_condition_get fails to
find the loop count register, and SMS is not done.

Loop 1 is simple:
  simple exit 5 -> 6
  infinite if: (expr_list:REG_DEP_TRUE (ne:SI (and:DI (minus:DI (plus:DI
(ashift:DI (reg:DI 211)
(const_int 2 [0x2]))
(reg/v/f:DI 205 [ ap ]))
(reg:DI 193 [ ivtmp.20 ]))
(const_int 3 [0x3]))
(const_int 0 [0]))
(nil))
  number of iterations: (lshiftrt:DI (plus:DI (minus:DI (reg:DI 203 [ _58 ])
(reg:DI 193 [ ivtmp.20 ]))
(const_int -4 [0xfffc]))
(const_int 2 [0x2]))
  upper bound: 4294967294
  likely upper bound: 4294967294
  realistic bound: -1
Doloop: Possible infinite iteration case.
Doloop: The loop is not suitable.

[Bug testsuite/63256] [5/6/7 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from acsawdey at gcc dot gnu.org ---
committed as 245138.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #30 from David Edelsohn  ---
.../src/src/configure --disable-werror --with-gmp=/opt/cfarm
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext

By the way, it's a lot faster if the src and build directories are in /scratch.
 It's a ramdisk for transient, temporary files, so don't leave things there
permanently.

[Bug tree-optimization/79352] [6 Regression] -fprintf-return-value doesn't handle flexible-like array members properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-02
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This causes miscompilation of the Prima package.

[Bug tree-optimization/79352] New: [6 Regression] -fprintf-return-value doesn't handle flexible-like array members properly

[jakub at gcc dot gnu.org]

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

Bug ID: 79352
   Summary: [6 Regression] -fprintf-return-value doesn't handle
flexible-like array members properly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Most of the optimization passes handle flexible array members and trailing
arrays in structures that could be poor man's flexible array members
conservatively, but apparently gimple-ssa-sprintf.c does not.

char buf[64];
struct S { int i; char j[1]; };

__attribute__((noinline, noclone)) void
foo (struct S *p)
{
  int a = __builtin_sprintf (buf, "a%sf", p->j);
  if (a != 6)
__builtin_abort ();
}

int
main ()
{
  struct S *s = __builtin_malloc (sizeof (struct S) + 4);
  if (s)
{
  s->i = 5;
  __builtin_strcpy (s->j, "bcde");
  foo (s);
  __builtin_free (s);
}
  return 0;
}

ICEs because of that, the pass thinks that p->j must be "", while in foo it can
be arbitrary length.  If you try to print __builtin_object_size (s->j, {0,1})
before the call to foo, it prints 8 (that is sizeof (struct S) + 4 - offsetof
(struct S, s->j[0])), if you try to print __builtin_object_size (p->j, {0,1})
inside of foo, it will correctly print -1, don't know length.

[Bug tree-optimization/79351] New: Invalid tree PRE optimization around compound literal

[wellons at nullprogram dot com]

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

Bug ID: 79351
   Summary: Invalid tree PRE optimization around compound literal
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wellons at nullprogram dot com
  Target Milestone: ---

Created attachment 40659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40659=edit
Demonstrates an invalid -ftree-pre optimization

GCC's -ftree-pre optimization incorrectly optimizes compound literals. I have
verified this bug in 6.3.0 (x86-64), 5.4.0 (AArch64), and 4.9.2 (x86-64).

Attached is a C program demonstrating the bug. When compiled with "-O1
-ftree-pre" the resulting program is miscompiled and produces incorrect output.
This only happens when the compound literal is used in the assignment
(-DENABLE_GCC_BUG=1, line 24), not under an identical memset() (line 26).

The example's header explains how to reproduce the bug for yourself:

$ gcc -std=c99 -O1 -ftree-pre -DENABLE_GCC_BUG=0 -o valid  example.c
$ gcc -std=c99 -O1 -ftree-pre -DENABLE_GCC_BUG=1 -o broken example.c
$ echo bookkeeper | ./valid XXYYZZ
bookkeeper
$ echo bookkeeper | ./broken XXYYZZ
$

The bug manifest at line 29, where the increment operation is "optimized" away
into a constant 1 assignment. Here's the relevant x86-64 assembly for line 29
in the memset() version, which behaves correctly:

movsx   rax, DWORD PTR states[rip]
lea edx, [rax+1]
mov DWORD PTR states[rip], edx
movsx   rdx, BYTE PTR [r9+rax]

The 32-bit signed integer is read into rax, incremented into edx, and written
back. The original integer, still in rax, is also used in the array index off
r9.

Here's the broken version of this line, when the compound literal was used:

mov DWORD PTR states[rip], 1
movsx   rdx, BYTE PTR [r9]

The integer on the struct is incorrectly assumed to be zero and is not read,
instead it's clobbered by a constant 1. Also because of the zero assumption,
it's not used as an array index off r9.

Here's the example under the Compiler Explorer in case that's helpful:
https://godbolt.org/g/ILmwSh

[Bug c++/79350] New: "explicit" deduction guides don't work

[mike at spertus dot com]

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

Bug ID: 79350
   Summary: "explicit" deduction guides don't work
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at spertus dot com
  Target Milestone: ---

When I compile the following code with gcc-7-20170122,

template struct S {};
template
explicit S(T) -> S;

I get the error 
error: decl-specifier in declaration of deduction guide
 explicit S(T) -> S;
 ^~~~
test.cpp:3:1: error: ‘explicit’ outside class declaration

This is currently a bug because the current standard draft N4618 allows an
optional "explicit" in the deduction-guide grammar production

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
Before that the "undesignated symbols" were around already, but the test PASSed
anyway.

[Bug middle-end/79349] New: unused std::string is not optimized away in presense of a call

[hiraditya at msn dot com]

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

Bug ID: 79349
   Summary: unused std::string is not optimized away in presense
of a call
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

g++ version (GCC) 7.0.0 20170118 (experimental)

$ cat t.cpp

#include
void foo();

int main() {
  std::string s("abc");
  foo ();
  return 0;
}

$ install/bin/g++ -O3 t.cpp -S -o t.s
$ cat t.s

main:
.LFB995:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDA995
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
subq$32, %rsp
.cfi_def_cfa_offset 48
leaq16(%rsp), %rax
movb$99, 18(%rsp)
movq$3, 8(%rsp)
movb$0, 19(%rsp)
movq%rax, (%rsp)
movl$25185, %eax
movw%ax, 16(%rsp)
.LEHB0:
call_Z3foov
.LEHE0:
movq(%rsp), %rdi
leaq16(%rsp), %rax
cmpq%rax, %rdi
je  .L6
call_ZdlPv
.L6:
addq$32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 16
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.L5:
.cfi_restore_state
movq(%rsp), %rdi
leaq16(%rsp), %rdx
movq%rax, %rbx
cmpq%rdx, %rdi
je  .L4
call_ZdlPv
.L4:
movq%rbx, %rdi
.LEHB1:
call_Unwind_Resume
.LEHE1:
.cfi_endproc
.LFE995:
.globl  __gxx_personality_v0
.section.gcc_except_table,"a",@progbits


While clang++ optimizes it away: clang version 5.0.0 (llvm-project SHA:
28b7c19c2379e17b26571260933467b9f98b449c)


$ ./bin/clang++ -O3 t.cpp -S -o t.s -stdlib=libc++
$ cat t.s

main:   # @main
.cfi_startproc
# BB#0: # %entry
pushq   %rax
.Lcfi0:
.cfi_def_cfa_offset 16
callq   _Z3foov
xorl%eax, %eax
popq%rcx
retq
.Lfunc_end0:
.size   main, .Lfunc_end0-main
.cfi_endproc


.ident  "clang version 5.0.0 "
.section".note.GNU-stack","",@progbits

[Bug target/66144] vector element operator produces very bad code

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #40657|0   |1
is obsolete||

--- Comment #5 from Michael Meissner  ---
Created attachment 40658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40658=edit
Potential patch to do the optimization

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
The test failure has started with r238647:

Move allocator in std::string and RB tree move constructors

PR libstdc++/71964
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_Alloc_hider(pointer, _Alloc&&)): Add constructor.
* include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&)): Move allocator.
* testsuite/21_strings/basic_string/allocator/71964.cc: New test.
* testsuite/23_containers/set/allocator/71964.cc: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238647
138bc75d-0d04-0410-96

[Bug target/66144] vector element operator produces very bad code

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Created attachment 40657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40657=edit
Potential patch to do the optimization

[Bug target/56828] [PowerPC] Type cast of sNaN value

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kelvin at gcc dot gnu.org
 Resolution|--- |INVALID
   Assignee|unassigned at gcc dot gnu.org  |kelvin at gcc dot 
gnu.org

--- Comment #2 from kelvin at gcc dot gnu.org ---
The default IBM extended precision long double type on Power does not conform
to the IEEE specification, so there is no expectation that this type coercions
would comply with the IEEE 754-2008 standard.

[Bug tree-optimization/79334] Segfault on tree loop hoisting

[amodra at gmail dot com]

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

--- Comment #4 from Alan Modra  ---
When you have the tree optimization bug fixed, this becomes an rtl optimization
bug since rtl pre does the same as tree pre..

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

--- Comment #29 from Aldy Hernandez  ---
> Are there any other particular tricks for bootstrapping GCC circa 219827 on
> this AIX?  Are there any other configury or otherwise flags?

FYI, I also tried --disable-nls as per comment 21, but I get a different
problem while linking stage2.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #28 from Aldy Hernandez  ---
I am at commit 53ec6b3f003abd3528f988fa32a07cc084128563:

Author: pault 
Date:   Sun Jan 18 22:01:29 2015 +

2015-01-18  Andre Vehreschild  
Janus Weil 

...

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219827
138bc75d-0d04-0410-96
1f-82ee72b054a4

And have applied the patch in
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00421.html.

I am building on gcc119, which is AIX power8-aix 2 7 (AIX 7.2 I presume).

export CXX="g++ -std=gnu++98"
/source/gcc/configure \
--with-gmp=/opt/cfarm --with-cloog=no --with-ppl=no
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch --enable-__cxa_atexit
\
--enable-languages=c,c++ 
make -j16

I am building with -std=gnu++98, as that particular point in the branch has an
issue being built with gcc 6.1.0 which is what is on gcc119 (see bz#69959).

I am running into:

/home/aldyh/src/gcc/libstdc++-v3/configure[20782]: syntax error at line 46079 :
`;' unexpected
/home/aldyh/src/gcc/libstdc++-v3/configure[20782]: syntax error at line 19 :
`)' unexpected
Makefile:12556: recipe for target 'configure-stage1-target-libstdc++-v3' failed
make[2]: *** [configure-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/home/aldyh/bld/bisect'
Makefile:17452: recipe for target 'stage1-bubble' failed

Are there any other particular tricks for bootstrapping GCC circa 219827 on
this AIX?  Are there any other configury or otherwise flags?

[Bug target/79343] [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #3 from Alan Modra  ---
powerpc64le is still PIC by default.  If you see non-PIC in executables it is
likely due to ld editing code.

The blas source looks to be adding r2 (and r0) to the clobbers completely
unnecessarily.  I suspect what the author of that code was trying to do was say
that i and n are changed by the asm, which is done by making them output args
as well as input.  The memory clobber could be removed too, if *x1 was made an
output.  Oh, and the asm misses clobbers for all the vector regs used..

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
(Also happend without --enable-shared.)

[Bug middle-end/32003] Undocumented -fdump-tree options

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed in r245136.

[Bug middle-end/32003] Undocumented -fdump-tree options

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu Feb  2 20:57:37 2017
New Revision: 245136

URL: https://gcc.gnu.org/viewcvs?rev=245136=gcc=rev
Log:
PR middle-end/32003 - Undocumented -fdump-tree options

gcc/ChangeLog:
   * doc/invoke.texi (-fdump-rtl-): Remove pass-specific options from
   index.
   (-fdump-tree-@var): Add to index and document how to come up
   with pass-specific option and dump file names.
   (-fdump-passes): Clarify where to look for output.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug fortran/65542] [5/6/7 Regression] SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Finally reduced this to something like 260 lines. Problem is the allocate
source construct, i.e. copying of allocatable derived type components. 


module iso_varying_string
  implicit none

  integer, parameter, private :: GET_BUFFER_LEN = 1  

  type, public :: varying_string
 private
 character(LEN=1), dimension(:), allocatable :: chars
  end type varying_string

  interface assignment(=)
 module procedure op_assign_CH_VS
 module procedure op_assign_VS_CH
  end interface assignment(=)

  interface char
 module procedure char_auto
 module procedure char_fixed
  end interface char

  interface len
 module procedure len_
  end interface len

  interface var_str
 module procedure var_str_
  end interface var_str

  public :: assignment(=)
  public :: char
  public :: len
  public :: var_str

  private :: op_assign_CH_VS
  private :: op_assign_VS_CH
  private :: char_auto
  private :: char_fixed
  private :: len_
  private :: var_str_

contains

  elemental function len_ (string) result (length)
type(varying_string), intent(in) :: string
integer  :: length
if(ALLOCATED(string%chars)) then
   length = SIZE(string%chars)
else
   length = 0
endif
  end function len_

  elemental subroutine op_assign_CH_VS (var, exp)
character(LEN=*), intent(out):: var
type(varying_string), intent(in) :: exp
var = char(exp)
  end subroutine op_assign_CH_VS

  elemental subroutine op_assign_VS_CH (var, exp)
type(varying_string), intent(out) :: var
character(LEN=*), intent(in)  :: exp
var = var_str(exp)
  end subroutine op_assign_VS_CH

  pure function char_auto (string) result (char_string)
type(varying_string), intent(in) :: string
character(LEN=len(string))   :: char_string
integer  :: i_char
forall(i_char = 1:len(string))
   char_string(i_char:i_char) = string%chars(i_char)
end forall
  end function char_auto

  pure function char_fixed (string, length) result (char_string)
type(varying_string), intent(in) :: string
integer, intent(in)  :: length
character(LEN=length):: char_string
char_string = char(string)
return
  end function char_fixed


  elemental function var_str_ (char) result (string)
character(LEN=*), intent(in) :: char
type(varying_string) :: string
integer  :: length
integer  :: i_char
length = LEN(char)
ALLOCATE(string%chars(length))
forall(i_char = 1:length)
   string%chars(i_char) = char(i_char:i_char)
end forall
  end function var_str_

end module iso_varying_string

!

module models
  use iso_varying_string, string_t => varying_string

  implicit none
  private

  public :: field_data_t
  public :: model_data_t

  type :: field_data_t
 private
 type(string_t) :: longname
 integer :: pdg = 0
 type(string_t), dimension(:), allocatable :: name, anti
   contains
 procedure :: init => field_data_init
 procedure :: copy_from => field_data_copy_from
 procedure :: set => field_data_set
  end type field_data_t

  type :: field_data_p
 type(field_data_t), pointer :: p => null ()
  end type field_data_p

  type :: model_data_t
 private
 type(string_t) :: name
 type(field_data_t), dimension(:), allocatable :: field
   contains
 procedure :: get_field_ptr_by_index => model_data_get_field_ptr_index
  end type model_data_t

  public :: model_t

  type, extends (model_data_t) :: model_t
   contains
 generic :: init => model_init
 procedure, private :: model_init
 procedure :: read => model_read
  end type model_t

contains

  subroutine field_data_init (prt, longname, pdg)
class(field_data_t), intent(out) :: prt
type(string_t), intent(in) :: longname
integer, intent(in) :: pdg
prt%longname = longname
prt%pdg = pdg
  end subroutine field_data_init

  subroutine field_data_copy_from (prt, prt_src)
class(field_data_t), intent(inout) :: prt
class(field_data_t), intent(in) :: prt_src
integer :: i
print *, "##"
print *, "inside copy_from"
if (allocated (prt_src%name)) then
   print *, "foo"
   do i = 1, size (prt_src%name)
  print *, "name = ", char (prt_src%name(i))
   end do
   if (allocated (prt%name))  deallocate (prt%name)
   allocate (prt%name (size (prt_src%name)), source = prt_src%name)
   print *, "THESE SHOULD NOT BE EMPTY"
   do i = 1, size (prt_src%name)
  print *, "name = ", char (prt_src%name(i))
   end do   
end if
if (allocated (prt_src%anti)) then
   if (allocated (prt%anti))  deallocate (prt%anti)
   allocate (prt%anti (size (prt_src%anti)), source = prt_src%anti)
end if
  end subroutine 

[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors

[juergen.reuter at desy dot de]

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

--- Comment #4 from Jürgen Reuter  ---
Created attachment 40656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40656=edit
Much reduced problem case

[Bug fortran/65542] [5/6/7 Regression] SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
Patch looks straightforward:

Index: intrinsic.c
===
--- intrinsic.c (Revision 244747)
+++ intrinsic.c (Arbeitskopie)
@@ -4680,6 +4680,27 @@ gfc_intrinsic_func_interface (gfc_expr *expr, int
   return MATCH_ERROR;
 }

+  /* F95, 7.1.6.1: Only transformational functions REPEAT, RESHAPE,
+ SELECTED_INT_KIND, SELECTED_REAL_KIND, TRANSFER, and TRIM are allowed in
+ initialization expressions.  */
+
+  if (gfc_init_expr_flag && isym->transformational)
+{
+  gfc_isym_id id = isym->id;
+  if (id != GFC_ISYM_REPEAT && id != GFC_ISYM_RESHAPE
+ && id != GFC_ISYM_SI_KIND && id != GFC_ISYM_SR_KIND
+ && id != GFC_ISYM_TRANSFER && id != GFC_ISYM_TRIM
+ && !gfc_notify_std (GFC_STD_F2003, "Transformational function %qs "
+ "invalid as initialization expression is at %L",
+ name, >where))
+   {
+ if (!error_flag)
+   gfc_pop_suppress_errors ();
+
+ return MATCH_ERROR;
+   }
+}
+
   gfc_current_intrinsic_where = >where;

   /* Bypass the generic list for min, max and ISO_C_Binding's c_loc.  */

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[hubicka at gcc dot gnu.org]

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

--- Comment #24 from Jan Hubicka  ---
Author: hubicka
Date: Thu Feb  2 20:22:13 2017
New Revision: 245135

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

PR middle-end/77445
* gcc.dg/tree-ssa/pr77445-2.c: Update testcase to check that all
threading is done.
* tree-ssa-threadbackward.c (profitable_jump_thread_path): Dump
statistics of the analyzed path; allow threading for speed when
any of BBs along the path are optimized for speed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr77445-2.c
trunk/gcc/tree-ssa-threadbackward.c

[Bug c++/79300] Wrong diagnostics position

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00207.html

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
(In reply to Jonathan Wakely from comment #2)
> Why have these symbols appeared now? Is TLS enabled by default on this
> target now? Did something change regarding TLS?

Not that I know of.

> Are you using the default configuration?

The configuration we always use for testing, minus some languages.

  $ configure --with-arch=zEC12 --enable-languages=c,c++ --enable-bootstrap
--enable-multilib --disable-checking --enable-checking=none --enable-shared
--with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-indirect-function

(The --enable-shared is left over from an earlier experiment, but that should
not matter, or does it?)

[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This seems reasonable to me, but this area of the configury is not my forte.

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
See
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_porting.html#build_hacking.configure.version
but you don't want to do that to add new symbols to an old symbol version, that
would hide a bug.

Why have these symbols appeared now? Is TLS enabled by default on this target
now? Did something change regarding TLS? Are you using the default
configuration?

[Bug fortran/66089] [6/7 Regression] elemental dependency mishandling when derived types are involved

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #21 from Thomas Koenig  ---
Is there anything left to fix?

[Bug libstdc++/79348] abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #1 from Dominik Vogt  ---
How do you regenerate the baseline files for s390*?

[Bug libstdc++/79348] New: abi_check fails on s390x (2 undesignated symbols)

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79348
   Summary: abi_check fails  on s390x (2 undesignated symbols)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
  Target Milestone: ---

2 undesignated symbols  
0 
_ZSt11__once_call 
std::__once_call 
version status: compatible 
GLIBCXX_3.4.11 
type: tls 
type size: 8 
status: undesignated 

1 
_ZSt15__once_callable 
std::__once_callable 
version status: compatible 
GLIBCXX_3.4.11 
type: tls 
type size: 8 
status: undesignated 
...
 libstdc++-v3 check-abi Summary  

# of added symbols:  106 
# of missing symbols:0 
# of undesignated symbols:   2 
# of incompatible symbols:   78 

using: baseline_symbols.txt 
FAIL: libstdc++-abi/abi_check

[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038

[vogt at linux dot vnet.ibm.com]

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

--- Comment #10 from Dominik Vogt  ---
(In reply to Richard Biener from comment #7)
> Author: rguenth
> Date: Wed Nov 16 08:42:20 2016
> New Revision: 242470
> 
> URL: https://gcc.gnu.org/viewcvs?rev=242470=gcc=rev
> Log:
> 2016-11-16  Richard Biener  
> 
>   PR tree-optimization/78348
>   * tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMMOVE.
>   (generate_memcpy_builtin): Honor PKIND_MEMCPY on the partition.
>   (classify_partition): Set PKIND_MEMCPY if dependence analysis
>   revealed no dependency, PKIND_MEMMOVE otherwise.
> 
>   * gcc.dg/tree-ssa/ldist-24.c: New testcase.
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-24.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/tree-loop-distribution.c

The new test ldist-24.c fails on s390x:

PASS: gcc.dg/tree-ssa/ldist-24.c (test for excess errors) 
FAIL: gcc.dg/tree-ssa/ldist-24.c scan-tree-dump ldist "generated memcpy" 
FAIL: gcc.dg/tree-ssa/ldist-24.c scan-tree-dump ldist "generated memset zero"

(See dump file in previous comment.)

[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #9 from Dominik Vogt  ---
Created attachment 40655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40655=edit
s390x ldist output

[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

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

[hubicka at gcc dot gnu.org]

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

Bug ID: 79347
   Summary: [7 regression] vect_do_peeling is messing up profile
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Hi,
compiling
short *a;
int c;
n()
{
  for (int i = 0; i

[Bug c++/49974] missing warning for indirectly returning reference to local/temporary

[steven.spark at gmail dot com]

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

--- Comment #8 from Szikra  ---
(In reply to Marc Glisse from comment #7)
> We currently warn on all the examples involving X, with -O2. We don't for Y,
> we might if there was a caller and the dangling reference was used there...

Hi, I assume you mean like this:
#include 
using namespace std;
struct Y {
Y(int& i) : r(i) { }
int& r;
};

Y f() {
int i=1;
return Y(i);
}

int main() {
Y y1= f();
cout << y1.r << endl; ///  warning: 'i' is used uninitialized in this
function [-Wuninitialized]
}

/* compiled with gcc version 6.3.0 (x86_64-posix-seh-rev1, Built by MinGW-W64
project)
g++ -std=c++11 -O2 -g3 -Wall -Wextra -Wconversion -c -fmessage-length=0 -v -o
"src\\test3.o" "..\\src\\test3.cpp" 
*/

What about this?
struct Y2 {
Y2(const int& i) : r(i) { }
const int& r;
};

We might or might not get a warning even if the reference is used.

int main() {
Y2 y2(2);
cout << y2.r << endl; ///  warning: '' is used uninitialized in
this function [-Wuninitialized]
}

and 

Y2 g_y2(22);
int main() {
cout << g_y2.r << endl; /// no warning at all
}

Or what about this?
struct Z {
Z(int i) : r(i) { }
int& r;
};

Z g_z(33);
int main() {
cout << g_z.r << endl; /// no warning
Z z(3);
cout << z.r << endl; /// no warning
}

[Bug other/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
For example, use-after-scope-goto-1.c built with -O0 -m31 crashed during exit:

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) up
#1  0x77a65c0a in __interceptor___tls_get_addr_internal (arg=0x77973060)
at
/home/vogt/src/t/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4557
4557  uptr res = REAL(__tls_get_addr_internal)(arg);
(gdb) p arg
$1 = (void *) 0x77973060
(gdb) up
#2  0x77824076 in __call_tls_dtors () from /lib/libc.so.6
(gdb) 
#3  0x778239f6 in __run_exit_handlers () from /lib/libc.so.6
(gdb) 
#4  0x77823ae8 in exit () from /lib/libc.so.6
(gdb) 
#5  0x7780b6c0 in __libc_start_main () from /lib/libc.so.6
(gdb) 
#6  0x00400696 in _start ()
(gdb) 
Initial frame selected; you cannot go up.
(gdb) bt
#0  0x in ?? ()
#1  0x77a65c0a in __interceptor___tls_get_addr_internal (arg=0x77973060)
at
/home/vogt/src/t/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4557
#2  0x77824076 in __call_tls_dtors () from /lib/libc.so.6
#3  0x778239f6 in __run_exit_handlers () from /lib/libc.so.6
#4  0x77823ae8 in exit () from /lib/libc.so.6
#5  0x7780b6c0 in __libc_start_main () from /lib/libc.so.6
#6  0x00400696 in _start ()

[Bug middle-end/79275] [7 Regression] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|--- |7.0
Summary|-Wformat-overflow false |[7 Regression]
   |positive exceeding INT_MAX  |-Wformat-overflow false
   |in glibc|positive exceeding INT_MAX
   |sysdeps/posix/tempname.c|in glibc
   ||sysdeps/posix/tempname.c

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
(In reply to __vic from comment #11)
> condition_variable.o
> cow-stdexcept.o
> cow-string-inst.o
> eh_throw.o
> functexcept.o
> functional.o
> futex.o
> future.o
> ios_failure.o
> regex.o
> stdexcept.o
> string-inst.o
> system_error.o

These dependencies are because src/c++11/functexcept.o requires the destructors
and vtables of all exception types. By moving __throw_bad_function_call and
__throw_regex_error and __throw_future_error into separate files we can get the
testcase smaller still:

233440 gcc7-splitexcept.so

And splitting up src/c++11/system_error.o gives:

225160 gcc7-splitexcept2.so

[Bug middle-end/78142] Commit r241590 is more registers to be used for on gcc.target/aarch64/vector_initialization_nostack.c

[tnfchris at gcc dot gnu.org]

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

--- Comment #6 from tnfchris at gcc dot gnu.org ---
Author: tnfchris
Date: Thu Feb  2 16:35:15 2017
New Revision: 245132

URL: https://gcc.gnu.org/viewcvs?rev=245132=gcc=rev
Log:
PR middle-end/78142
* gcc.target/aarch64/vector_initialization_nostack.c
(f12): Use one vector

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/vector_initialization_nostack.c

[Bug other/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
No, that does not help.

Meanwhile the Tests on s390x have completed (r244119), and there are > 100 Asan
related FAILs with -m31 as well as -m64.  Not anywhere near your or Andreas'
test results.  Many FAILs similar to this one:

  SUMMARY: AddressSanitizer: SEGV ()  
  ==24206==ABORTING 
  FAIL: gcc.dg/asan/use-after-scope-goto-1.c   -O0  execution test 
^^

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[juergen.reuter at desy dot de]

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

--- Comment #24 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #23)
> I filed another PR: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79334

sorry, this was a typo, the correct one is:

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

[Bug middle-end/78142] Commit r241590 is more registers to be used for on gcc.target/aarch64/vector_initialization_nostack.c

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from tnfchris at gcc dot gnu.org ---
Fixed in r245132

[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-02
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Really started with r242875.

[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok, fails with:

g++ -floop-nest-optimize -Ofast -w tramp3d-v4.cpp -fdump-tree-graphite-details
-$ fdbg-cnt=graphite_scop:4

Problem are following side-by-side loops:

[scheduler] original ast:
{
  for (int c0 = 0; c0 <= 2; c0 += 1)
S_3(c0);
  for (int c0 = 0; c0 <= 2; c0 += 1)
S_6(c0);
}

[scheduler] AST generated by isl:
{
  for (int c0 = 0; c0 <= 2; c0 += 1)
S_6(c0);
  for (int c0 = 0; c0 <= 2; c0 += 1)
S_3(c0);
}

which are interchanged. But due to fact that there's a data dependency:

...
   [75.00%]:
  # i_38 = PHI 
  _34 = (sizetype) i_38;
  _12 = _34 * 8;
  _7 =  + _12;
  _8 = s1_4(D) + _12;
  _9 = MEM[(int *)_8];
  MEM[(Element_t[2] &)_7][0] = _9; <- store to retval
  _10 = MEM[(int *)_8 + 4B];
  MEM[(Element_t[2] &)_7][1] = _10;
  i_11 = i_38 + 1;
  if (i_11 == 3)
goto ; [33.33%]
  else
goto ; [66.67%]

   [50.00%]:
  goto ; [100.00%]

   [25.00%]:

   [25.00%]:

   [75.00%]:
  # i_39 = PHI 
  _37 = (sizetype) i_39;
  _35 = _37 * 8;
  _13 = _3(D) + _35;
  _14 =  + _35;
  _15 = MEM[(int *)_14];
  MEM[(Element_t[2] &)_13][0] = _15; <-- load from retval, stored to _3+x
  _16 = MEM[(int *)_14 + 4B];
  MEM[(Element_t[2] &)_13][1] = _16;
  i_17 = i_39 + 1;
  if (i_17 == 3)
goto ; [33.33%]
  else
goto ; [66.67%]

   [50.00%]:
  goto ; [100.00%]
...

return _3(D);

I can work on that, but any hint where such dependency should be caught?

[Bug c++/79345] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
Note, if we add a use of gdb_disassembler::m_stream somewhere, like:

  gdb_disassembler_test ()
: gdb_disassembler (verbose == 123 ? _v : _q) // bug here
  {
if (m_stream != _v)
  abort ();
  }

then g++ 7 warns at -O2:

$ /opt/gcc/bin/g++ -std=gnu++11 -O2 -Wall -Wextra -Wuninitialized gcc-bug.cc -o
gcc-bug
gcc-bug.cc: In function ‘int main()’:
gcc-bug.cc:19:63: warning: ‘di.gdb_disassembler_test::verbose’ is used
uninitialized in this function [-Wuninitialized]
 : gdb_disassembler (verbose == 123 ? _v : _q) // bug here
   ^
gcc-bug.cc:29:25: note: ‘di.gdb_disassembler_test::verbose’ was declared here
   gdb_disassembler_test di;
 ^~

Unfortunately, the compilation unit that has this but in gdb doesn't have
any use like that, so the bug went unnoticed.

To reiterate, I think the frontend _should_ be able to warn even without seeing
the use of m_stream.  I.e., I don't think this bug is the same category as the
other truckload of bugs about missing -Winitialized opportunities at -O0
related to not running some parts of the optimization pipeline.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[juergen.reuter at desy dot de]

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

--- Comment #23 from Jürgen Reuter  ---
I filed another PR: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79334

[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 40654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40654=edit
This test case now actually produces a segfault.

[Bug preprocessor/79346] New: -Wundef should not warn for standard macros

[mpeg.blue at free dot fr]

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

Bug ID: 79346
   Summary: -Wundef should not warn for standard macros
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpeg.blue at free dot fr
CC: david at westcontrol dot com, jwakely.gcc at gmail dot com,
vincent-gcc at vinc17 dot net
  Target Milestone: ---

ML discussion:
https://gcc.gnu.org/ml/gcc-help/2017-02/msg0.html

According to Jonathan, -Wundef would warn for this legitimate use-case:

#if __STDC_VERSION__ < 199901L
#endif

Vincent suggested that there could be some kind of white-list for macros which
would not trigger the warning.

Macros suggested for the white-list:
https://gcc.gnu.org/ml/gcc-help/2017-02/msg9.html

__STDC_VERSION__
__STDC_ISO_10646__
__STDC_MB_MIGHT_NEQ_WC__
__STDC_UTF_16__
__STDC_UTF_32__


Bug 49928 might be relevant.

[Bug c++/79345] New: passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

[palves at redhat dot com]

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

Bug ID: 79345
   Summary: passing yet-uninitialized member as argument to base
class constructor should warn (-Wunitialized)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

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

Using g++ 7.0.1 20170202 (trunk), compiling this code:

==
#include 

struct ui_file {};
ui_file stream_v, stream_q;

struct gdb_disassembler
{
  gdb_disassembler (struct ui_file *file) : m_stream (file) {}

  struct ui_file *m_stream;
};

/* Test disassembly of one instruction.  */
struct gdb_disassembler_test : public gdb_disassembler
{
  const bool verbose = false;

  gdb_disassembler_test ()
: gdb_disassembler (verbose ? _v : _q) // bug here
  {}

  void use_stream ();
};

void
func ()
{
  gdb_disassembler_test di;

  di.use_stream ();
}



with:

 g++ -std=gnu++11 uninitialized.cc -c -o uninitialized -O2

does not produce any warning.  However, the member initializer here at:

  gdb_disassembler_test ()
: gdb_disassembler (verbose ? _v : _q) // bug here
  {}

is passing the yet-uninitialized "gdb_disassembler_test::verbose" to the
gdb_disassembler ctor.  This is a bug, because even though the "verbose" field
has an in-class initializer, base classes are initialized before members of the
current class are initialized.

The frontend end obviously must know this, so it should be able to detect the
bug and warn, regardless of optimization level.  (At least, when passing by
value.  Passing by reference/pointer may have legitimate uses.)

(TBC, g++ does not warn at any optimization level.)

Looks like a regression.  I tried:

   g++ 7.0.1 20170202 (trunk)
   g++ 5.3.1 (Fedora 23)
   g++ 4.8.5
   g++ 4.7.4
   clang++ 3.7

All but g++ 7 warned at -O2.  None warned at -O0.
clang++ manages to warn even at -O0.

g++ 5.3.1 (-O2):

$ g++ -std=gnu++11 -O2 -Wall -Wextra -Wuninitialized gcc-bug.cc -c -o gcc-bug
gcc-bug.cc: In function ‘void func()’:
gcc-bug.cc:19:25: warning: ‘di.gdb_disassembler_test::verbose’ is used
uninitialized in this function [-Wuninitialized]
 : gdb_disassembler (verbose ? _v : _q) // bug here
 ^
gcc-bug.cc:28:25: note: ‘di’ was declared here
   gdb_disassembler_test di;
 ^

g++ 4.7 (-O2):

$ /opt/gcc-4.7/bin/g++ -std=gnu++11 -O2 -Wall -Wextra -Wuninitialized
gcc-bug.cc -c -o gcc-bug
gcc-bug.cc: In function ‘void func()’:
gcc-bug.cc:19:56: warning: ‘di.gdb_disassembler_test::verbose’ is used
uninitialized in this function [-Wuninitialized]
gcc-bug.cc:28:25: note: ‘di’ was declared here


clang++ (-O0):

$ clang++ -std=gnu++11 -O0 -Wall -Wextra -Wuninitialized gcc-bug.cc -c -o
gcc-bug
gcc-bug.cc:19:25: warning: field 'verbose' is uninitialized when used here
[-Wuninitialized]
: gdb_disassembler (verbose ? _v : _q) // bug here
^
1 warning generated.

[Bug fortran/79344] New: [7 Regression] segmentation faults and run-time errors

[juergen.reuter at desy dot de]

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

Bug ID: 79344
   Summary: [7 Regression]  segmentation faults and run-time
errors
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 40652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40652=edit
Smaller test case of one (only one?) of the problems

This is a continuation of the bug 79230. There are other issues, not fixed by
the patch of Andre Vehreschild. Here is the link to the full test case:
http://whizard.hepforge.org/versions/unofficial/whizard-2.4.1_alpha-20170131.tar.gz
A smaller test case of one of the issues will be attached.

[Bug target/78439] [7 Regression] error: insn does not satisfy its constraints (arm-linux-gnueabihf)

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #13 from wilco at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
> Fixed.

Shouldn't this also be backported to be sure it cannot trigger in older GCCs?

[Bug target/79197] [5/6 Regression] ICE in extract_insn in gcc/recog.c:2311

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #15)
> I see SIGILL on
>0x3fffb7e722e8 :   xscvuxdsp vs32,vs33
> => 0x3fffb7e722ec :   stxssp  v0,0(r31)
>0x3fffb7e722f0 :   add r31,r31,r27
> This is in libhdf5 compiled with -mcpu=power8, I believe stxssp is power9
> instruction.  Let me try to distill a self-contained testcase.

That is indeed a power9 (ISA 3.0) instruction.  That should probably be a
separate bug.

[Bug fortran/79287] include files not searched for relative to the file containing the fortran include statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug fortran/79287] include files not searched for relative to the file containing the fortran include statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Oliver Kiddle from comment #2)
> The interpretation of the string being outside the scope of the standard
> doesn't stop this being an issue. Should I, as an outsider, interpret a
> WONTFIX resolution as meaning that you regard it as something that should
> not be changed - it is intended behavior - or merely that you as an
> individual are not motivated to fix it yourself. In the case of the former,
> some explanation would be nice and in the latter case, I'd have thought that
> leaving the issue open with a note to indicate whether a patch would be
> welcomed would be more helpful.

Patches are always welcomed.  WONTFIX here means that there is simply
not enough developers to address the 800+ Fortran bugs.  This bug is
deemed to be a nonissue, because it is processor defined behavior 
and you can use a -I option to find the file.

> To further elaborate on the issue, note that the preprocessor does work in
> the manner I suggest. The documentation for the -I option even states that
> "the general behavior of -I and "INCLUDE" is pretty much the same as of -I
> with "#include" in the cpp preprocessor.

Yeah, there are bugs in the documentation.  We accept patches
to the docs as well.

[Bug target/79197] [5/6 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
I see SIGILL on
   0x3fffb7e722e8 : xscvuxdsp vs32,vs33
=> 0x3fffb7e722ec : stxssp  v0,0(r31)
   0x3fffb7e722f0 : add r31,r31,r27
This is in libhdf5 compiled with -mcpu=power8, I believe stxssp is power9
instruction.  Let me try to distill a self-contained testcase.

[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ccoutant at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Probably latent everywhere, it just depends on -g3 and delicate balance of
indirect macro strings screwing up the hash table.  For this reason not really
a regression, just bad luck that it appears as one.

Cary?  It also looks like late introduced indirect strings will have no index
assigned?

[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Broken by

#0  hash_table::expand (
this=0x768a1360)
at /space/rguenther/src/svn/gcc-6-branch/gcc/hash-table.h:734
#1  0x00c5803e in hash_table::find_slot_with_hash (this=0x768a1360, 
comparable=@0x7fffd838: 0x769d79f0 "__cplusplus ", 
hash=2325771649, insert=INSERT)
at /space/rguenther/src/svn/gcc-6-branch/gcc/hash-table.h:860
#2  0x00c183c2 in find_AT_string_in_table (
str=0x769d79f0 "__cplusplus ", table=0x768a1360)
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:4099
#3  0x00c18461 in find_AT_string (str=0x769d79f0 "__cplusplus ")
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:4121
#4  0x00c4af5f in output_macinfo_op (ref=0x77eaf020)
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:25082
#5  0x00c4aecc in output_macinfo_op (ref=0x77eaf020)
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:25070
#6  0x00c4b95c in output_macinfo ()
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:25351
#7  0x00c516cc in dwarf2out_finish (filename=0x28dea50 "t.ii")
at /space/rguenther/src/svn/gcc-6-branch/gcc/dwarf2out.c:27975

enlarging the hash table after indexes are assigned.  Only afterwards
we are outputting indirect strings.

So the fix is probably to move assigning indexes right before outputting?
Or to not create new indirect strings when outputting macinfo.  Or to not
rely on hash table walking.

[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Introduced on trunk in r224371 and disappeared in r239783.

[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-02
 Ever confirmed|0   |1

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

[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.4

[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P2
   Target Milestone|--- |6.4

--- Comment #2 from Richard Biener  ---
wrong-code shouldn't be P4 even if it is graphite.

[Bug target/79343] [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Yes, please see https://gcc.gnu.org/gcc-7/changes.html:

PowerPC / PowerPC64 / RS6000

The PowerPC port now uses LRA by default.
GCC now diagnoses inline assembly that clobbers register r2. This has always
been invalid code, and is no longer quietly tolerated.

[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-02
 CC||marxin at gcc dot gnu.org
Summary|[graphite] tramp3d-v4   |[6/7 Regression][graphite]
   |compiled with   |tramp3d-v4 compiled with
   |-floop-nest-optimize|-floop-nest-optimize
   |crashes |crashes
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r227567. I've got ISL 0.16.1.

[Bug target/79343] [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/79343] [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
The original source is
https://github.com/xianyi/OpenBLAS/blob/develop/kernel/power/sasum_microk_power8.c
Is that invalid for ppc64le (previously, or only now)?

[Bug target/79343] New: [7 Regression] error: PIC register clobbered by '%2' in 'asm'

[jakub at gcc dot gnu.org]

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

Bug ID: 79343
   Summary: [7 Regression] error: PIC register clobbered by '%2'
in 'asm'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

openblas fails to compile on ppc64le-linux starting with r235876.
Small testcase:
void
foo (void)
{
  asm volatile ("" : : : "%2");
}
sasum.c: In function ‘foo’:
sasum.c:4:3: error: PIC register clobbered by ‘%2’ in ‘asm’
   asm volatile ("" : : : "%2");
   ^~~

I thought ppc64le ELFv2 is not PIC by default (and it is rejected even with
-fno-pic).

[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #9 from Matthias Klose  ---
PR79342 might be related (with a reduced test case of the 20170131 preprocessed
source)

[Bug debug/79342] New: [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf

[doko at gcc dot gnu.org]

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

Bug ID: 79342
   Summary: [6 Regression] ICE in output_index_string, at
dwarf2out.c:25635 with -gsplit-dwarf
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen on the gcc-6-branch, at least 20161005 and 20170202, not on 5 and on the
trunk.  May be related to PR70578.

$ g++-6 -std=gnu++11 -c -gsplit-dwarf -g3 -Og -fno-exceptions uvectr64.ii
uvectr64.ii:3031:1: internal compiler error: in output_index_string, at
dwarf2out.c:25635
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at ucw dot cz]

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

--- Comment #39 from Jan Hubicka  ---
> Finally, the total between after the last and before the first patch.  
> Overall,
> some tests gain some performance and others lose some.  The total number of
> instructions has grown somewhat (especially tonto, calculix, dealII and wrf),
> but there's no obvious connection between an increased number of instructions
> and loss of performance.
> 
> Is this what can be expected of the patches?

I would say so - the prediction controls a lot of different heuristics
and call predictor is quite weak (random) so it is expected to have bit random
effects.

I also can't see much of corelation in the tests, so I guess it is just
random noise.  Thanks for the tests!

Honza

[Bug fortran/79287] include files not searched for relative to the file containing the fortran include statement

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #3 from Thomas Koenig  ---
This is not mandated by the standard, but I can see that
it could be useful.

Confirming as enhancement request.

[Bug other/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Can you:
   s390*-*-linux*)
-if test x$ac_cv_sizeof_void_p = x4; then
-UNSUPPORTED=1
-fi
in libsanitizer/configure.tgt and retry?  As I said on the mailing list, I
don't have any longer a way (at least not easy) to test 31-bit s390, which is
why I haven't enabled it because I couldn't test it.
If it works, then those 3 lines should be dropped.
If it doesn't work, we'll need to figure out something (such as extending the
asan_shadow_offset hook so that target can signal to toplev.c the lack of asan
support even in a different way than having the hook NULL.  Either through a
magic value, or extra argument).

[Bug other/79341] New: Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79341
   Summary: Many Asan tests fail on s390
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390
Target: s390

The recent Asan patch for s390x (64 bit) has triggered about 270 Asan test
failures on s390 (31 bit).

[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[vogt at linux dot vnet.ibm.com]

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

--- Comment #33 from Dominik Vogt  ---
I still disagree with reverting the patch.  There was plenty of time to
identify and fix affected backends instead of doing nothing for half five
months and then claiming that the patch is potentially too disruptive at this
point in the release cycle.

[Bug target/79197] [5/6 Regression] ICE in extract_insn in gcc/recog.c:2311

[tom at compton dot nu]

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

Tom Hughes  changed:

   What|Removed |Added

 CC||tom at compton dot nu

--- Comment #14 from Tom Hughes  ---
That build worked because the tests were disabled on ppc64le. The first attempt
(https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752) is the one which
failed.

It looks like the test crashed running a test called "Testing hard unsigned
long -> float conversions" which sounded like it might be related to this.

[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #32 from Eric Botcazou  ---
.

[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #31 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Feb  2 12:39:09 2017
New Revision: 245124

URL: https://gcc.gnu.org/viewcvs?rev=245124=gcc=rev
Log:
PR middle-end/78468
* emit-rtl.c (init_emit): Add ??? comment for problematic alignment
settings of the virtual registers.

Revert again
2016-08-23  Dominik Vogt  

* explow.c (get_dynamic_stack_size): Take known alignment of stack
pointer + STACK_DYNAMIC_OFFSET into account when calculating the size
needed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/explow.c