[Bug c/80638] -ansi suppresses -Wstringop-overflow for mempcpy

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
>Calls to known library functions that overflow should be diagnosed regardless 
>of -ansi.

No, because mempcpy is not included in the ISO standard.  Basically -ansi is
the same as doing -fstd=c11.

[Bug c/80638] -ansi suppresses -Wstringop-overflow for mempcpy

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
If you had used __builtin_mempcpy you would have got the warning.

[Bug c/80638] -ansi suppresses -Wstringop-overflow for mempcpy

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
-ansi disables mempcpy as being a builtin.

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

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

--- Comment #10 from coypu  ---
(In reply to H.J. Lu from comment #9)
> 
> This may break Linux.  You may want to investigate if this approach:
> 
> commit 6e6c7fc1e15525a10f48d4f5ac2edd853e2f5cb7
> Author: nsz 
> Date:   Fri Nov 11 17:31:07 2016 +
> 
> [i386][musl] Add cpuinfo to static libgcc only on *-musl*
> 
> The __cpu_indicator_init and __cpu_model symbols are not safe to use
> from shared libgcc_s.so from ifunc resolvers, so since gcc-6, only
> the definitions from static libgcc.a are used, however the symbols
> are kept in libgcc_s as well for backward compatibility (with
> appropriate symbol version).  On targets without such backward
> compatibility concern add cpuinfo to the static library only (this
> avoids running the ctor, reduces libgcc_s size and elf abi concerns
> about the versioned symbols).
> 
> works for you.

Thanks. if I understand it correctly, it breaks backwards compatibility, so
would rather avoid it. With my (not upstreamable) patch we have a working GCC,
so it's not a pressing issue for us, although it seems to affect many other
platforms.

[Bug c/80638] New: -ansi suppresses -Wstringop-overflow for mempcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 80638
   Summary: -ansi suppresses -Wstringop-overflow for mempcpy
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A program containing a buffer overflow in a call to mempcpy compiled with the
-ansi option GCC is not diagnosed.  The same program is diagnosed without the
option, or when the call to mempcpy is replaced with memcpy.

Calls to known library functions that overflow should be diagnosed regardless
of -ansi.

$ (set -x && cat a.c && for opt in '' -ansi; do gcc -O2 -S -Wall $opt a.c;
done)
+ cat a.c
extern void* mempcpy (void*, const void*, __SIZE_TYPE__);

char d[3];

void f (void)
{
  mempcpy (d, "1234", 5);
}
+ for opt in ''\'''\''' -ansi
+ gcc -O2 -S -Wall a.c
a.c: In function ‘f’:
a.c:7:3: warning: ‘mempcpy’ writing 5 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
   mempcpy (d, "1234", 5);
   ^~
+ for opt in ''\'''\''' -ansi
+ gcc -O2 -S -Wall -ansi a.c
$

[Bug c++/80637] New: [concepts] incorrect ambiguous overload

[ryan.burn at gmail dot com]

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

Bug ID: 80637
   Summary: [concepts] incorrect ambiguous overload
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

This code won't compile with GCC

/
template 
struct A {
  void f() 
requires std::is_same_v
  {
  }

  void f(int) 
requires !std::is_same_v
  {
  }
};

int main() {
  auto fptr = ::f;
  return 0;
}
/

According to the discussion here, it should be valid:

http://stackoverflow.com/q/43793941/4447365

[Bug target/80634] strangely missed vectorization optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |target

--- Comment #2 from Andrew Pinski  ---
So it is doing an alignment check ...

So that would mean it is an issue with the cost model.

[Bug target/80636] New: AVX / AVX512 register-zeroing should always use AVX 128b, not ymm or zmm

[peter at cordes dot ca]

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

Bug ID: 80636
   Summary: AVX / AVX512 register-zeroing should always use AVX
128b, not ymm or zmm
   Product: gcc
   Version: 8.0
   URL: http://stackoverflow.com/questions/43713273/is-vxorps-
zeroing-on-amd-jaguar-bulldozer-zen-faster-with-xmm-re
gisters-than-ymm
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Currently, gcc compiles _mm256_setzero_ps() to vxorps %ymm0, %ymm0, %ymm0, or
zmm for _mm512_setzero_ps.  And similar for pd and integer vectors, using a
vector size that matches how it's going to use the register.

vxorps %xmm0, %xmm0, %xmm0 has the same effect, because AVX instructions zero
the destination register out to VLMAX.

AMD Ryzen decodes the xmm version to 1 micro-op, but the ymm version to 2
micro-ops.  It doesn't detect the zeroing idiom special-case until after the
decoder has split it.  (Earlier AMD CPUs (Bulldozer/Jaguar) may be similar.)

---

For zeroing a ZMM register, it also saves a byte or two to use a VEX prefix
instead of EVEX, if the target register is zmm0-15.  (zmm16-31 of course always
need EVEX).

---

There is no benefit, but also no downside, to using xmm-zeroing on Intel CPUs
that don't split 256b or 512b vector ops.  This change could be made across the
board, without adding any tuning options to control it.

References: 
http://stackoverflow.com/a/43751783/224132 Agner Fog's answer to my SO question
about this.
https://bugs.llvm.org/show_bug.cgi?id=32862  the same issue for clang.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Sadly, even with pr79214 fixed and pr79234 implemented, -Wno-system-headers
still somehow defeats the warning.

[Bug middle-end/79234] warn on past the end reads by library functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Patch committed in r247622.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 23:50:21 2017
New Revision: 247622

URL: https://gcc.gnu.org/viewcvs?rev=247622=gcc=rev
Log:
PR libstdc++/54924 - Warn for std::string constructor with wrong size
PR middle-end/79234 - warn on past the end reads by library functions

gcc/ChangeLog:

PR middle-end/79234
* builtins.c (check_sizes): Adjust to handle reading past the end.
Avoid printing excessive upper bound of ranges.  Use %E to print
tree nodes instead of converting them to %wu.
(expand_builtin_memchr): New function.
(compute_dest_size): Rename...
(compute_objsize): ...to this.
(expand_builtin_memcpy): Adjust.
(expand_builtin_mempcpy): Adjust.
(expand_builtin_strcat): Adjust.
(expand_builtin_strcpy): Adjust.
(check_strncat_sizes): Adjust.
(expand_builtin_strncat): Adjust.
(expand_builtin_strncpy): Adjust and simplify.
(expand_builtin_memset): Adjust.
(expand_builtin_bzero): Adjust.
(expand_builtin_memcmp): Adjust.
(expand_builtin): Handle memcmp.
(maybe_emit_chk_warning): Check strncat just once.

gcc/testsuite/ChangeLog:

PR middle-end/79234
* gcc.dg/builtin-stringop-chk-8.c: New test.
* gcc.dg/builtin-stringop-chk-1.c: Adjust.
* gcc.dg/builtin-stringop-chk-4.c: Same.
* gcc.dg/builtin-strncat-chk-1.c: Same.
* g++.dg/ext/strncpy-chk1.C: Same.
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Same.
* gcc.dg/out-of-bounds-1.c: Same.
* gcc.dg/pr78138.c: Same.
* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Same.
* gfortran.dg/mvbits_7.f90: Same.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/strncpy-chk1.C
trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-4.c
trunk/gcc/testsuite/gcc.dg/builtin-strncat-chk-1.c
trunk/gcc/testsuite/gcc.dg/out-of-bounds-1.c
trunk/gcc/testsuite/gcc.dg/pr78138.c
trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90

[Bug middle-end/79234] warn on past the end reads by library functions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 23:50:21 2017
New Revision: 247622

URL: https://gcc.gnu.org/viewcvs?rev=247622=gcc=rev
Log:
PR libstdc++/54924 - Warn for std::string constructor with wrong size
PR middle-end/79234 - warn on past the end reads by library functions

gcc/ChangeLog:

PR middle-end/79234
* builtins.c (check_sizes): Adjust to handle reading past the end.
Avoid printing excessive upper bound of ranges.  Use %E to print
tree nodes instead of converting them to %wu.
(expand_builtin_memchr): New function.
(compute_dest_size): Rename...
(compute_objsize): ...to this.
(expand_builtin_memcpy): Adjust.
(expand_builtin_mempcpy): Adjust.
(expand_builtin_strcat): Adjust.
(expand_builtin_strcpy): Adjust.
(check_strncat_sizes): Adjust.
(expand_builtin_strncat): Adjust.
(expand_builtin_strncpy): Adjust and simplify.
(expand_builtin_memset): Adjust.
(expand_builtin_bzero): Adjust.
(expand_builtin_memcmp): Adjust.
(expand_builtin): Handle memcmp.
(maybe_emit_chk_warning): Check strncat just once.

gcc/testsuite/ChangeLog:

PR middle-end/79234
* gcc.dg/builtin-stringop-chk-8.c: New test.
* gcc.dg/builtin-stringop-chk-1.c: Adjust.
* gcc.dg/builtin-stringop-chk-4.c: Same.
* gcc.dg/builtin-strncat-chk-1.c: Same.
* g++.dg/ext/strncpy-chk1.C: Same.
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Same.
* gcc.dg/out-of-bounds-1.c: Same.
* gcc.dg/pr78138.c: Same.
* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Same.
* gfortran.dg/mvbits_7.f90: Same.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/strncpy-chk1.C
trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-4.c
trunk/gcc/testsuite/gcc.dg/builtin-strncat-chk-1.c
trunk/gcc/testsuite/gcc.dg/out-of-bounds-1.c
trunk/gcc/testsuite/gcc.dg/pr78138.c
trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #2 from Pedro Alves  ---
Looks like a regression at some point:

There are no warnings with g++ 5.3.1, either reduced testcase, or with the
obvious change to use std::experimental::optional instead of std::optional.

Also no warnings with g++ 8.0.0 20170428 + -fno-lifetime-dse or
-flifetime-dse=1, perhaps unsurprisingly.

The original bug supposedly triggers with g++ 6.3.1 too, though I haven't
confirmed with the reduced testcase there.  (It's an s390 gdb buildbot, I don't
have access to it.)

[Bug tree-optimization/80632] [8 Regression] error: invalid PHI argument with -O2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Testcase without implicit ints:

extern int d (void);
extern void e (void);
int a;

int
b (void)
{
  int c;
  if (d ())
{
  e ();
  switch (a)
{
case 0:
  c = 1;
  break;
case 1:
  c = 0;
  break;
case 2:
  c = 0;
  break;
case 3:
  c = 0;
  break;
default:
  c = 1;
}
}
  return c;
}

[Bug tree-optimization/80632] [8 Regression] error: invalid PHI argument with -O2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |8.0
Summary|error: invalid PHI argument |[8 Regression] error:
   |with -O2|invalid PHI argument with
   ||-O2

--- Comment #3 from Marek Polacek  ---
Started with r247538.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitilized

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
If you uncomment the lines to use std::optional instead, you get:

 $ /opt/gcc/bin/g++ optional.cc -g3 -O2 -Wall -std=gnu++17 -c 
 optional.cc: In function ‘void func()’:
 optional.cc:28:15: warning: ‘maybe_a.A::m’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
~A () { set (m); }
^~~
 optional.cc:41:15: note: ‘maybe_a.A::m’ was declared here
Optional maybe_a;
^~~

This warns at a different location from the reproducer in the OP.

If you revert back to use the self-contained optional, and change the
optional::m_dummy field to be of empty struct type, similarly to
std::optional:

  union
  {
struct {} m_dummy;
T m_item;
  };

then you get the exact same warning you get with std::optional.

I suspect that the "maybe_a.A::m" location is a bug of its own and a red
herring here, but I can't be sure.

[Bug c++/80635] New: std::optional and bogus -Wmaybe-uninitilized

[palves at redhat dot com]

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

Bug ID: 80635
   Summary: std::optional and bogus -Wmaybe-uninitilized
   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: ---

GDB ran into an odd -Wmaybe-uninitialized warning in code using std::optional
Well, actually with gdb::optional, but std::optional shows the exact same
warning.  https://sourceware.org/ml/gdb-patches/2017-05/msg00118.html>.

The reproducer below is a reduced self-contained testcase that triggers the
same warning.  I wasn't able to reduce it further.

 $ cat optional.cc
 //#include 
 #include 

 template
 struct optional
 {
   optional () : m_dummy () {}
   ~optional () { m_item.~T (); }
   void emplace () { new (_item) T (); }

   union
   {
 int m_dummy;
 T m_item;
   };
 };

 template 
 using Optional = optional; // warns
 //using Optional = std::optional; // warns too

 extern int get ();
 extern void set (int);

 struct A
 {
   A () : m (get ()) {}
   ~A () { set (m); }

   int m;
 };

 struct B
 {
   B ();
   ~B ();
 };

 void func ()
 {
   Optional maybe_a;
   Optional maybe_b;

   maybe_a.emplace ();
   maybe_b.emplace ();
 }

With g++ 8.0.0 20170428 pristine built from trunk:

 $ /opt/gcc/bin/g++ optional.cc -g3 -O2 -Wall -c
 optional.cc: In function ‘void func()’:
 optional.cc:28:15: warning:
‘maybe_a.optional::.optionalm_dummy’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
~A () { set (m); }
^~~
 optional.cc:41:15: note:
‘maybe_a.optional::.optionalm_dummy’ was
declared here
Optional maybe_a;
^~~

[Bug other/80634] strangely missed vectorization optimizations

[steven at uplinklabs dot net]

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

--- Comment #1 from Steven Noonan  ---
Created attachment 41323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41323=edit
icc 17.0.1 outputs for ELEMS=1 through ELEMS=32

[Bug other/80634] New: strangely missed vectorization optimizations

[steven at uplinklabs dot net]

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

Bug ID: 80634
   Summary: strangely missed vectorization optimizations
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
  Target Milestone: ---

Created attachment 41322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41322=edit
gcc 6.3.1 outputs for ELEMS=1 through ELEMS=32

(Not sure which component is the correct one for this issue).

I've noticed that the vectorizer makes some strange choices occasionally, and
will turn some straightforward code into a large branchy code sequence. Take
this, for example:

void saxpy(float a, float * restrict x, float * restrict y)
{
for (int i = 0; i < ELEMS; ++i)
y[i] = a*x[i] + y[i];
}

If I use the flags "-O3 -march=haswell" (or "-O3 -xAVX2" on ICC) and use
varying definitions of ELEMS, I will sometimes get odd results with GCC 6.3.1.

Here's -DELEMS=6 with GCC 6.3.1:

saxpy:
vshufps $0, %xmm0, %xmm0, %xmm1
vmovups (%rsi), %xmm2
vfmadd132ps (%rdi), %xmm2, %xmm1
vmovss  20(%rsi), %xmm3
vmovups %xmm1, (%rsi)
vmovss  16(%rdi), %xmm1
vfmadd213ss 16(%rsi), %xmm0, %xmm1
vfmadd132ss 20(%rdi), %xmm3, %xmm0
vmovss  %xmm1, 16(%rsi)
vmovss  %xmm0, 20(%rsi)
ret

Seems reasonable.


Here's -DELEMS=7 with GCC 6.3.1:

saxpy:
movq%rsi, %rax
shrq$2, %rax
negq%rax
andl$3, %eax
je  .L7
vmovss  (%rdi), %xmm1
vfmadd213ss (%rsi), %xmm0, %xmm1
vmovss  %xmm1, (%rsi)
cmpl$1, %eax
je  .L8
vmovss  4(%rdi), %xmm1
vfmadd213ss 4(%rsi), %xmm0, %xmm1
vmovss  %xmm1, 4(%rsi)
cmpl$3, %eax
jne .L9
vmovss  8(%rdi), %xmm1
vfmadd213ss 8(%rsi), %xmm0, %xmm1
movl$4, %r8d
movl$3, %edx
vmovss  %xmm1, 8(%rsi)
.L3:
movl$7, %ecx
movl%eax, %r9d
subl%eax, %ecx
.L2:
leaq(%rsi,%r9,4), %rax
vshufps $0, %xmm0, %xmm0, %xmm1
vmovaps (%rax), %xmm3
vfmadd132ps (%rdi,%r9,4), %xmm3, %xmm1
vmovaps %xmm1, (%rax)
leal4(%rdx), %eax
cmpl$4, %ecx
je  .L19
cltq
addl$5, %edx
leaq(%rsi,%rax,4), %rcx
vmovss  (%rdi,%rax,4), %xmm1
vfmadd213ss (%rcx), %xmm0, %xmm1
vmovss  %xmm1, (%rcx)
cmpl$5, %r8d
je  .L17
movslq  %edx, %rdx
leaq(%rsi,%rdx,4), %rax
vmovss  (%rdi,%rdx,4), %xmm1
vfmadd213ss (%rax), %xmm0, %xmm1
vmovss  %xmm1, (%rax)
cmpl$6, %r8d
je  .L17
vmovss  24(%rsi), %xmm2
vfmadd132ss 24(%rdi), %xmm2, %xmm0
vmovss  %xmm0, 24(%rsi)
ret
.L17:
ret
.L7:
movl$7, %ecx
xorl%r9d, %r9d
movl$7, %r8d
xorl%edx, %edx
jmp .L2
.L19:
ret
.L8:
movl$6, %r8d
movl$1, %edx
jmp .L3
.L9:
movl$5, %r8d
movl$2, %edx
jmp .L3


This might be explained away by it being an odd number just short of a power of
two, but ICC does an apparently better job (one packed FMA plus three single
FMAs):

saxpy:

vbroadcastss %xmm0, %xmm2
vmovups   (%rdi), %xmm1
vmovss16(%rdi), %xmm3
vmovss20(%rdi), %xmm4
vmovss24(%rdi), %xmm5
vfmadd213ps (%rsi), %xmm1, %xmm2
vfmadd213ss 16(%rsi), %xmm0, %xmm3
vfmadd213ss 20(%rsi), %xmm0, %xmm4
vfmadd213ss 24(%rsi), %xmm5, %xmm0
vmovups   %xmm2, (%rsi)
vmovss%xmm3, 16(%rsi)
vmovss%xmm4, 20(%rsi)
vmovss%xmm0, 24(%rsi)
ret

The results from GCC 6.3.1 for ELEMS values 8 through 14 look fine (short
branchless code sequences similar to what ICC emits), but things go to crap
again for what seems to be *any* value ELEMS=15 or above.

It even misses the opportunity with ELEMS=16 to just do two packed FMAs with
YMM registers:

saxpy:
movq%rsi, %rax
shrq$2, %rax
negq%rax
andl$7, %eax
je  .L7
vmovss  (%rdi), %xmm1
vfmadd213ss (%rsi), %xmm0, %xmm1
vmovss  %xmm1, (%rsi)
cmpl$1, %eax
je  .L8
vmovss  4(%rdi), %xmm1
vfmadd213ss 4(%rsi), %xmm0, %xmm1
vmovss  %xmm1, 4(%rsi)
cmpl$2, %eax
je  .L9
vmovss  8(%rdi), %xmm1
vfmadd213ss 8(%rsi), %xmm0, %xmm1
vmovss  %xmm1, 8(%rsi)
cmpl$3, %eax
je  .L10
vmovss  12(%rdi), %xmm1
vfmadd213ss 

[Bug middle-end/79223] missing -Wstringop-overflow on a memmove overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #3 from Martin Sebor  ---
Fix committed in r247618.

[Bug middle-end/79222] missing -Wstringop-overflow= on a stpcpy overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #4 from Martin Sebor  ---
Fix committed in r247618.

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #6 from Martin Sebor  ---
Fix committed in r247618.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[msebor at gcc dot gnu.org]

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

Bug 79214 Summary: -Wno-system-header defeats strncat buffer overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79214

   What|Removed |Added

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

[Bug middle-end/79223] missing -Wstringop-overflow on a memmove overflow

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 20:54:43 2017
New Revision: 247618

URL: https://gcc.gnu.org/viewcvs?rev=247618=gcc=rev
Log:
PR preprocessor/79214 -  -Wno-system-header defeats strncat buffer overflow
warnings
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
PR middle-end/79223 - missing -Wstringop-overflow on a memmove overflow

gcc/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* builtins.c (check_sizes): Add inlinining context and issue
warnings even when -Wno-system-headers is set.
(check_strncat_sizes): Same.
(expand_builtin_strncat): Same.
(expand_builtin_memmove): New function.
(expand_builtin_stpncpy): Same.
(expand_builtin): Handle memmove and stpncpy.

gcc/testsuite/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* gcc.dg/pr79214.c: New test.
* gcc.dg/pr79214.h: New test header.
* gcc.dg/pr79222.c: New test.
* gcc.dg/pr79223.c: New test.
* gcc.dg/pr78138.c: Adjust.
* gfortran.dg/unconstrained_commons.f: Same.


Added:
trunk/gcc/testsuite/gcc.dg/pr79214.c
trunk/gcc/testsuite/gcc.dg/pr79214.h
trunk/gcc/testsuite/gcc.dg/pr79222.c
trunk/gcc/testsuite/gcc.dg/pr79223.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr78138.c
trunk/gcc/testsuite/gfortran.dg/unconstrained_commons.f

[Bug middle-end/79222] missing -Wstringop-overflow= on a stpcpy overflow

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 20:54:43 2017
New Revision: 247618

URL: https://gcc.gnu.org/viewcvs?rev=247618=gcc=rev
Log:
PR preprocessor/79214 -  -Wno-system-header defeats strncat buffer overflow
warnings
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
PR middle-end/79223 - missing -Wstringop-overflow on a memmove overflow

gcc/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* builtins.c (check_sizes): Add inlinining context and issue
warnings even when -Wno-system-headers is set.
(check_strncat_sizes): Same.
(expand_builtin_strncat): Same.
(expand_builtin_memmove): New function.
(expand_builtin_stpncpy): Same.
(expand_builtin): Handle memmove and stpncpy.

gcc/testsuite/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* gcc.dg/pr79214.c: New test.
* gcc.dg/pr79214.h: New test header.
* gcc.dg/pr79222.c: New test.
* gcc.dg/pr79223.c: New test.
* gcc.dg/pr78138.c: Adjust.
* gfortran.dg/unconstrained_commons.f: Same.


Added:
trunk/gcc/testsuite/gcc.dg/pr79214.c
trunk/gcc/testsuite/gcc.dg/pr79214.h
trunk/gcc/testsuite/gcc.dg/pr79222.c
trunk/gcc/testsuite/gcc.dg/pr79223.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr78138.c
trunk/gcc/testsuite/gfortran.dg/unconstrained_commons.f

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 20:54:43 2017
New Revision: 247618

URL: https://gcc.gnu.org/viewcvs?rev=247618=gcc=rev
Log:
PR preprocessor/79214 -  -Wno-system-header defeats strncat buffer overflow
warnings
PR middle-end/79222 - missing -Wstringop-overflow= on a stpcpy overflow
PR middle-end/79223 - missing -Wstringop-overflow on a memmove overflow

gcc/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* builtins.c (check_sizes): Add inlinining context and issue
warnings even when -Wno-system-headers is set.
(check_strncat_sizes): Same.
(expand_builtin_strncat): Same.
(expand_builtin_memmove): New function.
(expand_builtin_stpncpy): Same.
(expand_builtin): Handle memmove and stpncpy.

gcc/testsuite/ChangeLog:

PR preprocessor/79214
PR middle-end/79222
PR middle-end/79223
* gcc.dg/pr79214.c: New test.
* gcc.dg/pr79214.h: New test header.
* gcc.dg/pr79222.c: New test.
* gcc.dg/pr79223.c: New test.
* gcc.dg/pr78138.c: Adjust.
* gfortran.dg/unconstrained_commons.f: Same.


Added:
trunk/gcc/testsuite/gcc.dg/pr79214.c
trunk/gcc/testsuite/gcc.dg/pr79214.h
trunk/gcc/testsuite/gcc.dg/pr79222.c
trunk/gcc/testsuite/gcc.dg/pr79223.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr78138.c
trunk/gcc/testsuite/gfortran.dg/unconstrained_commons.f

[Bug c/80632] error: invalid PHI argument with -O2

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Reduced code:

a;
b() {
  int c;
  if (d()) {
e();
switch (a) {
case 0:
  c = 1;
  break;
case 1:
  c = 0;
  break;
case 2:
  c = 0;
  break;
case 3:
  c = 0;
  break;
default:
  c = 1;
}
  }
  return c;
}

[Bug c++/80633] New: [7/8 Regression] -Wstrict-aliasing false positive

[Casey at Carter dot net]

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

Bug ID: 80633
   Summary: [7/8 Regression] -Wstrict-aliasing false positive
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 41321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41321=edit
Repro (sorry, not library-free)

gcc 7.1.1 20170504 and 8.0.0 20170504 - but not 6.2/5.4/4.9.4 - incorrectly
diagnose this program:

#include 

extern void f(std::istream&);
std::ifstream ss;
using T = decltype(f(ss)); // warning: dereferencing type-punned pointer will
break strict-aliasing rules

when compiling with "gcc -Wstrict-aliasing -O2 -c". The diagnostic is notably
not emitted for "decltype(f(std::declval<std::ifstream&>()))".

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[colu...@gmx-topmail.de]

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

--- Comment #7 from Robert Haberlach  ---
Oh, damn. "Submit only my new comment" does not what I thought it does. :-)

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[colu...@gmx-topmail.de]

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

--- Comment #6 from Robert Haberlach  ---
(In reply to TC from comment #4)
> (In reply to Eric Fiselier from comment #3)
> > Here is an example of why `_Bind::operator()(...) const` must be considered
> > during overload resolution even if the call wrapper itself is not const.
> > 
> > --
> > #include 
> > 
> > struct Func {
> >   template 
> >   void operator()(Args&&...) = delete;
> > 
> >   template 
> >   void operator()(Args&&...) const {}
> > };
> > 
> > int main() {
> > Func f;
> > std::bind(f)();
> > }
> > -
> 
> Interesting, libstdc++ rejects this as an attempt to call a deleted
> function. That seems more correct than libc++'s approach which calls the
> const overload.

See also the discussion on Phabricator: https://reviews.llvm.org/D32824

I agree. AFAICS [func.bind.bind] is clear on this: the type of the Func
object used to call the member operator() is non-const.

[Bug c/80632] error: invalid PHI argument with -O2

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
This bugs seems to have appeared between revision 247534
and 247578.

I'll have a go at reducing it.

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[r.hl at gmx dot net]

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

--- Comment #5 from r.hl at gmx dot net ---
See also the discussion on Phabricator: https://reviews.llvm.org/D32824

I agree; AFAICS [func.bind.bind] is clear on this: the type of the Func
object used to call the member operator() is non-const.

On 5/4/2017 9:09 PM, rs2740 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80564
>
> TC  changed:
>
>What|Removed |Added
> 
>  CC||rs2740 at gmail dot com
>
> --- Comment #4 from TC  ---
> (In reply to Eric Fiselier from comment #3)
>> Here is an example of why `_Bind::operator()(...) const` must be considered
>> during overload resolution even if the call wrapper itself is not const.
>>
>> --
>> #include 
>>
>> struct Func {
>>   template 
>>   void operator()(Args&&...) = delete;
>>
>>   template 
>>   void operator()(Args&&...) const {}
>> };
>>
>> int main() {
>> Func f;
>> std::bind(f)();
>> }
>> -
> Interesting, libstdc++ rejects this as an attempt to call a deleted function.
> That seems more correct than libc++'s approach which calls the const overload.
>

[Bug c/80632] New: error: invalid PHI argument with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 80632
   Summary: error: invalid PHI argument with -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached code does this with today's gcc trunk and flag -O2:

$ /home/dcb/gcc/results/bin/gcc   -c   -w -O2 /tmp/q.i
xlock.c: In function ‘monitor_powered_on_p’:
xlock.c:4059:1: error: invalid PHI argument
 }
 ^
.MEM
xlock.c:4059:1: error: invalid PHI argument
.MEM
.MEM_7 = PHI <.MEM_11(2), .MEM_12(3), .MEM_13(4), .MEM(11), .MEM(10)>
xlock.c:4059:1: internal compiler error: verify_gimple failed
0xc860d2 verify_gimple_in_cfg(function*, bool)
../../trunk/gcc/tree-cfg.c:5266
0xb12976 execute_function_todo
../../trunk/gcc/passes.c:1968
0xb14f61 do_per_function
../../trunk/gcc/passes.c:1652

[Bug c/80631] [6/7/8 Regression] Compiling with -O3 -mavx2 gives wrong code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-04
 CC||alan.hayward at arm dot com,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|Compiling with -O3 -mavx2   |[6/7/8 Regression]
   |gives wrong code|Compiling with -O3 -mavx2
   ||gives wrong code
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r230297.
Note, in C
  const int N = 8;
  int v[N];
is a variable length array, so unnecessarily pessimizing, you need to use
#define N 8
or
  enum { N = 8 };
or something similar instead for it to be a non-VLA.  In C++ it is not a VLA.
But fixing that doesn't help here.

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Eric Fiselier from comment #3)
> Here is an example of why `_Bind::operator()(...) const` must be considered
> during overload resolution even if the call wrapper itself is not const.
> 
> --
> #include 
> 
> struct Func {
>   template 
>   void operator()(Args&&...) = delete;
> 
>   template 
>   void operator()(Args&&...) const {}
> };
> 
> int main() {
> Func f;
> std::bind(f)();
> }
> -

Interesting, libstdc++ rejects this as an attempt to call a deleted function.
That seems more correct than libc++'s approach which calls the const overload.

[Bug c/80631] New: Compiling with -O3 -mavx2 gives wrong code

[elias.rudberg at it dot uu.se]

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

Bug ID: 80631
   Summary: Compiling with -O3 -mavx2 gives wrong code
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elias.rudberg at it dot uu.se
  Target Milestone: ---

Created attachment 41319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41319=edit
Preprocessed source generated by gcc -v -save-temps -O3 -mavx2 thecode.c

I ran into a problem with strange results when compiling with -O3 -mavx2 and
have been able to reduce it to the following small test code:

#include 
int main() {
  const int N = 8;
  int v[N];
  for(int k = 0; k < N; k++)
v[k] = k;
  v[0] = 77;
  int found_index = -1;
  for(int k = 0; k < N; k++) {
if(v[k] == 77)
  found_index = k;
  }
  printf("found_index = %d\n", found_index);
}


If compiled correctly, running this code should give "found_index = 0".

When compiling it like this:
gcc -O3 -mavx2 thecode.c

then running the resulting a.out executable gives:
$ ./a.out
found_index = -1

which is wrong.

The output of "gcc -v -save-temps -O3 -mavx2 thecode.c" looks as follows:

$ gcc -v -save-temps -O3 -mavx2 thecode.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx2' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/6.3.1/cc1 -E -quiet -v thecode.c -mavx2
-mtune=generic -march=x86-64 -O3 -fpch-preprocess -o thecode.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.3.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx2' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/6.3.1/cc1 -fpreprocessed thecode.i -quiet
-dumpbase thecode.c -mavx2 -mtune=generic -march=x86-64 -auxbase thecode -O3
-version -o thecode.s
GNU C11 (GCC) version 6.3.1 20161221 (Red Hat 6.3.1-1) (x86_64-redhat-linux)
compiled by GNU C version 6.3.1 20161221 (Red Hat 6.3.1-1), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.2, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.3.1 20161221 (Red Hat 6.3.1-1) (x86_64-redhat-linux)
compiled by GNU C version 6.3.1 20161221 (Red Hat 6.3.1-1), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.2, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 67626b9d441eed376539391e660a9413
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx2' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o thecode.o thecode.s
GNU assembler version 2.26.1 (x86_64-redhat-linux) using BFD version version
2.26.1-1.fc25
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/:/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/6.3.1/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/6.3.1/:/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx2' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/6.3.1/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
-plugin-opt=-fresolution=thecode.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu 

[Bug target/80627] The Dart is crashing when glibc is compiled with arch armv7-a

[tomas_paukrt at conel dot cz]

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

--- Comment #4 from tomas_paukrt at conel dot cz ---
I wanted to trace this issue down to the root cause, but the Dart is quite
large project and I realy do not have time to isolate the code that triggers
this bug and fix it myself, so I just asked for help.

The core dump is quite useless as you can see:

Core was generated by `/bin/dart bin/run.dart'.
Program terminated with signal 6, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

I understand that you do not have such much time too, so lets close this case.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #16 from Jerry DeLisle  ---
Fixed on 7.1.1 and closing

[Bug fortran/80484] Three syntax errors involving derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu May  4 18:45:50 2017
New Revision: 247615

URL: https://gcc.gnu.org/viewcvs?rev=247615=gcc=rev
Log:
2017-05-04  Jerry DeLisle  

Backport from trunk.
PR fortran/80484
* io.c (format_lex): Check for '/' and set token to FMT_SLASH.
(check_format): Move FMT_DT checking code to data_desc section.
* module.c (gfc_match_use): Include the case of INTERFACE_DTIO.
Backport from mainline
PR fortran/80484
* gfortran.dg/dtio_29.f03: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dtio_29.f03
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/io.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to coypu from comment #8)
> Created attachment 41317 [details]
> Unbreak NetBSD following r243219
> 
> This patch works for me.

This may break Linux.  You may want to investigate if this approach:

commit 6e6c7fc1e15525a10f48d4f5ac2edd853e2f5cb7
Author: nsz 
Date:   Fri Nov 11 17:31:07 2016 +

[i386][musl] Add cpuinfo to static libgcc only on *-musl*

The __cpu_indicator_init and __cpu_model symbols are not safe to use
from shared libgcc_s.so from ifunc resolvers, so since gcc-6, only
the definitions from static libgcc.a are used, however the symbols
are kept in libgcc_s as well for backward compatibility (with
appropriate symbol version).  On targets without such backward
compatibility concern add cpuinfo to the static library only (this
avoids running the ctor, reduces libgcc_s size and elf abi concerns
about the versioned symbols).

works for you.

[Bug c++/80630] gcc fails to compile constexpr with -O0/-O1

[vsevolod.livinskij at frtk dot ru]

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

Vsevolod Livinskiy  changed:

   What|Removed |Added

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

--- Comment #1 from Vsevolod Livinskiy  ---
Missed out-of-line definition for A::debug_typeid:

constexpr uint32_t A::debug_typeid;

[Bug c++/80630] New: gcc fails to compile constexpr with -O0/-O1

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 80630
   Summary: gcc fails to compile constexpr with -O0/-O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Created attachment 41318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41318=edit
Reproducer.

gcc fails to compile constexpr at -O0 and -O2 with -std=c++11 and -std=c++14.
Everything works fine with -std=c++17.

Reproducer:
>$ cat repr.cpp 
#include 
#include 

template
void foo() {
std::cout << T::debug_typeid << std::endl;
std::make_pair(T::debug_typeid, T::debug_typeid);
}

struct A {
static constexpr uint32_t debug_typeid = 1;
}; 

int main () {
foo();
}

Error:
>$ g++ -std=c++11 repr.cpp -O0 ; ./a.out
/tmp/cckPqG1z.o: In function `void foo()':
repr.cpp:(.text._Z3fooI1AEvv[_Z3fooI1AEvv]+0x21): undefined reference to
`A::debug_typeid'
repr.cpp:(.text._Z3fooI1AEvv[_Z3fooI1AEvv]+0x26): undefined reference to
`A::debug_typeid'
collect2: error: ld returned 1 exit status

GCC revision:247564

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

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

--- Comment #8 from coypu  ---
Created attachment 41317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41317=edit
Unbreak NetBSD following r243219

This patch works for me.

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu May  4 17:40:05 2017
New Revision: 247607

URL: https://gcc.gnu.org/viewcvs?rev=247607=gcc=rev
Log:
PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/c-family/ChangeLog:

PR translation/80280
* c-attribs.c (handle_alias_ifunc_attribute): Quote a %D directive.
(handle_weakref_attribute): Same.

PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/ChangeLog:

PR translation/80280
* config/i386/i386.c (ix86_function_versions): Quote a %D directive.

PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/cp/ChangeLog:

PR translation/80280
* call.c (print_z_candidate): Add missing quoting to %D and other
like directives.
(build_op_call_1): Same.
* constraint.cc (diagnose_check_constraint): Same.
* mangle.c (mangle_decl): Same.
* name-lookup.c (cp_binding_level_debug): Same.
(set_decl_namespace): Same.
* parser.c (cp_parser_tx_qualifier_opt): Same.
* pt.c (print_candidates_1): Same.
(check_template_variable): Same.
(tsubst_default_argument): Same.
(most_specialized_partial_spec): Same.
* semantics.c (omp_reduction_lookup): Same.
* tree.c (check_abi_tag_redeclaration): Same.
* typeck.c (comptypes): Same.
* typeck2.c (abstract_virtuals_error_sfinae): Same.

PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/ChangeLog:

PR translation/80280
* builtins.c (expand_builtin_object_size): Add missing quoting to
%D and like directives.
* hsa-gen.c (hsa_type_for_scalar_tree_type): Same.
(hsa_type_for_tree_type): Same.
(verify_function_arguments): Same.
* symtab.c (symbol_table::change_decl_assembler_name): Same.
* varasm.c (get_section): Same.
(mark_weak): Same.

PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/objc/ChangeLog:

PR translation/80280
* objc-gnu-runtime-abi-01.c (objc_eh_runtime_type): Add missing
quoting to directives.
* objc-next-runtime-abi-01.c (objc_eh_runtime_type): Ditto.
* objc-next-runtime-abi-02.c (next_runtime_02_eh_type): Ditto.

PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/testsuite/ChangeLog:

PR translation/80280
* g++.dg/abi/Wabi-2-3.C: Adjust.
* g++.dg/abi/Wabi-3-2.C: Ditto.
* g++.dg/lookup/using17.C: Ditto.
* gcc.dg/format/gcc_diag-1.c (foo): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/config/i386/i386.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/constraint.cc
trunk/gcc/cp/mangle.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/hsa-gen.c
trunk/gcc/objc/ChangeLog
trunk/gcc/objc/objc-gnu-runtime-abi-01.c
trunk/gcc/objc/objc-next-runtime-abi-01.c
trunk/gcc/objc/objc-next-runtime-abi-02.c
trunk/gcc/symtab.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/abi/Wabi-2-3.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-3-2.C
trunk/gcc/testsuite/g++.dg/lookup/using17.C
trunk/gcc/testsuite/gcc.dg/format/gcc_diag-1.c
trunk/gcc/varasm.c

[Bug target/80627] The Dart is crashing when glibc is compiled with arch armv7-a

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
You obviously haven't read the page I just pointed you to.  See explicitly the
section "what we do not want".

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #15 from Vincent  ---
Still there in 7.1.0.

[Bug target/80627] The Dart is crashing when glibc is compiled with arch armv7-a

[tomas_paukrt at conel dot cz]

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

tomas_paukrt at conel dot cz changed:

   What|Removed |Added

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

--- Comment #2 from tomas_paukrt at conel dot cz ---
The GCC, binutils and glibc were compiled using our toolchain builder
(https://bitbucket.org/bbsmartworx/tcbuilder), so you can find all information
about versions, options, etc. there.

The Dart SDK was built using instructions from here:
https://github.com/dart-lang/sdk/wiki/Building-Dart-SDK-for-ARM-processors. I
can provide final binary if you want to, but it is quite large.

This issue can be reproduced easily by executing the "dart" binary several
times.

I have tested it on embedded system with AM3352 CPU.

[Bug target/80627] The Dart is crashing when glibc is compiled with arch armv7-a

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug target/80627] The Dart is crashing when glibc is compiled with arch armv7-a

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  ---
This is not a usable bug report.  We cannot provide a debugging service for
you, so you are going to have to narrow the problem down to something usable. 
See https://gcc.gnu.org/bugs/ for details of the information we would need.

[Bug tree-optimization/80622] [8 Regression] wrong code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Thu May  4 16:19:20 2017
New Revision: 247604

URL: https://gcc.gnu.org/viewcvs?rev=247604=gcc=rev
Log:
[PR 80622] Treat const pools as initialized in SRA

2017-05-04  Martin Jambor  

PR tree-optimization/80622
* tree-sra.c (comes_initialized_p): New function.
(build_accesses_from_assign): Only set write lazily when
comes_initialized_p is false.
(analyze_access_subtree): Use comes_initialized_p.
(propagate_subaccesses_across_link): Assert !comes_initialized_p
instead of testing for PARM_DECL.

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


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80622.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[herring at lanl dot gov]

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

--- Comment #7 from S. Davis Herring  ---
We can extend the C test case (thanks for that) with a shared, non-constant
value (and more savings by having dead code as in the original C++ example):

void foo(int *p,int *q,int x) {
  *q=*p=x;
  if(*p!=x) abort();  /* dead */
}

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
OK, will do (probably next week after things hopefully unstack a bit).  Thanks!

[Bug fortran/70071] ICE on wrong usage of a subscript triplet

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #3)

The patch in comment #3 regtests cleanly on i686-pc-linux-gnu
and has been posted here:

https://gcc.gnu.org/ml/fortran/2017-05/msg00010.html
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00312.html

Whoever wants to take it and adapt to 8-trunk, 7-release (?).

[Bug tree-optimization/80622] [8 Regression] wrong code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
(In reply to Martin Jambor from comment #6)
> The simplest fix is the following, but I'll move the whole test a bit
> earlier in a patch to the mailing list:

Which is now posted at
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00306.html

[Bug tree-optimization/80574] GCC fail to optimize nested ternary

[SztfG at yandex dot ru]

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

SztfG at yandex dot ru changed:

   What|Removed |Added

 CC||SztfG at yandex dot ru

--- Comment #6 from SztfG at yandex dot ru ---
Created attachment 41316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41316=edit
some benchmark with macro stuff and std::max

Well, maybe this is also not related to this issue, but here is some benchmark,
and std::max is slower than macro

[Bug c++/80587] Incorrect type from outer scope inside lambda under some conditions

[jas...@3db-labs.com]

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

--- Comment #1 from jas...@3db-labs.com ---
I neglected to include the preprocessed source file. It is too large to attach
here, so I posted it at:

https://gist.github.com/otherjason/9f50d3f36207ea4b40bb805f6c710304

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

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Yup, you were right.

Compiling with r247543:

seurer@genoa:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o
./pr50310-2.exe


And adding  --param vect-max-peeling-for-alignment=0

seurer@genoa:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o
./pr50310-2.exe --param vect-max-peeling-for-alignment=0
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c: In function 'main':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c:47:1: error:
unrecognizable insn:
(insn 361 360 176 2 (set (reg:V2DF 342)
(not:V2DF (ior:V2DF (reg:V2DF 470)
(reg:V2DF 471
"/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c":30 -1
 (nil))
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr50310-2.c:47:1: internal
compiler error: in extract_insn, at recog.c:2311
0x108ab353 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:108
0x108ab3b7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:116
0x108701d7 extract_insn(rtx_insn*)
/home/seurer/gcc/gcc-test/gcc/recog.c:2311
0x1120fe63 decompose_multiword_subregs
/home/seurer/gcc/gcc-test/gcc/lower-subreg.c:1467
0x1121150b execute
/home/seurer/gcc/gcc-test/gcc/lower-subreg.c:1734
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/80620] [8 Regression] gcc produces wrong code with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Now needs sth before r247596 to reproduce.

The whole

PRE_EXPR_NARY (expr) = newnary;
constant = fully_constant_expression (expr);
PRE_EXPR_NARY (expr) = nary;
if (constant != expr)
  {
/* For non-CONSTANTs we have to make sure we can eventually
   insert the expression.  Which means we need to have a
   leader for it.  */
if (constant->kind != CONSTANT)
  {
/* Do not allow simplifications to non-constants over
   backedges as this will likely result in a loop PHI node
   to be inserted and increased register pressure.
   See PR77498 - this avoids doing predcoms work in
   a less efficient way.  */
if (find_edge (pred, phiblock)->flags & EDGE_DFS_BACK)
  ;
else
  {
unsigned value_id = get_expr_value_id (constant);
constant = find_leader_in_sets (value_id, set1, set2,
AVAIL_OUT (pred));
if (constant)
  return constant;

mitigates the fact that

tree result = vn_nary_op_lookup_pieces (newnary->length,
newnary->opcode,
newnary->type,
>op[0],
);
if (result && is_gimple_min_invariant (result))
  return get_or_alloc_expr_for_constant (result);

doesn't allow SSA name result to prevail here.  That is vn_nary_simplify
also just looks up the expr now even if not simplified.  It also gets
fed leaders which are not necessarily final values and thus do not have
range-info cleared.

The SCCVN band-aid to clear SSA_NAME_RANGE_INFO doesn't apply here because
nothing is value-numbered to a.4_4 besides itself.  But phi-translation
effectively value-numbers an expression to it.

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[anlauf at gmx dot de]

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

--- Comment #12 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #11)
> While reducing PR 78290, I found another example giving a similar traceback:
> 
> % gfc-trunk gfcbug136.f90
[...]

While checking the status of the example in comment #11,
I found it does no longer crash with the 7-release.

However, the testcases in the previous comments still fail.

[Bug fortran/80554] [f08] variable redefinition in submodule

[tamas.bela.feher at ipp dot mpg.de]

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

--- Comment #3 from Tamas Bela Feher  ---
Dear Dominique,

Thank you for looking into the problem.

> Why do you want to use such constructs?
I was refactoring and splitting large modules into submodules when I
accidentally run into this problems. I could get around by simply
renaming the variables. I also agree with you, that using such
constructs is asking for trouble.

The main question is whether the standard forbids this construct or not.
If it does not, then the compiler should not give any error message. A
warning could be given if you really deem it dangerous.

> How do you parse [...] ?
If I understood correctly, section 16.3.1 establishes that
variable i belongs to class (1) of local identifiers, and such
identifiers shall not be the same as a global identifier.

Further in section 16.3.1 we can find that

"Within its scope, a local identifier of one class shall not be the same
as another local identifier of the same class."

None of these restrictions apply. The submodule (as a program unit)
should be considered as a separate scoping unit:

"1.3.124 scoping unit
BLOCK construct, derived-type definition, interface body, program unit,
subprogram, excluding all nested scoping units in it"

"Note 2.4
A submodule has access to entities in its parent module or submodule by
host association."

I did not find any specific restrictions for host association in case of
submodules, therefore I would use the general rule:

"16.5.1.4 Host association
[...]
A name that appears in the scoping unit as
[...]
(2) an object-name in an entity-decl [...]
is a local identifier in the scoping unit and any entity of the host
that has this as its nongeneric name is inaccessible by that name by
host association."

Considering all the above, I would interpret the attached code (repeated here)
the following way:

1 module M
2   implicit none
3   integer :: i = 0
4   interface
5 module subroutine write_i()
6 end subroutine
7   end interface
8 end module
9 
10 submodule (M) S
11   integer :: i = 137
12   contains
13 module subroutine write_i()
14write (*,*) i
15 end subroutine
16 end submodule

Line 3 declares local variable i in the scoping unit of module M.
Line 11 declares a local variable with the same name in the scoping unit of
submodule S (which is separate from the scoping unit of M).
The variable i in line 14 refers to the local variable from the scoping unit of
S. The program is correct, the error message that GFortran gives is incorrect.

I have also tried a recent version of IBM's XL-Fortran compiler (15.1.5) and it
compiles the code without any error message.

[Bug debug/80629] Missing .loc for a function in the presence of -O2

[matt at godbolt dot org]

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

--- Comment #1 from Matt Godbolt  ---
This bug is noticeable in Compiler Explorer: https://godbolt.org/g/scFj7A for
example; the function is not colourised as CE uses the .locs to track how the
source lines map to asm. One can also see how the bug has changed between
compiler revisions, in the 5.x and 6.x series it was the first function that
suffered the loc loss, and in 4.9.4 there's no such issue. (the older compilers
need the addition of the -std=c++0x flag)

[Bug debug/80629] New: Missing .loc for a function in the presence of -O2

[matt at godbolt dot org]

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

Bug ID: 80629
   Summary: Missing .loc for a function in the presence of -O2
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

Firstly; I appreciate how tricky it is to keep track of debug information in
the presence of optimization and inlining, but I wonder if there's something
specific happening in this case. This is filed against 7.1, but previous
versions had slightly different, but similar issues.

In the following code snippet:

---cut---
#include 

int callByValue(std::unique_ptr a) { return *a; }  // comment me out - see
below
int callByRef(std::unique_ptr && a) { return *a; }

int callItByRef(std::unique_ptr a) {
  return callByRef(std::move(a));
}
---cut---

Compiled and output thus:
  g++ foo.cc -O2 -S -o - -g | c++filt | head -50

One can see that the final function "callItByRef" doesn't have a `.loc`
anywhere in it to tie it to the source.

At -O1 the locations are output correctly.

Interestingly, commenting out the (unused) callByValue function causes the
callItByRef to gain debug information, which makes me wonder if there's a bug
here rather than a difficulty in tracking debug information per se.

[Bug debug/80628] New: gcc 7.1.0 produces duplicate entries in .debug_gnu_pubtypes table

[georgerim at gmail dot com]

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

Bug ID: 80628
   Summary: gcc 7.1.0 produces duplicate entries in
.debug_gnu_pubtypes table
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georgerim at gmail dot com
  Target Milestone: ---

Created attachment 41315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41315=edit
sample object

I found this when builded LLVM llc binary using gcc 5.4.1 and -ggnu-pubnames
-gsplit-dwarf.
And also checked that latest available released version 7.1.0 is also affected.

gcc produces duplicate entries in .debug_gnu_pubtypes section, ex:
UnifyFunctionExitNodes.cpp.o has:
0xac07 EXTERNAL TYPE "std::success_type"
0xac07 EXTERNAL TYPE "std::success_type"

clang produces single entry for the same:
0xd291 EXTERNAL TYPE "std::__success_type"

This entries can be used by linker to produce .gdb_index section. 
And gold currently filters such duplicates out.
Though it still looks useless and excessive to have them in output.

Object file produces by gcc 7.1.0 is attached.
Below is a demonstration of duplication.

>> strings -a UnifyFunctionExitNodes.cpp.o |grep "GCC: ("
GCC: (GNU) 7.1.0
>> objdump UnifyFunctionExitNodes.cpp.o --dwarf=pubtypes
Contents of the .debug_gnu_pubtypes section:
...
1ea15   g,typellvm::InsertValueInst
1ea15   g,typellvm::InsertValueInst
1e47f   g,typellvm::SelectInst
1e47f   g,typellvm::SelectInst
1de70   g,typellvm::FuncletPadInst
1de70   g,typellvm::FuncletPadInst
151bc   g,typellvm::PassRegistrationListener
151bc   g,typellvm::PassRegistrationListener

[Bug tree-optimization/80625] gcc fails to notice strdup does not modify it's argument

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Ah indeed, sorry for the noise.

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
C testcase:

int foo (int *p, int *q)
{
  *p = 1;
  *q = 1;
  return *p;
}

[Bug tree-optimization/80622] [8 Regression] wrong code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
The simplest fix is the following, but I'll move the whole test a bit
earlier in a patch to the mailing list:

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 1606573aead..79ca1666c15 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2581,8 +2581,10 @@ propagate_subaccesses_across_link (struct access *lacc,
struct access *racc)

   /* IF the LHS is still not marked as being written to, we only need to do so
  if the RHS at this level actually was.  */
-  if (!lacc->grp_write &&
-  (racc->grp_write || TREE_CODE (racc->base) == PARM_DECL))
+  if (!lacc->grp_write
+  && (racc->grp_write
+ || TREE_CODE (racc->base) == PARM_DECL
+ || constant_decl_p (racc->base)))
 {
   lacc->grp_write = true;
   ret = true;

[Bug ada/80626] Ada x32 multilib build failure for a-cfinve.ads

[steven at uplinklabs dot net]

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

--- Comment #2 from Steven Noonan  ---
It looks like this is just the first of several files with that build issue. If
I build with 'make -k' I see several others fail with the same warning, e.g.:

/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  g-allein.ads -o
g-allein.o
g-allein.ads:183:04: warning: types for unchecked conversion have different
sizes
g-allein.ads:185:04: warning: types for unchecked conversion have different
sizes
g-allein.ads:187:04: warning: types for unchecked conversion have different
sizes
g-allein.ads:189:04: warning: types for unchecked conversion have different
sizes
g-allein.ads:191:04: warning: types for unchecked conversion have different
sizes
[... many more in the same file ...]

/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  s-wwdenu.adb -o
s-wwdenu.o
s-wwdenu.adb:55:07: warning: types for unchecked conversion have different
sizes
s-wwdenu.adb:94:07: warning: types for unchecked conversion have different
sizes
s-wwdenu.adb:133:07: warning: types for unchecked conversion have different
sizes
s-wwdenu.adb:172:07: warning: types for unchecked conversion have different
sizes
s-wwdenu.adb:211:07: warning: types for unchecked conversion have different
sizes
s-wwdenu.adb:250:07: warning: types for unchecked conversion have different
sizes


And several files fail with a different warning:

/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  a-dispat.adb -o
a-dispat.o
s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64
make[9]: *** [../gcc-interface/Makefile:296: a-dispat.o] Error 1
/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  a-dynpri.adb -o
a-dynpri.o
s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64
make[9]: *** [../gcc-interface/Makefile:296: a-dynpri.o] Error 1
/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  a-interr.adb -o
a-interr.o
s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64
make[9]: *** [../gcc-interface/Makefile:296: a-interr.o] Error 1

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Richard Biener  ---
So we end up with

void disassemble_me(A&, A&) (struct A & a, struct A & b)
{
  void * __old_val;
  void * __old_val;
  void * _7;
  void * _8;

   [100.00%]:
  __old_val_5 = MEM[(void * &)a_2(D)];
  MEM[(void * &)a_2(D)] = 0B;
  __old_val_6 = MEM[(void * &)b_3(D)];
  MEM[(void * &)b_3(D)] = 0B;
  _7 = MEM[(void * &)a_2(D)];
  MEM[(void * &)a_2(D)] = __old_val_6;
  if (_7 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

   [53.47%]:
  free (_7);
...

which shows this issue.  I believe there's a duplicate PR for this somewhere...
(I even remember writing a patch for this).

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
  MEM[(void * &)a_2(D)] = 0B;
  MEM[(void * &)b_3(D)] = 0B;
  _7 = MEM[(void * &)a_2(D)];

Indeed.

[Bug tree-optimization/80625] gcc fails to notice strdup does not modify it's argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Is handled fine.

[Bug tree-optimization/80625] gcc fails to notice strdup does not modify it's argument

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
s might be a global variable, that foo modifies.

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[herring at lanl dot gov]

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

--- Comment #3 from S. Davis Herring  ---
Created attachment 41314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41314=edit
bad assembly test case

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[herring at lanl dot gov]

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

--- Comment #2 from S. Davis Herring  ---
So sorry.  For whatever reason, copy/paste works for me thence...

#include
#include
#include

struct A {  // vaguely unique_ptr-like
  void *p;
  A(A &) : p(a.release()) {}
  ~A() {if(p) std::free(p);}// not that you can't free(nullptr)
  void* release() {return std::exchange(p,nullptr);}
  void swap(A ) {std::swap(p,a.p);}
  A& operator=(A &) {A(std::move(a)).swap(*this); return *this;}
};

void disassemble_me(A ,A ) {std::swap(a,b);}

int main() {
  return !!execlp("cat","cat","prog.s",static_cast(0));
}

[Bug target/80627] New: The Dart is crashing when glibc is compiled with arch armv7-a

[tomas_paukrt at conel dot cz]

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

Bug ID: 80627
   Summary: The Dart is crashing when glibc is compiled with arch
armv7-a
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas_paukrt at conel dot cz
  Target Milestone: ---

I have found out that the Dart (https://www.dartlang.org/) is occasionally
crashing when glibc 2.25 is cross-compiled with options "--with-arch=armv7-a
--with-tune=cortex-a8 --with-fpu=vfpv3 --with-float=softfp". I have tested GCC
4.9.4, 5.4.0, 6.3.0 and 7.1.0 and all these versions produced "libc.so.6" that
does not work with the Dart. When I change option "with-arch" to "armv6" then
cross-compiled "libc.so.6" works with the Dart.


This is output of the Dart when running on system with "libc.so.6" compiled for
arch "armv7-a":

Dumping native stack trace for thread 530
  [0x008cf920] Unknown symbol
  [0x008cf920] Unknown symbol
-- End of DumpStackTrace
Aborted

[Bug ada/80626] Ada x32 multilib build failure for a-cfinve.ads

[steven at uplinklabs dot net]

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

--- Comment #1 from Steven Noonan  ---
I configured with these flags, if they're needed for repro:

--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://www.uplinklabs.net/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--enable-gnu-indirect-function --enable-gnu-unique-object
--enable-install-libiberty --enable-libmpx --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-isl --with-linker-hash-style=gnu
--with-multilib-list=m32,m64,mx32 --with-system-zlib

[Bug ada/80626] New: Ada x32 multilib build failure for a-cfinve.ads

[steven at uplinklabs dot net]

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

Bug ID: 80626
   Summary: Ada x32 multilib build failure for a-cfinve.ads
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
  Target Milestone: ---

I'm sure this would be trivial to fix if I knew any Ada at all, but I've run
into this build failure for GCC 7.1.0 when built with
--with-multilib=m32,m64,mx32 for x86_64.

make[9]: Entering directory
'/home/steven/gcc-multilib/src/gcc-build/gcc/ada/rts_x32'
[...]
/home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc
-B/home/steven/gcc-multilib/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
  -c -g -O2 -mx32 -fpic  -W -Wall -gnatpg -nostdinc -mx32  a-cfinve.adb -o
a-cfinve.o
a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55
a-cfinve.ads:245:04: warning: types for unchecked conversion have different
sizes
make[9]: *** [../gcc-interface/Makefile:296: a-cfinve.o] Error 1

Any ideas?

[Bug tree-optimization/80625] New: gcc fails to notice strdup does not modify it's argument

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 80625
   Summary: gcc fails to notice strdup does not modify it's
argument
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
While working on PR80613, I came up with following test-case:

int f(char *s)
{
  void foo(char *);

  *s = 'a';
  char *p = __builtin_strdup (s);
  foo (p);
  return *s;
}

I assume return *s could be safely replaced by return 97 since strdup will
not modify s ? Or am I mistaken ?

Thanks,
Prathamesh

[Bug c++/80613] [8 Regression] ICE in is_gimple_reg_type with -O2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 41313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41313=edit
untested fix

Hi,
The issue can be reproduced with following test-case:

char f(void)
{
  char *a();
  void bar(char *);

  char d = *a();
  char *p = __builtin_strdup ();
  __builtin_free (p);
  bar ();
}

cddce1 marks the call to __builtin_strdup as necessary:
marking necessary through .MEM_6 stmt p_7 = __builtin_strdup ();

and since p_7 doesn't get added to worklist in propagate_necessity
because it's used only within free(), it's treated as "dead"
and wrongly gets released.
The patch fixes that by adding strdup/strndup in corresponding condition
in eliminate_unnecessary_stmts.

I am not sure though why call to strdup is marked necessary.
I suppose it's safe to remove calls to strdup and free in above case since
strdup won't modify d ?

Another issue I found was that my patch failed to remove multiple calls to
strdup:
char *f(char **tt)
{
  char *t = *tt;
  char *p;

  p = __builtin_strdup (t);
  p = __builtin_strdup (t);
  return p;
}

That's fixed in patch by adding strdup/strndup to another corresponding
condition in propagate_necessity
so that only one instance of strdup would be kept.

Validation in progress, will post it to the list if it passes.

Thanks,
Prathamesh

[Bug libstdc++/80624] char_traits::eof() doesn't meet requirements

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/80624] New: char_traits::eof() doesn't meet requirements

[redi at gcc dot gnu.org]

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

Bug ID: 80624
   Summary: char_traits::eof() doesn't meet requirements
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

using u16_traits = std::char_traits;
constexpr u16_traits::char_type c = u'\u';
constexpr u16_traits::int_type e = u16_traits::eof();
static_assert( u16_traits::eq_int_type(e, c) == false, "eof() is correct" );


[char.traits.require] says eof() return "a value e such that
X::eq_int_type(e,X::to_int_type(c)) is false for all values c."

Despite being a noncharacter, u'\u' is a valid code point, see
http://www.unicode.org/faq/private_use.html#nonchar7 and
http://www.unicode.org/faq/private_use.html#nonchar8

This means there's no way to tell if std::ostream::put(u'\u') is
successful, because it returns to_int_type(u'\u') on success and returns
eof() on failure, which compares equal.

This might be fixable by making to_int_type(eof()) return u'\uFFFD' as
suggested by the FAQ linked to above.

[Bug c++/80614] [7/8 Regression] Bad mangling for noexcept abominable function types

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Marek Polacek from comment #2)
> Bisection points to r241958 but that is nonsense, so I suspect r241944.

Yes that would have been my guess.

[Bug c++/80614] [7/8 Regression] Bad mangling for noexcept abominable function types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Bisection points to r241958 but that is nonsense, so I suspect r241944.

[Bug tree-optimization/80612] [7 Regression] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |get_range_info, at  |get_range_info, at
   |tree-ssanames.c:375 |tree-ssanames.c:375

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

[Bug tree-optimization/80612] [7/8 Regression] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu May  4 10:35:58 2017
New Revision: 247586

URL: https://gcc.gnu.org/viewcvs?rev=247586=gcc=rev
Log:
PR tree-optimization/80612
* calls.c (get_size_range): Check for INTEGRAL_TYPE_P.

* gcc.dg/torture/pr80612.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80612.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69460] ARM Cortex M0 produces suboptimal code vs Cortex M3

[strntydog at gmail dot com]

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

--- Comment #6 from strntydog at gmail dot com ---
I have built GCC 7.1.0 and have tested this optimization bug against that.  It
persists.  Further, the new target cortx-m23 is affected by the bug, exactly
the same as Cortex M0/M0+ and M1

The new cortex-m33 target behaves the same as the cortex-m3, in that it
produces legal code for the cortex-m23/m0/m0+/m1 but it is much better
optimised.

[Bug tree-optimization/80622] [8 Regression] wrong code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Mine.

[Bug tree-optimization/80620] [8 Regression] gcc produces wrong code with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ugh.  This is really another latent issue with PRE and range-info.  When
PHI-translating {bit_and_expr,a.12_17,4081116982543369} when valueizing
a.12_17 we end up with a leader for a.12_17 as {nop_expr,a.6_10} (as this is
in antic-in).  We then translate that as {nop_expr,a.0_1} for which we have
a.4_4 as "representative" -- but this has range-info that isn't valid in
the context we are looking at, when we the simplify using match.pd we use
that range-info and BOOM!.

The rev. in question just made this more likely to trigger (previously
only match.pd simplifications to constants were considered).

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
106 testcases remaining.

[ Or 94, if we ignore i386/avx-* (see PR80606). ]

[Bug testsuite/80611] [8 regression] test case gfortran.dg/coarray_lock_7.f90 fails starting with r247495

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-04
 CC||burnus at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yeah, this testcase is really weird as it completely lacks a comment what we
are supposed to look for.

CCing coarray authors to update (and sanity check the new IL).

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Author: vries
Date: Thu May  4 07:55:11 2017
New Revision: 247580

URL: https://gcc.gnu.org/viewcvs?rev=247580=gcc=rev
Log:
Replace absolute line numbers in g++.dg/warn

2017-05-04  Tom de Vries  

PR testsuite/80557
* g++.dg/warn/Wstrict-aliasing-float-ref-int-obj.C: Replace absolute
line numbers.
* g++.dg/warn/miss-format-1.C: Same.
* g++.dg/warn/overflow-warn-1.C: Same.
* g++.dg/warn/overflow-warn-3.C: Same.
* g++.dg/warn/overflow-warn-4.C: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-float-ref-int-obj.C
trunk/gcc/testsuite/g++.dg/warn/miss-format-1.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-1.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-3.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-4.C

[Bug c++/80613] [8 Regression] ICE in is_gimple_reg_type with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Hmm, cddce leaves us with free (_11) and the def of _11 removed.  _11 was

Deleting LHS of call: _11 = strdup ();

so caused by

2017-04-29  Prathamesh Kulkarni  

PR tree-optimization/79697
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Check if callee
is BUILT_IN_STRDUP, BUILT_IN_STRNDUP, BUILT_IN_REALLOC.
(propagate_necessity): Check if def_callee is BUILT_IN_STRDUP or
BUILT_IN_STRNDUP.
* gimple-fold.c (gimple_fold_builtin_realloc): New function.
(gimple_fold_builtin): Call gimple_fold_builtin_realloc.

which failed to update BUILT_IN_FREE handling properly.

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Author: vries
Date: Thu May  4 07:54:59 2017
New Revision: 247579

URL: https://gcc.gnu.org/viewcvs?rev=247579=gcc=rev
Log:
Replace absolute line numbers in gcc.target/i386

2017-05-04  Tom de Vries  

PR testsuite/80557
* gcc.target/i386/pr57655.c: Replace absolute line numbers.
* gcc.target/i386/pr68657.c: Same.
* gcc.target/i386/pr69255-1.c: Same.
* gcc.target/i386/pr69255-2.c: Same.
* gcc.target/i386/pr69255-3.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr57655.c
trunk/gcc/testsuite/gcc.target/i386/pr68657.c
trunk/gcc/testsuite/gcc.target/i386/pr69255-1.c
trunk/gcc/testsuite/gcc.target/i386/pr69255-2.c
trunk/gcc/testsuite/gcc.target/i386/pr69255-3.c

[Bug c++/80613] [8 Regression] ICE in is_gimple_reg_type with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug tree-optimization/80622] [8 Regression] wrong code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
I can confirm that r247497 is first problematic revision.

[Bug c++/80613] [8 Regression] ICE in is_gimple_reg_type with -O2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Sorry for the breakage, I will take a look.

Regards,
Prathamesh

[Bug c++/80613] [8 Regression] ICE in is_gimple_reg_type with -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|8ice in is_gimple_reg_type  |[8 Regression] ICE in
   |with -O2|is_gimple_reg_type with -O2

--- Comment #4 from Martin Liška  ---
Confirmed, started with r247407.

[Bug c++/80613] 8ice in is_gimple_reg_type with -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-04
 CC||marxin at gcc dot gnu.org,
   ||prathamesh3492 at gcc dot 
gnu.org
Summary|ice in is_gimple_reg_type   |8ice in is_gimple_reg_type
   |with -O2|with -O2
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed, started with r247407.

[Bug tree-optimization/80612] [7/8 Regression] ICE in get_range_info, at tree-ssanames.c:375

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fix looks obvious - though I wonder why we call get_size_range on sth not
integral...  maybe there's a lurking bug elsewhere.

[Bug tree-optimization/80621] [8 regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Dup has reduced testcase.

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

[Bug c++/80613] ice in is_gimple_reg_type with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #2 from Richard Biener  ---
*** Bug 80621 has been marked as a duplicate of this bug. ***