[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #15 from Andrew Roberts  ---
Created attachment 42792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42792=edit
/proc/cpuinfo fro rpi3 (cortex a-53) on aarch64

/proc/cpuinfo fro rpi3 (cortex a-53) on aarch64

while this is the same cpu as odroid-c2 running aarch64, it has much newer
kernel.
rpi: 4.14.3-1-ARCH
odroid-c2: 3.14.79-28-ARCH

Newer aarch64 kernels expose MIDR directly at:
/sys/devices/system/cpu/cpu0/regs/identification/midr_el1

but not the other control regs needed for FPU detection

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #14 from Andrew Roberts  ---
Richard, I have checked with latest snapshot (20171203) and problem persists.

I think the issue is that the CPU on the original Raspberry Pi and Pi Zero is
not detected properly by gcc. 

/usr/local/gcc/bin/gcc -mcpu=native -Q --help=target | grep mcpu=
  -mcpu=arm1176jz-s

But the processor is actually an arm1176jzf-s

Using:
/usr/local/gcc/bin/gcc -o matrix-v6  -mcpu=arm1176jzf-s  -mfpu=auto -O3
matrix.c
works

whereas using -mcpu=native or -mcpu=arm1176jz-s fails (no FPU).

gcc seems to parse /proc/cpuinfo to get the MIDR details and this is correct
(as far as it goes). But it doesn't parse the Features line to get the FPU
details. Which is the only way of telling the arm1176jz-s from arm1176jzf-s (as
Linux doesn't give access to control registers).

On Raspberry Pi B/Zero:
Features: half thumb fastmult vfp edsp java tls

I've attached /proc/cpuinfo for all arm processors I have.

While looking at this it might be worth also looking at bug 83207 (big/little
cpu detection) as that is just a case of parsing out both processors from the
/proc/cpuinfo file (see odroid-xu4 file)

It might be worth soliciting additional /proc/cpuinfo files from the mailing
list, if anybody has them.

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #13 from Andrew Roberts  ---
Created attachment 42791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42791=edit
/proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode

/proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode

[Bug middle-end/83286] internal compiler error: Illegal instruction

[aweslowski at gmail dot com]

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

--- Comment #5 from Alex Weslowski  ---

Please note, this appears to be fixed (hopefully) in GCC 7.2.0. Either that, or
my version of GCC 6.4.0 is borked. (Or, it may be an intermittent error, I
suppose.)

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #12 from Andrew Roberts  ---
Created attachment 42790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42790=edit
/proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mode

/proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mode

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #11 from Andrew Roberts  ---
Created attachment 42789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42789=edit
/proc/cpuinfo from rpi b (arm1176jzf-s)

/proc/cpuinfo from rpi b (arm1176jzf-s)

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #10 from Andrew Roberts  ---
Created attachment 42788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42788=edit
/proc/cpuinfo from odroid-xu4 big/little cortex-a15/cortex-a7

/proc/cpuinfo from odroid-xu4 big/little cortex-a15/cortex-a7

[Bug driver/83206] -mfpu=auto does not work on ARM (armv7l-unknown-linux-gnueabihf)

[andrewm.roberts at sky dot com]

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

--- Comment #9 from Andrew Roberts  ---
Created attachment 42787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42787=edit
/proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1

/proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1

[Bug middle-end/83286] internal compiler error: Illegal instruction

[aweslowski at gmail dot com]

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

--- Comment #4 from Alex Weslowski  ---

Verbose output:




Making gp in O6.1-none-msys_nt
make[1]: Entering directory 'pari-2.9.3/O6.1-none-msys_nt'
/usr/bin/gcc -v -save-temps -c -O3 -Wall -fno-strict-aliasing
-fomit-frame-pointer-funroll-loops -fPIC -I. -I../src/headers -o mpker.o
mpker.c
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-pc-msys
Configured with: /msys_scripts/gcc/src/gcc-6.4.0/configure
--build=x86_64-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --with-arch=x86-64 --with-tune=generic
--disable-multilib --enable-__cxa_atexit --with-dwarf2
--enable-languages=c,c++,fortran,lto --enable-graphite --enable-threads=posix
--enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as
--disable-isl-version-check --enable-checking=release --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 6.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O3' '-Wall'
'-fno-strict-aliasing' '-fomit-frame-pointer' '-funroll-loops' '-fPIC' '-I' '.'
'-I' '../src/headers' '-o' 'mpker.o' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-msys/6.4.0/cc1.exe -E -quiet -v -I . -I ../src/headers
-Dunix -idirafter /usr/lib/../lib/../include/w32api -idirafter
/usr/lib/gcc/x86_64-pc-msys/6.4.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api
mpker.c -mtune=generic -march=x86-64 -Wall -fno-strict-aliasing
-fomit-frame-pointer -funroll-loops -fPIC -O3 -fpch-preprocess -o mpker.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-msys/6.4.0/../../../../x86_64-pc-msys/include"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-pc-msys/6.4.0/../../../../x86_64-pc-msys/lib/../lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../src/headers
 /usr/lib/gcc/x86_64-pc-msys/6.4.0/include
 /usr/lib/gcc/x86_64-pc-msys/6.4.0/include-fixed
 /usr/include
 /usr/lib/../lib/../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O3' '-Wall'
'-fno-strict-aliasing' '-fomit-frame-pointer' '-funroll-loops' '-fPIC' '-I' '.'
'-I' '../src/headers' '-o' 'mpker.o' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-msys/6.4.0/cc1.exe -fpreprocessed mpker.i -quiet
-dumpbase mpker.c -mtune=generic -march=x86-64 -auxbase-strip mpker.o -O3 -Wall
-version -fno-strict-aliasing -fomit-frame-pointer -funroll-loops -fPIC -o
mpker.s
GNU C11 (GCC) version 6.4.0 (x86_64-pc-msys)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.4.0 (x86_64-pc-msys)
compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version
3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 24bcd17f6cf5e28e81030c79700f6f57
In file included from ../src/headers/pari.h:49:0,
 from ../src/kernel/none/mp.c:20:
../src/kernel/none/divll_pre.h: In function ‘get_Fl_red’:
../src/kernel/none/divll_pre.h:31:1: internal compiler error: Illegal
instruction
 }
 ^
gcc: internal compiler error: Segmentation fault (program cc1)
make[1]: *** [Makefile:970: mpker.o] Error 4
make[1]: Leaving directory 'pari-2.9.3/O6.1-none-msys_nt'
make: *** [Makefile:34: gp] Error 2

[Bug middle-end/83286] internal compiler error: Illegal instruction

[aweslowski at gmail dot com]

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

--- Comment #3 from Alex Weslowski  ---
Created attachment 42786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42786=edit
Preprocessed file mpker.i

[Bug middle-end/83286] internal compiler error: Illegal instruction

[aweslowski at gmail dot com]

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

--- Comment #2 from Alex Weslowski  ---
(In reply to Andrew Pinski from comment #1)
> Can you read https://gcc.gnu.org/bugs/ and provide the preprocessed source?

Hi, will attach the mpker.i file to this bug. The zip file has also been
updated. Check the O6.1-none-msys_nt directory, I think.

https://www.dropbox.com/s/b2maeinfc459x0o/pari-2.9.3.zip?dl=0

[Bug target/83285] non-atomic stores can reorder more aggressively with seq_cst on AArch64 than x86: missed x86 optimization?

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|missed-optimization |wrong-code
 Target|x86_64-*-*, i?86-*-*,   |aarch64-linux-gnu
   |aarch64-*-* |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-05
 Ever confirmed|0   |1
   Severity|normal  |major

--- Comment #1 from Andrew Pinski  ---
So this is how the RTL for the atomic store for aarch64:

;; __atomic_store_4 (_6, 2, 5);

(insn 9 8 0 (set (mem/v:SI (reg/v/f:DI 75 [ sync ]) [-1  S4 A32])
(unspec_volatile:SI [
(const_int 2 [0x2])
(const_int 5 [0x5])
] UNSPECV_STL))
"/data1/src/gcc-cavium/toolchain-7/thunderx-tools/aarch64-thunderx-elf/include/c++/7.2.0/bits/atomic_base.h":374
-1
 (nil))


For x86:

(insn 9 8 10 (set (mem/v:SI (reg/v/f:DI 89 [ sync ]) [-1  S4 A32])
(unspec:SI [
(reg:SI 90)
(const_int 5 [0x5])
] UNSPEC_STA))
"/data1/src/gcc-cavium/toolchain-7/tools/include/c++/7.1.0/bits/atomic_base.h":374
-1
 (nil))

(insn 10 9 0 (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MFENCE))
"/data1/src/gcc-cavium/toolchain-7/tools/include/c++/7.1.0/bits/atomic_base.h":374
-1
 (nil))


This is a bug in aarch64.

See https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync :
"Although x and y are unrelated variables, the memory model specifies that the
assert cannot fail. The store to 'y' happens-before the store to x in thread 1.
If the load of 'x' in thread 2 gets the results of the store that happened in
thread 1, it must all see all operations that happened before the store in
thread 1, even unrelated ones. That means the optimizer is not free to reorder
the two stores in thread 1 since thread 2 must see the store to Y as well."

[Bug middle-end/83286] internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-12-05
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you read https://gcc.gnu.org/bugs/ and provide the preprocessed source?

[Bug c/83286] New: internal compiler error: Illegal instruction

[aweslowski at gmail dot com]

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

Bug ID: 83286
   Summary: internal compiler error: Illegal instruction
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aweslowski at gmail dot com
  Target Milestone: ---

Summary
--
Error compiling PARI/GP on Windows with MSYS2/mingw64. This might be an error
with make or with the config? 

make clean
./configure
make gp

internal compiler error: Illegal instruction
gcc: internal compiler error: Segmentation fault (program cc1)


System
--
Windows 7 Home Premium
MSYS2 64-bit
GCC 6.4.0

Resources
--
http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe

Local zip file (includes generated/processed files):
https://www.dropbox.com/s/b2maeinfc459x0o/pari-2.9.3.zip?dl=0

Original tar file from PARI/GP server:
https://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.9.3.tar.gz

Message
--
/usr/bin/gcc  -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer   
-funroll-loops -fPIC -I. -I../src/headers -o mpker.o mpker.c
In file included from ../src/headers/pari.h:49:0,
 from ../src/kernel/none/mp.c:20:
../src/kernel/none/divll_pre.h: In function ‘get_Fl_red’:
../src/kernel/none/divll_pre.h:31:1: internal compiler error: Illegal
instruction
 }
 ^
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
make[1]: *** [Makefile:970: mpker.o] Error 4

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
An ever-so-slightly slightly simplified test case (no loop) is the following:

void bar (std::vector , int num)
{
  if (num > 0)
{
  const auto sz = a.size ();

  if (sz < 3)
a.assign (1, 0);
  else
a.resize (sz - 2);
  }
}

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
This libstdc++ patch helps avoid both the warning and the bogus memset.  if
Jonathan isn't opposed to this kind of annotation I think there might be other
places in vector where this approach could improve the emitted object code.

diff --git a/libstdc++-v3/include/bits/vector.tcc
b/libstdc++-v3/include/bits/vector.tcc
index eadce3c..8093f5e 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -582,8 +582,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 {
   if (__n != 0)
{
- if (size_type(this->_M_impl._M_end_of_storage
-   - this->_M_impl._M_finish) >= __n)
+ size_type __navail = size_type(this->_M_impl._M_end_of_storage
+  - this->_M_impl._M_finish);
+
+ if (__navail > max_size () - size ())
+   __builtin_unreachable ();
+
+ if (__navail >= __n)
{
  _GLIBCXX_ASAN_ANNOTATE_GROW(__n);
  this->_M_impl._M_finish =

[Bug target/83285] New: non-atomic stores can reorder more aggressively with seq_cst on AArch64 than x86: missed x86 optimization?

[peter at cordes dot ca]

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

Bug ID: 83285
   Summary: non-atomic stores can reorder more aggressively with
seq_cst on AArch64 than x86: missed x86 optimization?
   Product: gcc
   Version: 6.3.0
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: ---

This is either an x86-64 missed optimization or an AArch64 bug.  I *think*
x86-64 missed optimization, but it's not-a-bug on AArch64 only because any
observers that could tell the difference would have data race UB.

#include 
// int na;
// std::atomic_int sync;

void seq_cst(int , std::atomic_int ) {
na = 1;
sync = 2;
na = 3;
}
https://godbolt.org/g/bUwZaM

On x86, all 3 stores are there in the asm in source order (for mo_seq_cst, but
not for mo_release).

On AArch64, gcc6.3 does  does  sync=2;  na=3;  If `na` was using relaxed atomic
stores, this would be a bug (because a thread that saw `sync==2` could then see
the original value of na, not na==1 or na==3).

But for non-atomic na, reading na even after Synchronizing With the `sync=2`
(with an acquire load) would be UB, because the thread that writes sync writes
na again *after* that.  It seems that gcc's AArch64 backend is using this as
license to sink the na=1 store past the sync=2 and merge it with the na=3.

seq_cst(int&, std::atomic&, std::atomic&):
mov w2, 2 // tmp79,
stlrw2, [x1]// tmp79,* sync
mov w1, 3 // tmp78,
str w1, [x0]  // tmp78, *na_2(D)
ret

-

If sync=2 is a release store (not seq_cst), then gcc for x86 does sink the na=1
past the release and merge.  (See the godbolt link.)  In this case it's also
allowed to hoist the na=3 store ahead of the release, because plain release is
only a one-way barrier for earlier stores.  That would be safe for
relaxed-atomic as well (unlike for non-atomic), but gcc doesn't do that.

I'm slightly worried that this is unintentional and could maybe happen for
relaxed atomics when it would be illegal.  (On AArch64 with seq_cst or release,
and on x86 only with release.)

But hopefully this is just gcc being clever and taking advantage of the fact
that writing a non-atomic after a possible synchronization point means that the
sync point is irrelevant for programs without data race UB.

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-12-05
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
This is my bad for letting these bugs sit so long without fixing them.

-Wstringop-overflow is meant to warn only for provable overflow.  In g(), the
overflow is possible but not inevitable.  The only call to the function in the
program is with an argument that guarantees the overflow doesn't happen, and so
the warning should not be issued.

The bug here is in the maybe_emit_chk_warning() function in builtins.c called
to handle __builtin___strncpy_chk.  The function passes the strncpy() bound as
the maxlen argument to check_sizes() when it should pass it as the size
argument analogously to the check_strncpy_sizes() function called for
__builtin_strncpy.

The following patch fixes the problem.  Let me run the full regression test
suite and submit it.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 097e1b7..3278c7f 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -9862,6 +9862,8 @@ maybe_emit_chk_warning (tree exp, enum built_in_function
fcode)
  (such as __strcat_chk).  */
   tree maxlen = NULL_TREE;

+  tree count = NULL_TREE;
+
   switch (fcode)
 {
 case BUILT_IN_STRCPY_CHK:
@@ -9888,7 +9890,7 @@ maybe_emit_chk_warning (tree exp, enum built_in_function
fcode)
 case BUILT_IN_STRNCPY_CHK:
 case BUILT_IN_STPNCPY_CHK:
   srcstr = CALL_EXPR_ARG (exp, 1);
-  maxlen = CALL_EXPR_ARG (exp, 2);
+  count = CALL_EXPR_ARG (exp, 2);
   objsize = CALL_EXPR_ARG (exp, 3);
   break;

@@ -9911,7 +9913,7 @@ maybe_emit_chk_warning (tree exp, enum built_in_function
fcode)
 }

   check_sizes (OPT_Wstringop_overflow_, exp,
-  /*size=*/NULL_TREE, maxlen, srcstr, objsize);
+  count, maxlen, srcstr, objsize);
 }

 /* Emit warning if a buffer overflow is detected at compile time

[Bug c++/83273] if constexpr does not fail with run-time conditions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug bootstrap/83284] New: bootstrap comparison failure in libiberty/stack-limit.o

[egallager at gcc dot gnu.org]

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

Bug ID: 83284
   Summary: bootstrap comparison failure in
libiberty/stack-limit.o
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10

On darwin10 I get this failure: 

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
libiberty/pic/stack-limit.o differs
libiberty/stack-limit.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2

I'm building as of SVN r255380.

My configure flags:

../configure --disable-werror --disable-werror-always
--enable-stage1-checking=release,rtl -C --with-system-libunwind
--enable-secureplt --enable-frame-pointer --enable-debug --without-isl
--disable-host-shared --enable-maintainer-mode --disable-default-pie
--with-ld64 --without-pic --enable-target-optspace --disable-nls
--with-system-zlib --with-libiconv-prefix=/opt/local --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--with-build-config=bootstrap-debug --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --enable-objc-gc
--enable-libada --enable-libssp --disable-libsanitizer CC=/usr/local/bin/gcc
CXX=/usr/local/bin/g++ AR_FOR_TARGET=/opt/local/bin/ar
AS_FOR_TARGET=/opt/local/bin/as LD_FOR_TARGET=/opt/local/bin/ld
NM_FOR_TARGET=/opt/local/bin/nm RANLIB_FOR_TARGET=/opt/local/bin/ranlib
STRIP_FOR_TARGET=/opt/local/bin/strip OTOOL=/opt/local/bin/otool
OTOOL64=/opt/local/bin/otool AUTOCONF=/opt/local/bin/autoconf264
AUTOHEADER=/opt/local/bin/autoheader264 AUTOM4TE=/opt/local/bin/autom4te264
AUTORECONF=/opt/local/bin/autoreconf264 AUTOSCAN=/opt/local/bin/autoscan264
AUTOUPDATE=/opt/local/bin/autoupdate264 IFNAMES=/opt/local/bin/ifnames264
ACLOCAL=/sw/bin/aclocal-1.11 PERL=/opt/local/bin/perl M4=/opt/local/bin/gm4
--enable-languages=c,c++,lto,objc,obj-c++ --no-create --no-recursion

cmp -b says:

$ cmp -b stage2-libiberty/stack-limit.o stage3-libiberty/stack-limit.o
stage2-libiberty/stack-limit.o stage3-libiberty/stack-limit.o differ: byte 21,
line 1 is  50 (   4 ^D
$

[Bug tree-optimization/83283] [7/8 Regression] Casting from boolean to unsigned char to enum returns incorrect results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|c++ |tree-optimization
  Known to work||6.2.1
   Target Milestone|--- |7.3
Summary|Casting from boolean to |[7/8 Regression] Casting
   |unsigned char to enum   |from boolean to unsigned
   |returns incorrect results   |char to enum returns
   ||incorrect results

[Bug c++/83283] New: Casting from boolean to unsigned char to enum returns incorrect results

[lukas.lorimer at snowflake dot net]

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

Bug ID: 83283
   Summary: Casting from boolean to unsigned char to enum returns
incorrect results
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukas.lorimer at snowflake dot net
  Target Milestone: ---

Hello, it appears casting from boolean to unsigned char then to an enum returns
incorrect results when the operation is vectorized. Below is a minimized
example.

* Removing the typedef and including `cstdint` also triggers the bug.
* Running it with `-fsanitize=undefined` does not produce any warnings (but
does stop the bug from occurring).
* This appears to be a regression since g++ 6.2.1.

// START main.ii
# 1 "main.cpp"
# 1 "/tmp/a//"
# 1 ""
# 1 ""
# 1 "main.cpp"
typedef unsigned char uint8_t;

enum EN : uint8_t {
  X = 0,
  Y = 1
};

void __attribute__((noinline)) fn(EN *v, int size) {
for (int i = 0; i < size; ++i) {

const bool b = (v[i] == EN::Y);
v[i] = static_cast(static_cast(b));
}
}

int main() {
  constexpr int items = 32;
  EN vals[items] = {X};
  vals[3] = Y;

  fn(vals, items);
  return vals[3];
}
// END main.ii

$ g++72 -g -O1 -ftree-loop-vectorize -Wall -Wextra main.cpp
# No output
$ ./a.out; echo $?
# Expected output: 1
255
$ g++72 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++72
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr
--mandir=/opt/rh/devtoolset-7/root/usr/share/man
--infodir=/opt/rh/devtoolset-7/root/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-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu
--enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-7.2.1-20170829/obj-x86_64-redhat-linux/isl-install
--enable-libmpx
--with-mpc=/builddir/build/BUILD/gcc-7.2.1-20170829/obj-x86_64-redhat-linux/mpc-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170829 (Red Hat 7.2.1-1) (GCC) 


The behaviour is correct if one uses:
const uint8_t b = (v[i] == EN::Y);

It appears the difference between the two is a single pand instruction which
applies a mask to the result of some vectorized operations.

[Bug fortran/83282] New: missing comma in format changes output

[urbanjost at comcast dot net]

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

Bug ID: 83282
   Summary: missing comma in format changes output
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

I (accidently) used a GNU/gfortran extension, leaving a comma out
  of a format. The output changed unexpectedly.  The description of
  the extension seems to indicate that the behavior should be the same
  whether the comma is present or not. The code produces the following
  output 

[a][bb   ][ccc  ][ ]
[a   [bb  [ccc [ 
[a   [bb  [ccc [ 

  The only difference between the three formats is that the first one
  has commas between the edit descriptors, some of which are removed in
  the other two formats ...

program missing_comma
implicit none

! A missing comma in a format changes output
character(len=*),parameter :: array(*)=[character(len=5) ::
'a','bb','ccc','']
   write(*,'(*("[",a,"]":))')array  ! with commas
   ! next, using GNU extension to leave out commas in format
   write(*,'(*("[",a"]":))')array 
   write(*,'(*("["a"]":))')array 

end program missing_comma

This is personally a low-priority issue, but might cause significant problems
for pre-f90 code where the lack of commas in format descriptors is common.

[Bug sanitizer/82076] inconsistencies between sanitizer and -Wstringop-overflow

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Yea, I think it's inevitable that sanitizer-instrumented code is likely to run
afoul of various warnings.  Using the sanitizers disables certain
optimizations.  Optimizations that often we rely on to get accurate warnings.

I think we should ultimately consider this NOTABUG.

[Bug tree-optimization/82646] bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #1 from Jeffrey A. Law  ---
This test looks bogus to me.

"g" boils down to:

g (struct S * p, int n)
{
  long unsigned int _1;
  char[5] * _2;

;;   basic block 2, loop depth 0, count 1073741825 (estimated locally), maybe
hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [always]  count:1073741826 (estimated locally)
(FALLTHRU,EXECUTABLE)
  n_7 = MAX_EXPR ;
  _1 = (long unsigned int) n_7;
  _2 = _5(D)->a;
  __builtin___strncpy_chk (_2, "1234567", _1, 5);
  sink (_2);
  return;
;;succ:   EXIT [always (guessed)]  count:1073741825 (estimated locally)
(EXECUTABLE)

}

We can pretty easily see that _1 can exceed "7" and thus we could do an
out-of-bounds write.  THe fact that it doesn't is because main passes in the
value of 1.  MAX (1, 5) is 5, thus no runtime failure.  Pass in a large value
to g and you'll get a nice runtime failure.

[Bug tree-optimization/82103] spurious stringop-overflow warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #4 from Jeffrey A. Law  ---
IMHO the warning is correct here.  The code clearly does very bad things when
frame is zero.  In that case we pass -1 to the memset #define.  Which
ultimately results in the insane memset arguments.

This is *precisely* the kinds of things we want to be warning about.

[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
This (and pr80641) all feel closely related.  Transforming into a trap early
means we're not likely to get these reports which would be unfortunate because
they often point to a failing of the optimizer.

I think we should start by figuring out why VRP didn't help us here. From
looking at the stuff we've got so far, I'd focus on:

;;   basic block 13, loop depth 1, count 357916946 (estimated locally), maybe
hot
;;prev block 12, next block 14, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [50.0% (guessed)]  count:357916948 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  _117 = ASSERT_EXPR <_17, _17 > 2>;
  _1 = _117 + 18446744073709551614;
  if (_1 > _117)
goto ; [33.00%]
  else
goto ; [67.00%]


;;   basic block 14, loop depth 1, count 59056296 (estimated locally), maybe
hot
;;   Invalid sum of incoming counts 118112592 (estimated locally), should be
59056296 (estimated locally)
;;prev block 13, next block 15, flags: (NEW, REACHABLE, VISITED)
;;pred:   13 [33.0% (guessed)]  count:118112592 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  _185 = ASSERT_EXPR <_1, _1 > _117>;
  _184 = ASSERT_EXPR <_185, _185 > 18446744073709551613>;
  _152 = ASSERT_EXPR <_117, _117 < _184>;
  _40 = ASSERT_EXPR <_152, _152 <= 1>;
  _83 = a$16_134 - a$8_73;
  _84 = _83 /[ex] 4;
  _85 = (long unsigned int) _84;
  if (_85 > 18446744073709551613)
goto ; [67.00%]
  else
goto ; [33.00%]
;;succ:   15 [67.0% (guessed)]  count:39567718 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;16 [33.0% (guessed)]  count:19488578 (estimated locally)
(FALSE_VALUE,EXECUTABLE)


The biggest problem I see is we don't know the relationship between a$16_134
and a$8_73 in BB14.  In fact we know nothing about a$16_134 at that point.  So
I don't see any way to simplify the conditional at the end of BB14.

The conditional at the end of BB12 is an overflow check.  But we're dealing
with unsigned types, so we can't rule out overflow.  But even knowing what
direction it took doesn't help us.  So we can't simplify/eliminate it nor use
its direction to help.

Note this differs from 79095 because in 79095 we had information about the
relationship between the two key pointers -- namely we knew they were not the
same.  That allowed us to determine their difference was nonzero and the result
of the exact division had to be nonzero as well.  All that played into being
able to eventually prove the path leading to the problem memset was not
executable.

I don't see anything in this BZ that would allow us to make the same
determination here.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at gcc dot gnu.org]

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

--- Comment #37 from Jan Hubicka  ---
Author: hubicka
Date: Mon Dec  4 23:59:11 2017
New Revision: 255395

URL: https://gcc.gnu.org/viewcvs?rev=255395=gcc=rev
Log:
PR target/81616
* athlon.md: Disable for generic.
* haswell.md: Enable for generic.
* i386.c (ix86_sched_init_global): Add core hooks for generic.
* x86-tune-sched.c (ix86_issue_rate): Increase issue rate for generic
to 4.
(ix86_adjust_cost): Move generic to haswell path.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/athlon.md
trunk/gcc/config/i386/haswell.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/x86-tune-sched.c

[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[macetw at gmail dot com]

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

--- Comment #4 from Tyler Mace  ---
The argument against environment variables doesn't make sense, when the
GCC_COLORS environment variables are used right within this feature.

[Bug testsuite/83281] New: [8 regression] libgomp.oacc-c-c++-common/reduction-cplx-flt.c and reduction-cplx-dbl.c fail starting with r255335

[seurer at gcc dot gnu.org]

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

Bug ID: 83281
   Summary: [8 regression]
libgomp.oacc-c-c++-common/reduction-cplx-flt.c and
reduction-cplx-dbl.c fail starting with r255335
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Given the description of the revision do the test cases just need updating?

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/ -x c++
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/../../include
-I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenacc
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -O2 -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-lstdc++ -lm -o ./reduction-cplx-dbl.exe
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:
In function 'int main()':
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
error: unable to find numeric literal operator 'operator""i'
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
note: add 'using namespace std::complex_literals' (from ) to enable
the C++14 user-defined literal suffixes
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
note: or use 'j' instead of 'i' for the GNU built-in suffix
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
error: unable to find numeric literal operator 'operator""i'
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
note: add 'using namespace std::complex_literals' (from ) to enable
the C++14 user-defined literal suffixes
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
note: or use 'j' instead of 'i' for the GNU built-in suffix
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:
In function 'int main()':
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
error: unable to find numeric literal operator 'operator""i'
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
note: add 'using namespace std::complex_literals' (from ) to enable
the C++14 user-defined literal suffixes
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
note: or use 'j' instead of 'i' for the GNU built-in suffix
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
error: unable to find numeric literal operator 'operator""i'
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
note: add 'using namespace std::complex_literals' (from ) to enable
the C++14 user-defined literal suffixes
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:38:
note: or use 'j' instead of 'i' for the GNU built-in suffix

FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c:102:31:
error: unable to 

[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[macetw at gmail dot com]

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

Tyler Mace  changed:

   What|Removed |Added

 CC||macetw at gmail dot com

--- Comment #3 from Tyler Mace  ---
This makes a ton of sense. gcc is typically used alongside other tools like
cmake, googletest, clang (maybe), and other tools are using that specific
environment variable.

Let me put it this way:
As a build engineer, I want to minimize the steps to set up this kind of
environment within an automation framework like Jenkins (and the Ansicolor
plugin), so that I can see colorized output without digging into each tool that
needs command arguments.

[Bug middle-end/81876] [7/8 Regression] bogus -Wstrict-overflow warning with -O3

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
I'm a bit unsure how you want to proceed here Richi.

Marc's changes to move key folding patterns from fold-const.c into match.pd
means the x + 1 > x  -> 1 simplification happens earlier/more often.  So the
problematical sequence gets wiped out by VRP2.   That's probably a good thing.  

However, that bit of match.pd does not warn when it makes that assumption.  
One could argue it should.  Of course if it warns, then we end up in situations
like this BZ where the warning spit out by GCC bears no resemblance to the
actual source code because of ldist or other significant code transformations.

So I could make an argument to drop the 8 from the regression marker.  I could
make an argument we should open a new BZ for the missed warning and/or a BZ for
getting the code coming out of ldist sane.

Thoughts?

[Bug libstdc++/83279] std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to T B from comment #0)
> However, when I compiled it with GCC 5.4.0 (g++ -std=c++14 *.cpp *.h
> -lstdc++fs) everything works fine and I can copy files with a size of over
> 2.0GiB.

That's strange, because the code for copy_file is identical.

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Dec  4 23:08:22 2017
New Revision: 255392

URL: https://gcc.gnu.org/viewcvs?rev=255392=gcc=rev
Log:
Fix warnings in 

* include/bits/regex_compiler.tcc: Use C-style comment to work around
PR preprocessor/61638.
(__INSERT_REGEX_MATCHER): Replace GNU extension with __VA_ARGS__.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_compiler.tcc

[Bug c++/83273] if constexpr does not fail with run-time conditions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

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

[Bug c++/83280] gcc doesn't realize a returning value from complete switch(enum...) does return a value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
No, GCC is correct. If you call converter((e)3) the function fails to return.

[Bug c++/83273] if constexpr does not fail with run-time conditions

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Dec  4 22:52:07 2017
New Revision: 255390

URL: https://gcc.gnu.org/viewcvs?rev=255390=gcc=rev
Log:
PR c++/83273 - constexpr if allows non-constant condition

* semantics.c (finish_if_stmt_cond): Use require_constant_expression
rather than is_constant_expression.
* constexpr.c (potential_constant_expression_1) [LAMBDA_EXPR]: Allow
in C++17.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if12.C

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
So the core bits of the embeddable range analyzer have landed.I've just
updated (locally) my bits to use that in the sprintf warnings and they do
indeed fix this problem.  Let me finish beating those into shape.

[Bug c++/83280] New: gcc doesn't realize a returning value from complete switch(enum...) does return a value

[gu...@henkel-wallace.org]

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

Bug ID: 83280
   Summary: gcc doesn't realize a returning value from complete
switch(enum...) does return a value
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gu...@henkel-wallace.org
  Target Milestone: ---

Given this file:
===
enum class e { a, b, c};

int converter (e val);

int converter (e val) {
 switch (val) {
 case e::a: return 0;
 case e::b: return 1;
 case e::c: return 2;
 }
}
===

g++ 7.2 doesn't realize this function always returns correctly:

   $ g++-7 -Wswitch -Wreturn-type -std=c++11 -c enum-problem.cc
   enum-problem.cc: In function 'int converter(e)':
   enum-problem.cc:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
   $

[Bug rtl-optimization/83272] Unnecessary mask instruction generated

[slash.tmp at free dot fr]

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

--- Comment #2 from Mason  ---
(In reply to Jakub Jelinek from comment #1)

> I don't believe the andl is not needed after shrb, as that is an 8-bit
> operand size, it should leave the upper 56 bits of the register unmodified. 
> And unsigned char argument is in the ABI passed as int, so I think the upper
> 32 bits are undefined, which the andl instruction clears.

I checked the amd64 SysV ABI, and didn't see a requirement for a function
returning an INTEGER type smaller than 64 bits to clear the upper bits?
(The caller knows what bits are valid.)

Anyway, I may have oversimplified the testcase. Consider this one:

char foo(unsigned char *p)
{
static const char map[16] = "wxyz";
return map[*p / 16];
}

foo:
movzbl  (%rdi), %eax
shrb$4, %al
andl$15, %eax
movzbl  map.2295(%rax), %eax
ret


movzbl does all bits of RAX.
shrb discards 4 of the 8 bits, leaving only 4.
Thus, andl is a no-op in that case.

[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
So this really doesn't have anything to do with locking, mutexes or anything
like that.  It's really just a matter of the CFG having a shape that is
problematical for the old jump threader.

To thread the CFG (and thus allow proving the uninitialized use is properly
guarded) requires iterating jump threading.  That's something we decided years
ago to stop doing due to the compilation cost.

Aldy is working on improvements to the newer backwards jump threader which will
give it a fighting chance to address this problem.  The biggest worry there
will be the amount of block copying that will be necessary to expose the flow
of the known value of fibmatch through all the paths between the two
conditionals.

An alternate solution would be to enhance the predicate analysis that is used
to prune uninit warnings in tree-ssa-uninit.c.  Fixing the threader is strongly
preferred because threading the jumps ultimately reduces the amount of runtime
branching the code does as opposed to just avoiding the warning.

I'm cc-ing Aldy just in case he wants to peek and see if his work does capture
the jump thread in this BZ or if he wants to dig into tree-ssa-uninit.c again
:-)

[Bug c++/83268] internal compiler error: in lambda_expr_this_capture, at cp/lambda.c:785

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Works in trunk.

[Bug libstdc++/83279] New: std::experimental::filesystem::copy_file can't copy larger files than 2.0GiB

[ta12ba34 at gmail dot com]

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

Bug ID: 83279
   Summary: std::experimental::filesystem::copy_file can't copy
larger files than 2.0GiB
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ta12ba34 at gmail dot com
  Target Milestone: ---

GCC-version: 7.2.0
System: KDE neon (based on Ubuntu 16.04 LTS) x64, x86_64-linux-gnu
GCC-configuration-options: --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --enable-checking=release --enable-languages=c,c++
--program-suffix=-7.2 --disable-multilib --prefix=/opt/gcc-7.2.0

compile line: g++ -std=c++17 *.cpp *.h -lstdc++fs

thrown exception: filesystem error: cannot copy file: No such file or directory
[/path/to/sourcefile] [/path/to/destinationfile]

preprocessed file: see attachment

detailed description:
The function std::experimental::filesystem::copy_file is not able to copy any
file larger than 2.0GiB (2147483647 Bytes). If you try this, the mentioned
exception will be thrown after 2.0GiB of an >2.0GiB-file were copied - so that
the copy process is canceled and the copied file is incomplete.
I could reproduce this behavior in more than one program by simply using
std::experimental::filesystem::copy.
However, when I compiled it with GCC 5.4.0 (g++ -std=c++14 *.cpp *.h
-lstdc++fs) everything works fine and I can copy files with a size of over
2.0GiB.


I am sorry for any English mistakes.
Please contact me if there are any open questions.

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On December 4, 2017 6:55:02 PM GMT+01:00, law at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
>
>Jeffrey A. Law  changed:
>
>   What|Removed |Added
>
> CC||law at redhat dot com
>
>--- Comment #10 from Jeffrey A. Law  ---
>WRT c#9.  Precisely.  There's just one too many statements in the block
>for the
>threader to think it's profitable to clone the block.
>
>I've long wanted to have some kind of indication of how many statements
>are
>going to be eliminated by jump threading within the duplicated block so
>that we
>didn't have to be so pessimistic.  There's at least one more BZ in the
>regression list which touches on this issue.  Here's the block in
>question:
>
>  # t0_36 = PHI <-1(3), 0(2)>
>  # t1_37 = PHI 
>  # prephitmp_18 = PHI <_17(3), 0(2)>
>  # prephitmp_19 = PHI <_9(3), 2(2)>
>  # VUSE <.MEM_28>
>  x0.3_41 = x0;
>  _42 = (int) x0.3_41;
>  _43 = 29 % _42;
>  _44 = _43 & 25;
>  _45 = (long unsigned int) _44;
>  _46 = _45 * 10;
>  _47 = 128 % _46;
>  _48 = (char) _47;
>  _49 = (unsigned int) _48;
>  _50 = prephitmp_18 + _49;
>  _51 = (int) _50;
>  if (_51 < 0)
>goto ; [85.00%]
>  else
>goto ; [15.00%]
>
>
>Essentially starting at the control statement, we could realize that
>_51 is a
>single use SSA_NAME.  So if we thread, it's defining statement will go
>away, so
>we don't need to count it.  THen we look at its operand(s).  _50.  _50
>is
>single use as well, so its defining statement will go away.  And so-on
>until we
>hit the start of the block. We can then use that information to get a
>much
>better  estimation of the codesize cost of cloning the block.
>
>Alex, want to take a stab at it?

Also PHI nodes which are all single argument after threading shouldn't really
count as we can propagate them away.

Loop unrolling has crude heuristics to estimate stmts eliminated by constant
propagation, sth to look at as well. And then there's the possibility to simply
run DOM on the path and instead of modifying the original code emit copies in a
new sequence, costing, copying and optimizing in one go. If it gets too
expensive simply throw the sequence away.

Richard.

[Bug tree-optimization/83278] missing -Wformat-overflow for an inlined __builtin___sprintf_chk with a local buffer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80074

--- Comment #1 from Martin Sebor  ---
See also bug 80074, though that one is about not warning without optimization.

[Bug tree-optimization/83278] New: missing -Wformat-overflow for an inlined __builtin___sprintf_chk with a local buffer

[msebor at gcc dot gnu.org]

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

Bug ID: 83278
   Summary: missing -Wformat-overflow for an inlined
__builtin___sprintf_chk with a local buffer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The example below shows a inconsistency in the compile-time detection of
overflowing calls to strcpy.  The first call (in f()) is detected, the second
one (in g()) results in a duplicate warning, and third one (in h()) is not
detected.

$ cat d.c && gcc -O2 -S -Wall d.c
void sink (char*);

void f (const char *s)
{
  char a[3];

  __builtin_sprintf (a, "%s", s);   // warning (good)

  sink (a);
}

void call_f (void)
{
  f ("12345");
}

char a[3];

void g (const char *s)
{
  __builtin___sprintf_chk (a, 1,   // duplicate warning
__builtin_object_size (a, 1), "%s", s);
}

void call_g (void)
{
  g ("123456");
}

void h (const char *s)
{
  char a[3];

  __builtin___sprintf_chk (a, 1,   // missing warning (bug)
   __builtin_object_size (a, 1), "%s", s);

  sink (a);
}

void call_h (void)
{
  h ("1234567");
}
d.c: In function ‘call_f’:
d.c:7:26: warning: ‘%s’ directive writing 5 bytes into a region of size 3
[-Wformat-overflow=]
   __builtin_sprintf (a, "%s", s);   // warning (good)
  ^~
d.c:14:6:
   f ("12345");
  ~~~  
d.c:7:3: note: ‘__builtin_sprintf’ output 6 bytes into a destination of size 3
   __builtin_sprintf (a, "%s", s);   // warning (good)
   ^~
d.c: In function ‘call_g’:
d.c:22:60: warning: ‘%s’ directive writing 6 bytes into a region of size 3
[-Wformat-overflow=]
 __builtin_object_size (a, 1), "%s", s);
^~
d.c:27:6:
   g ("123456");
     
d.c:21:3: note: ‘__builtin___sprintf_chk’ output 7 bytes into a destination of
size 3
   __builtin___sprintf_chk (a, 1,   // duplicate warning
   ^
 __builtin_object_size (a, 1), "%s", s);
 ~~
In function ‘g’,
inlined from ‘call_g’ at d.c:27:3:
d.c:21:3: warning: ‘__builtin___sprintf_chk’ writing 7 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]

[Bug c++/83271] const variable previously declared "extern" results in "weak declaration must be public" error

[alexey.salmin at gmail dot com]

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

--- Comment #4 from Alexey Salmin  ---
(In reply to Jonathan Wakely from comment #3)
> At least there's a simple workaround (adding 'extern' to the definition
> where the attribute).

That's what we do, so this is really a minor bug. Still, I decided to report it
for a few reasons:
1) Current g++ behavior looks inconsistent
2) clang++ and icc handle this case correctly
3) I'm used to a practice where declarations has the "extern" specifier while
definitions don't. This matters when you rely on the zero-initialization which
I normally don't do, but this pattern is somehow stuck in my head

[Bug c++/83273] if constexpr does not fail with run-time conditions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
And you also can't use #pragma GCC diagnostic ignored "-Wcomment" to silence
it.

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(Changed from "enhancement" to "normal" because the current behaviour is just
bad)

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2014-10-05 00:00:00 |2017-12-4
   Severity|enhancement |normal

--- Comment #2 from Jonathan Wakely  ---
The warning is even emitted when the backslash isn't the last character before
the newline, so you can't add whitespace to your ascii art to shut the warning
up.

Clang doesn't warn when the next line is also a comment (as Zack requests) and
has a separate -Wbackslash-newline-escape warning for the case where there's
whitespace between the backslash and the newline. That seems much more useful.

[Bug c++/83271] const variable previously declared "extern" results in "weak declaration must be public" error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
At least there's a simple workaround (adding 'extern' to the definition where
the attribute).

[Bug c++/83273] if constexpr does not fail with run-time conditions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-04
 Ever confirmed|0   |1

[Bug c++/83271] const variable previously declared "extern" results in "weak declaration must be public" error

[alexey.salmin at gmail dot com]

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

--- Comment #2 from Alexey Salmin  ---
(In reply to Jakub Jelinek from comment #1)
> I must say I fail to see usefulness of adding the attribute to the
> definition rather than declaration though.

Here's my case. There's a const bool flag in a static library that should be
reliably available before the main() entry point, therefore the static
initialization is used (see C++11 3.6.2.2). By default the flag is set to true
but it's overridden to false in a custom build.

flag.h:
extern const bool flag;

enabled.cpp:
#include "flag.h"
const bool flag __attribute__((weak)) = true;

disabled.cpp:
#include "flag.h"
const bool flag = false; // strong override

Library behaves differently depending on whether the "disabled.o" was provided
to the linker or not, while the "enabled.o" is always ar-ed into the static
library. I include the same header file in both cpp files to make sure both
definitions correspond to the same declaration.

Let me know if there's a better way to achieve this behavior. The one I can
think of involves a macro and two different builds of the library but it's not
welcome in our build system. Another option would be to keep both "enabled.o"
and "disabled.o" out of the static library and don't use weak symbols at all,
but that breaks the compatibility.

[Bug fortran/83275] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 (and others)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
I am starting to suspect that you have a distinctly perverse sense of humour
:-)

That said, finding these invalid cases that die horribly is extremely valuable.

Many thanks, I will take it.

Paul

[Bug bootstrap/81934] after install of 7.2.0 the libcilkrts.la has extra quote chars in it for dependency_libs

[dclarke at blastwave dot org]

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

--- Comment #2 from Dennis Clarke  ---
So then, this is a case of "wait and see" wherein any previous release of
the gcc tarballs will just continue to fail?

[Bug tree-optimization/69224] [6/7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[6/7/8 Regression]  |[6/7 Regression]
   |-Warray-bounds false|-Warray-bounds false
   |positive with -O3 and   |positive with -O3 and
   |struct pointer parameter|struct pointer parameter

--- Comment #9 from Jeffrey A. Law  ---
Another fixed by Richi's 83202 changes.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
(In reply to Andrew Pinski from comment #10)

> We can add this if needed.  I think regression could be made make generic
> and add a generic new bug component.  We do have some very active people
> reading bug reports that can re-categorize them (not to sound special but I
> am one of them; note sometimes I get it wrong too).

Yes, in practice bugs are usually dispatched to the correct owner quite fast
(thanks for that, it really helps). So "new" category would not change much in
this sense, but it would definitely make the process more friendly and less
confusing for outsiders.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu

--- Comment #10 from Andrew Pinski  ---
(In reply to Dmitry Babokin from comment #9)
> And GCC bug tracker doesn't even have generic "new bugs"
> component to assign, which means people need to have secret knowledge about
> compiler internals

We can add this if needed.  I think regression could be made make generic and
add a generic new bug component.  We do have some very active people reading
bug reports that can re-categorize them (not to sound special but I am one of
them; note sometimes I get it wrong too).

[Bug c++/83271] const variable previously declared "extern" results in "weak declaration must be public" error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That diagnostics is emitted from the attribute handling, before the decls is
merged with the previous extern const int x; decl, so it indeed isn't
TREE_PUBLIC.
So, this doesn't really look easy to fix, we'd need to postpone the weak
attribute processing until later, or look up from the attribute handling code
in the FE whether it has been defined already during the attribute processing,
or temporarily set TREE_PUBLIC bits on the constants around the generic
processing and then make sure to call it again once we can finalize it if it
isn't TREE_PUBLIC but is DECL_WEAK.

I must say I fail to see usefulness of adding the attribute to the definition
rather than declaration though.

[Bug target/70216] [SH] Implement __builtin_trap

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #20 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #19)
> (In reply to John Paul Adrian Glaubitz from comment #18)
> 
> > I can confirm that the patch from comment #6 resolves the problem for me.
> 
> Thanks for checking.

Just for completeness sake, the patch also fixes the build of glibc with gcc-7.

So, yes, it should be merged :).

[Bug fortran/82973] [8 regression] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---
(In reply to Martin Liška from comment #0)
> Trunk does with cross compiler:
> 
> $ aarch64-linux-gnu-gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/intrinsic_modulo_1.
> f90 -frounding-math -Ofast -c
> during RTL pass: final
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/intrinsic_modulo_1.
> f90:37:0:
> 
>  end program main
>  
> internal compiler error: in output_constant_pool_2, at varasm.c:3896
> 0xee97bb output_constant_pool_2
>   .././../gcc/varasm.c:3896
> 0xee974d output_constant_pool_2
>   .././../gcc/varasm.c:3929
> 0xee9846 output_constant_pool_1
>   .././../gcc/varasm.c:3997
> 0xef85d9 output_constant_pool_contents
>   .././../gcc/varasm.c:4134
> 0xef9003 output_constant_pool
>   .././../gcc/varasm.c:4162
> 0xef9003 assemble_end_function(tree_node*, char const*)
>   .././../gcc/varasm.c:1912
> 0x8b0f3f rest_of_handle_final
>   .././../gcc/final.c:4488
> 0x8b0f3f execute
>   .././../gcc/final.c:4551

Well this doesn't look like a proper vector constant after cse1:

(insn 871 1529 917 122 (set (reg:V4SF 60 v28 [orig:143 vect__115.44 ] [143])
(mem/u/c:V4SF (lo_sum:DI (reg:DI 2 x2 [822])
(symbol_ref/u:DI ("*.LC3") [flags 0x2])) [0  S16
A128]){*aarch64_simd_movv4sf}
 (expr_list:REG_EQUIV (const_vector:V4SF [
(mult:SF (const_double:SF 5.0e+0 [0x0.ap+3])
(const_double:SF
3.3e-1
[0x0.aaabp-1]))
(mult:SF (const_double:SF 5.0e+0 [0x0.ap+3])
(const_double:SF
-3.3e-1
[-0x0.aaabp-1]))
(const_double:SF 5.0e+0 [0x0.ap+3])
(const_double:SF -5.0e+0 [-0x0.ap+3])
])

It believes the multiply is a constant but doesn't fold it due to
-frounding-math... I can work around it in the back-end by rejecting illegal
vector constants but I think the mid-end really shouldn't create these.

[Bug rtl-optimization/83272] Unnecessary mask instruction generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't believe the andl is not needed after shrb, as that is an 8-bit operand
size, it should leave the upper 56 bits of the register unmodified.  And
unsigned char argument is in the ABI passed as int, so I think the upper 32
bits are undefined, which the andl instruction clears.  Perhaps using shrl $4,
%edi
would be sufficient if the argument really has to be zero extended.
In your
static const char map[16] = "xyz";
void foo(unsigned char *src, char *buf)
{
int hi = src[0] / 16;
int lo = src[0] % 16;
buf[0] = map[hi];
buf[1] = map[lo];
}
testcase, I suppose we'd need to use REE to figure out something the generic
code can't know, in particular that the movzbl instruction also clears the
upper 32 bits and that shrb instruction doesn't modify the upper 32 bits.
REE sees:
(insn 7 4 21 2 (set (reg:QI 0 ax [orig:87 _1 ] [87])
(mem:QI (reg/v/f:DI 5 di [orig:94 src ] [94]) [0 *src_6(D)+0 S1 A8]))
"pr83272.c":4 88 {*movqi_internal}
 (nil))
(insn 21 7 9 2 (set (reg:QI 1 dx [97])
(reg:QI 0 ax [orig:87 _1 ] [87])) "pr83272.c":4 88 {*movqi_internal}
 (nil))
(insn 9 21 10 2 (parallel [
(set (reg:QI 1 dx [97])
(lshiftrt:QI (reg:QI 1 dx [97])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr83272.c":4 585 {*lshrqi3_1}
 (nil))
(insn 10 9 11 2 (set (reg:DI 1 dx [orig:98 hi ] [98])
(zero_extend:DI (reg:QI 1 dx [97]))) "pr83272.c":4 136
{zero_extendqidi2}
 (nil))
...
(insn 15 14 16 2 (parallel [
(set (reg:DI 0 ax [orig:102 lo ] [102])
(and:DI (reg:DI 0 ax [orig:87 _1 ] [87])
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) "pr83272.c":5 412 {*anddi_1}
 (nil))

The & 15 in that case is a must, that is the % 16 from the source, the upper
bits can be set.  And so the only thing that can be eliminated is the movzbl
insn 10, but in order to find that out we'd need to understand first that insn
7 clears upper 56 bits of the register, that insn 21 if we actually emit movl
%eax, %edx copies the low 32 bits (where from the earlier insn the upper 24
bits are cleared) and clears the high 32 bits (note if we emit instead movb
%al, %dl, then this doesn't hold, as it leaves upper 56 bits of %rdx
unmodified), and finally that insn 9 keeps upper 56 bits of %rdx unmodified and
from previous insns we have guaranteed zeros there.
In any case, this is far beyond what current REE can do ATM.

[Bug middle-end/82286] [6/7 Regression] Wrong array subscript is above array bounds

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[6/7/8 Regression] Wrong|[6/7 Regression] Wrong
   |array subscript is above|array subscript is above
   |array bounds|array bounds

--- Comment #6 from Jeffrey A. Law  ---
Also fixed by Richi's change for 83202 on the trunk.  Will be collecting this
and other instances of the same issue for the testsuite.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #9 from Dmitry Babokin  ---
(In reply to Richard Biener from comment #8)
> I suppose one could try scripting something with -fdisable-{tree,rtl}-$dump
> and seeding the list of passes to enable/disable with -fdump-{tree,rtl}-all.
> 
> Of course some -fdisable-* are "invalid" and will cause "interesting"
> downstream
> effects...
> 
> Sometimes I do this manually for cases where it isn't obvious who's doing sth
> wrong...

The main downside of this approach is that it requires understanding of GCC
compiler internals. And GCC bug tracker doesn't even have generic "new bugs"
component to assign, which means people need to have secret knowledge about
compiler internals. Would be good to address this problem in the long run and
make bug filing process more friendly for outsiders.

Don't take me wrong, my bugs are almost always are addressed blazingly fast and
I'm super happy about it. But I still think there are things which can make
life for bug filing people easier.

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Note the #c8 testcase started failing with r247578 - before that we weren't
doing that good job in evrp to optimize it.

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #8 from Jeffrey A. Law  ---


The two key blocks are:

bb2:
  _3 = __builtin_object_size (tp_2(D), 0);
  _4 = _2(D)->D.2254;
  GIMPLE_NOP
  _5 = tp_2(D)->chrono_type;
  if (_5 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

bb3:
  now_6 = tcp_jiffies32;
  _7 = BIT_FIELD_REF <*tp_2(D), 8, 128>;
  _8 = _7 & 3;
  if (_8 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

Where the out of bounds access occurs in BB4 which can only be reached via BB3.

We essentially need to prove that _5 and _8 are equivalent.  The only good news
is that the edge 2->3 dominates bb3 so this could (in theory) be handled with
good equivalence processing without jump threading.

Are we allowed to use types like this in a gimple conditional?

   _5;

If so, then one approach would be first focus on BB3.  We'd want to combine the
BIT_FIELD_REF and masking into a single BIT_FIELD_REF and test the result of
that without conversion.  Could forwprop handle that perhaps?

Once the BIT_FIELD_REF just reads two bits, then we'd have a fighting chance of
realizing that the BIT_FIELD_REF is just a reference to tp_2->chrono_type. 
Which we could lookup in the hash table has _5 which has a known constant value
of zero.

Not working on this, but figured I'd at least chime in with some thoughts on
how we might be able to approach...

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
void
foo (unsigned p, unsigned a, unsigned b)
{
  unsigned q = p + 7;
  if (a - (1U + __INT_MAX__) >= 2)
__builtin_unreachable ();
  int d = p + b;
  int c = p + a;
  if (c - d != __INT_MAX__)
__builtin_abort ();
}

void
bar (unsigned p, unsigned a)
{
  unsigned q = p + 7;
  if (a - (1U + __INT_MAX__) >= 2)
__builtin_unreachable ();
  int c = p;
  int d = p + a;
  if (c - d != -__INT_MAX__ - 1)
__builtin_abort ();
}

int
main ()
{
  foo (-1U, 1U + __INT_MAX__, 1U);
  bar (-1U, 1U + __INT_MAX__);
  return 0;
}

is a testcase that fails on the trunk with -O2 because of this (without any
sanitization).

On the other side, when add is a plus and not pointer_plus, the pattern doesn't
contain :c as I found when writing the testcase, so it matches only if the
SSA_NAMEs are in the right order.

[Bug fortran/83246] internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #10 from Jeffrey A. Law  ---
WRT c#9.  Precisely.  There's just one too many statements in the block for the
threader to think it's profitable to clone the block.

I've long wanted to have some kind of indication of how many statements are
going to be eliminated by jump threading within the duplicated block so that we
didn't have to be so pessimistic.  There's at least one more BZ in the
regression list which touches on this issue.  Here's the block in question:

  # t0_36 = PHI <-1(3), 0(2)>
  # t1_37 = PHI 
  # prephitmp_18 = PHI <_17(3), 0(2)>
  # prephitmp_19 = PHI <_9(3), 2(2)>
  # VUSE <.MEM_28>
  x0.3_41 = x0;
  _42 = (int) x0.3_41;
  _43 = 29 % _42;
  _44 = _43 & 25;
  _45 = (long unsigned int) _44;
  _46 = _45 * 10;
  _47 = 128 % _46;
  _48 = (char) _47;
  _49 = (unsigned int) _48;
  _50 = prephitmp_18 + _49;
  _51 = (int) _50;
  if (_51 < 0)
goto ; [85.00%]
  else
goto ; [15.00%]


Essentially starting at the control statement, we could realize that _51 is a
single use SSA_NAME.  So if we thread, it's defining statement will go away, so
we don't need to count it.  THen we look at its operand(s).  _50.  _50 is
single use as well, so its defining statement will go away.  And so-on until we
hit the start of the block. We can then use that information to get a much
better  estimation of the codesize cost of cloning the block.

Alex, want to take a stab at it?

[Bug fortran/83275] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 (and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/83274] [PDT] ICE in delete_root and missing error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug tree-optimization/83262] SELECT CASE slower than IF/ELSE

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Mon, Dec 04, 2017 at 10:03:01AM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262
> 
> --- Comment #7 from Dominique d'Humieres  ---
> > Dick Henderson in clf claims that there is a bug in the code.
> > You're comparing apples and oranges.  Mike Metcalf ran the
> > code with Dick's suggested change.
> 
> All my timings after comment 3 are done with the change of 'n' to 'i'.
> 

Then you may want to update the testcase.

[Bug c++/83273] if constexpr does not fail with run-time conditions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
tree
finish_if_stmt_cond (tree cond, tree if_stmt)
{
  cond = maybe_convert_cond (cond);
  if (IF_STMT_CONSTEXPR_P (if_stmt)
  && is_constant_expression (cond)
  && !value_dependent_expression_p (cond))
{
  cond = instantiate_non_dependent_expr (cond);
  cond = cxx_constant_value (cond, NULL_TREE);
}

So, if is_constant_expression is true, we do the right thing.
There is just no diagnostics if cond fails the is_constant_expression check and
isn't value dependent.  We actually treat that if constexpr like normal if,
with both then and else evaluated.

[Bug tree-optimization/83277] New: [8 Regression] [graphite] Wrong code w/ -O2 -floop-nest-optimize

[asolokha at gmx dot com]

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

Bug ID: 83277
   Summary: [8 Regression] [graphite] Wrong code w/ -O2
-floop-nest-optimize
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171126 snapshot (r255155), as well as gcc-8.0.0-alpha20171203
snapshot (r255368) w/ r255382 applied on top of it, produce wrong code w/ -O2
-floop-nest-optimize for the following snippet:

int rk, si = 0;
int jr[2];

int
wv (signed char n8)
{
  const int tw = 8;
  int xq[tw];
  int bj, pu = 0;

  for (bj = 0; bj < tw; ++bj)
xq[bj] = 0;

  bj = 0;
  while (bj < 1)
{
  int gs = n8 ^ 128;

  if (gs != 0)
{
  int u7[3];

  while (bj < 2)
{
  u7[bj] = 0;
  ++bj;
}

  jr[0] = u7[0];
  rk = xq[0];
  pu = n8;

  if (si != 0)
return si;
}
}

  return pu;
}

int
main (void)
{
  signed char ax = 1;

  return wv (ax) != ax;
}

% gcc-8.0.0-alpha20171203 -O2 -o good lu41pybr.c && ./good
% echo $?
0

% gcc-8.0.0-alpha20171203 -O2 -floop-nest-optimize -o bad lu41pybr.c && ./bad
zsh: exit 1 ./bad
% echo $?
1

[Bug c/83276] New: ICE in pre_and_rev_post_order_compute, at cfganal.c:1050

[gs...@t-online.de]

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

Bug ID: 83276
   Summary: ICE in pre_and_rev_post_order_compute, at
cfganal.c:1050
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This snippet together with -fopenmp :

$ cat z1.c
int f ()
{
  int i;
  #pragma omp parallel for
  for (i = 0; i < 4; ++i)
__builtin_return (0);
}


$ gcc-8-20171203 -c z1.c -fopenmp 
during GIMPLE pass: ssa
z1.c: In function 'f._omp_fn.0':
z1.c:7:1: internal compiler error: in pre_and_rev_post_order_compute, at
cfganal.c:1050
 }
 ^
0x736c11 pre_and_rev_post_order_compute(int*, int*, bool)
../../gcc/cfganal.c:1050
0x10d2a0a dom_walker::dom_walker(cdi_direction, bool, int*)
../../gcc/domwalk.c:191
0xb2f2cc mark_def_dom_walker::mark_def_dom_walker(cdi_direction)
../../gcc/tree-into-ssa.c:2325
0xb36aaa execute
../../gcc/tree-into-ssa.c:2456

[Bug fortran/83275] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 (and others)

[gs...@t-online.de]

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

--- Comment #2 from G. Steinmetz  ---

$ cat z5.f90
program p
   type t(a)
  allocate (a)
   end type
end


$ gfortran-8-20171203 -c z5.f90
f951: internal compiler error: Segmentation fault
0xb6a96f crash_signal
../../gcc/toplev.c:325
0x6fc247 gfc_impure_variable(gfc_symbol*)
../../gcc/fortran/resolve.c:15599
0x6c8878 gfc_match_allocate()
../../gcc/fortran/match.c:4048
0x6e6059 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6e9e89 match_word
../../gcc/fortran/parse.c:439
0x6e9e89 decode_statement
../../gcc/fortran/parse.c:439
0x6eb544 next_free
../../gcc/fortran/parse.c:1225
0x6eb544 next_statement
../../gcc/fortran/parse.c:1457
0x6ecabd parse_derived
../../gcc/fortran/parse.c:3255
0x6ecabd parse_spec
../../gcc/fortran/parse.c:3796
0x6ef323 parse_progunit
../../gcc/fortran/parse.c:5638
0x6f08e4 gfc_parse_file()
../../gcc/fortran/parse.c:6178
0x73537f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/83275] [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 (and others)

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 Blocks||82173

--- Comment #1 from G. Steinmetz  ---

$ cat z2.f90
program p
   type t()
   end type
   type, extends(t) :: t2
   end type
end


$ gfortran-8-20171203 -c z2.f90
f951: internal compiler error: Segmentation fault
0xb6a96f crash_signal
../../gcc/toplev.c:325
0x68dca4 gfc_match_derived_decl()
../../gcc/fortran/decl.c:9905
0x6e6059 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6ea06b match_word
../../gcc/fortran/parse.c:565
0x6ea06b decode_statement
../../gcc/fortran/parse.c:565
0x6eb544 next_free
../../gcc/fortran/parse.c:1225
0x6eb544 next_statement
../../gcc/fortran/parse.c:1457
0x6ece2c parse_spec
../../gcc/fortran/parse.c:3835
0x6ef323 parse_progunit
../../gcc/fortran/parse.c:5638
0x6f08e4 gfc_parse_file()
../../gcc/fortran/parse.c:6178
0x73537f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug fortran/83275] New: [PDT] ICE in get_pdt_constructor, at fortran/resolve.c:1185 (and others)

[gs...@t-online.de]

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

Bug ID: 83275
   Summary: [PDT] ICE in get_pdt_constructor, at
fortran/resolve.c:1185 (and others)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Related to pr83274, in order to avoid an overloaded PR.
According to f2008 4.5.3.1 and 1.4.3, a type-param-name-list in
a PDT definition statement should have at least one element (name).


$ cat z1.f90
program p
   type t()
   end type
   data x /t()/
end


$ gfortran-8-20171203 -c z1.f90
f951: internal compiler error: in get_pdt_constructor, at
fortran/resolve.c:1185
0x6f7d0f get_pdt_constructor
../../gcc/fortran/resolve.c:1185
0x70e1de resolve_structure_cons
../../gcc/fortran/resolve.c:1247
0x6fe629 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6763
0x69b55f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2696
0x6f5ab7 gfc_match_structure_constructor(gfc_symbol*, gfc_expr**)
../../gcc/fortran/primary.c:3039
0x682c7c match_data_constant
../../gcc/fortran/decl.c:412
0x682d66 top_val_list
../../gcc/fortran/decl.c:457
0x682f99 gfc_match_data()
../../gcc/fortran/decl.c:586
0x6e6059 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6eaa7f match_word
../../gcc/fortran/parse.c:467
0x6eaa7f decode_statement
../../gcc/fortran/parse.c:467
0x6eb544 next_free
../../gcc/fortran/parse.c:1225
0x6eb544 next_statement
../../gcc/fortran/parse.c:1457
0x6ece2c parse_spec
../../gcc/fortran/parse.c:3835
0x6ef323 parse_progunit
../../gcc/fortran/parse.c:5638
0x6f08e4 gfc_parse_file()
../../gcc/fortran/parse.c:6178
0x73537f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/83274] [PDT] ICE in delete_root and missing error

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 Blocks||82173

--- Comment #1 from G. Steinmetz  ---

These examples should be rejected :


$ cat z7.f90
program p
   type t
   end type
   type(t( )) :: a
   type(t(0)) :: b
   type(t(:)) :: c
   type(t(*)) :: d
end


$ cat z8.f90
program p
   type t()
  integer :: a
   end type
end


$ gfortran-8-20171203 -c z7.f90
$ gfortran-8-20171203 -Wall -c z8.f90
$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug fortran/83274] New: [PDT] ICE in delete_root and missing error

[gs...@t-online.de]

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

Bug ID: 83274
   Summary: [PDT] ICE in delete_root and missing error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

One remaining issue is that a PDT definition statement cannot have
an additional component-spec-list or a second type-param-name-list.


$ cat z1.f90
program p
   type t(a)(b)
  integer, kind :: a
  integer, len :: b
   end type
end


$ cat z2.f90
program p
   type t(a)()
  integer, len :: a
   end type
end


$ cat z3.f90
program p
   type t(a)(:)
  integer :: a
   end type
end


$ cat z4.f90
program p
   type t(a)(b)(c)
  integer, len :: a
  integer, kind :: b
  integer :: c
   end type
end

#...


$ gfortran-8-20171203 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb6a96f crash_signal
../../gcc/toplev.c:325
0x66ce9b delete_root
../../gcc/fortran/bbt.c:150
0x66d06e gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/fortran/bbt.c:197
0x725c48 gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc/fortran/symbol.c:2925
0x727416 gfc_restore_last_undo_checkpoint()
../../gcc/fortran/symbol.c:3694
0x6e5f67 reject_statement
../../gcc/fortran/parse.c:2546
0x6e607c match_word_omp_simd
../../gcc/fortran/parse.c:98
0x6ea06b match_word
../../gcc/fortran/parse.c:565
0x6ea06b decode_statement
../../gcc/fortran/parse.c:565
0x6eb544 next_free
../../gcc/fortran/parse.c:1225
0x6eb544 next_statement
../../gcc/fortran/parse.c:1457
0x6ed34c parse_spec
../../gcc/fortran/parse.c:3651
0x6ef323 parse_progunit
../../gcc/fortran/parse.c:5638
0x6f08e4 gfc_parse_file()
../../gcc/fortran/parse.c:6178
0x73537f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Even the
  (T)P - (T)(P + A) -> -(T) A
transformation looks wrong, consider A being 0U+INT_MIN, and P -1U.
(int)-1U - (int)(-1U+INT_MIN) is INT_MIN without overflow, while -(int)INT_MIN
overflows.  Note it doesn't look like fold-const.c, at least the removed spot
from it, was doing what the match.pd is doing at least for non-pointers.

Note r251651 was actually the right fix, just not for this issue, but for the
general issue that through performing say (int) (long_long_a - long_long_b)
to (int) ((unsigned) long_long_a - (unsigned) long_long_b)) optimization we
won't be able to detect UB user code had, but the optimized form doesn't.
That just means that the sanitizer is less useful in finding bugs in the
compiler transformations.  Perhaps we could have a debug counter or param or
something similar where we'd accept detecting fewer UBs on user code but gain
the possibility to detect more invalid transformations like this one.

[Bug c++/83273] New: if constexpr does not fail with run-time conditions

[nico at josuttis dot de]

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

Bug ID: 83273
   Summary: if constexpr does not fail with run-time conditions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

The following C++17 program should not compile, but it does:

#include 
int main()
{
  auto d = 42;
  if constexpr (d > 0) {
std::cout << "oops \n";
  }
}

This even works inside a loop over different values of d.
And I found it trying this:
  if constexpr (auto obj = 42; obj == 0) {
//...
  }
which should need a const/constexpr in the if initialization.

Reported as recommended by Jonathan Wakely.

Might also be a problem in 7.x

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So it is indeed the
  /* (T)(P + A) - (T)(P + B) -> (T)A - (T)B */
  (for add (plus pointer_plus)
   (simplify
(minus (convert (add @@0 @1))
 (convert (add @0 @2)))
(if (element_precision (type) <= element_precision (TREE_TYPE (@1))
 /* For integer types, if A has a smaller type
than T the result depends on the possible
overflow in P + A.
E.g. T=size_t, A=(unsigned)429497295, P>0.
However, if an overflow in P + A would cause
undefined behavior, we can assume that there
is no overflow.  */
 || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
 && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
 /* For pointer types, if the conversion of A to the
final type requires a sign- or zero-extension,
then we have to punt - it is not defined which
one is correct.  */
 || (POINTER_TYPE_P (TREE_TYPE (@0))
 && TREE_CODE (@1) == INTEGER_CST
 && tree_int_cst_sign_bit (@1) == 0
 && TREE_CODE (@2) == INTEGER_CST
 && tree_int_cst_sign_bit (@2) == 0))
 (minus (convert @1) (convert @2)))

case, where we have:
op0 (int) unsigned int) ll - (unsigned int) ci) - (unsigned int) i) +
2270794745)
op1 (int) unsigned int) ll - (unsigned int) ci) - (unsigned int) i) +
(unsigned int) ci);
type here is int, @0/@1/@2 all have unsigned type.

The (T)(P + A) - (T)(P + B) to (T)A - (T)B transformation is incorrect if
TYPE_OVERFLOW_UNDEFINED (type) (or its element type)
and either !TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)) (or its element type), or
TREE_TYPE (@1) has larger element precision.
Say if T is int, and TREE_TYPE (P) is unsigned, then e.g. random example of A =
0U+INT_MIN, B = 1U, P = -1U overflows only in the (int) INT_MIN - (int) 1 case,
but doesn't overflow in the (int)(-1U+INT_MIN) - (int)(1U + -1U) case (many
other examples).

We need to do the subtraction in an unsigned_type_for (type) instead and only
cast to type at the end.

For the POINTER_PLUS_EXPR case, the explicitly enabled case is only if both @1
and @2 are INTEGER_CSTs with MSB clear which is fine for the widening
conversion to type, but for equal or narrowing one not really sure.

[Bug tree-optimization/80907] [6/7 Regression] False positive: "warning: array subscript is above array bounds"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] False|[6/7 Regression] False
   |positive: "warning: array   |positive: "warning: array
   |subscript is above array|subscript is above array
   |bounds" |bounds"

--- Comment #2 from Jeffrey A. Law  ---
Richi's patches for 83202 fixed this on the trunk.

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Ah, thanks.  Indeed, and this stuff is highly FE specific.

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

[zackw at panix dot com]

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

--- Comment #5 from Zack Weinberg  ---
I was just thinking that other language front-ends might want to offer
spell-checking suggestions with their own rules for which names are/aren't
appropriate to suggest in context, but maybe we can worry about that when it
happens.

[Bug tree-optimization/78496] [7 Regression] Missed opportunities for jump threading

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[7/8 Regression] Missed |[7 Regression] Missed
   |opportunities for jump  |opportunities for jump
   |threading   |threading

--- Comment #13 from Jeffrey A. Law  ---
Fixed on the trunk.   No plans to backport.

[Bug tree-optimization/78496] [7/8 Regression] Missed opportunities for jump threading

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Mon Dec  4 16:14:24 2017
New Revision: 255387

URL: https://gcc.gnu.org/viewcvs?rev=255387=gcc=rev
Log:
PR tree-optimizatin/78496
* gimple-ssa-evrp-analyze.h
(evrp_range_analyzer::get_vr_values): Simplify.
* gimple-ssa-evrp-analyze.c: Corresponding changes.
* tree-ssa-dom.c: Include alloc-pool.h, tree-vrp.h, vr-values.h
and gimple-ssa-evrp-analyze.h.
(dom_opt_dom_walker class): Add evrp_range_analyzer member.
(simplify_stmt_for_jump_threading): Copy a blob of code from
tree-vrp.c to use ranges to simplify statements.
(dom_opt_dom_walker::before_dom_children): Call
evrp_range_analyzer::{enter,record_ranges_from_stmt} methods.
(dom_opt_dom_walker::after_dom_children): Similarly for
evrp_range_analyzer::leave.
(dom_opt_dom_walker::optimize_stmt): Use EVRP ranges to optimize
conditionals.

PR tree-optimization/78496
* gcc.dg/builtin-unreachable-6.c: Disable DOM.
* gcc.dg/builtin-unreachable-6a.c: New test.
* gcc.dg/tree-ssa/20030922-1.c: No longer XFAIL.
* gcc.dg/ssa-dom-branch-1.c: Tweak expected output.

Added:
trunk/gcc/testsuite/gcc.dg/builtin-unreachable-6a.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-evrp-analyze.h
trunk/gcc/gimple-ssa-evrp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-branch-1.c
trunk/gcc/tree-ssa-dom.c

[Bug rtl-optimization/83272] New: Unnecessary mask instruction generated

[slash.tmp at free dot fr]

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

Bug ID: 83272
   Summary: Unnecessary mask instruction generated
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slash.tmp at free dot fr
  Target Milestone: ---

Consider the following testcase:

char foo(unsigned char n)
{
static const char map[16] = "wxyz";
return map[n / 16];
}

gcc-7 -O2 -march=haswell -S testcase.c generates:

foo:
shrb$4, %dil
andl$15, %edi
movzbl  map.2295(%rdi), %eax
ret


On this platform, CHAR_BIT = 8 and UCHAR_MAX = 255
Therefore n / 16 is guaranteed to be less than 16.
Yet, GCC generates an unnecessary mask instruction (andl $15, %edi).

https://gcc.gnu.org/ml/gcc-help/2017-11/msg00102.html

[Bug target/82096] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[vp at gcc dot gnu.org]

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

Vidya Praveen  changed:

   What|Removed |Added

 CC||vp at gcc dot gnu.org

--- Comment #1 from Vidya Praveen  ---
I can't reproduce this on GCC 8.

[Bug c++/83271] const variable previously declared "extern" results in "weak declaration must be public" error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-04
 Ever confirmed|0   |1

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Zack Weinberg from comment #3)
> Maybe name_reserved_for_implementation_p should be a langhook?

I'm only using it in the C/C++ frontends, and the implementation is identical
for both, so I don't think so - unless I'm missing something?  I'm working on a
version of the patch that moves the macro-spellchecking to c-family.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm  ---
...but presumably a question here is "what is the ideal output of the compiler
for that code?", and the answer might be:

constexpr-reinterpret1.C:19:??: error: reinterpret_cast from integer to pointer
   { return *((Inner *)4); }
  ^~

and it ought to be possible to implement that with the more ambitious v3 patch
kit.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[dmalcolm at gcc dot gnu.org]

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

--- Comment #17 from David Malcolm  ---
(In reply to Jakub Jelinek from comment #16)
> David, does your patchset solve this?

The v2 version of the kit
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00880.html
doesn't affect it.

The work-in-progress v3 version of the kit
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01588.html
actually breaks the warning, stopping it from appearing altogether (this turns
out to be one of the regressions mentioned in that post).  I'm investigating
why.

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 4 Dec 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81281
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 42785
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42785=edit
> gcc8-pr81281-test.patch
> 
> This was fixed by r251651 for -fsanitize=undefined.  Attaching testcase in
> patch form.  That said, without -fsanitize=unreachable the bug is still 
> latent.
> If we start just with:
>   int a = (int) (-2024172551 - (long long)ci);
> then we properly fold it into:
>   int a = (int) (2270794745 - (unsigned int) ci);

Yeah, those sanitize_flags_p (SANITIZE_SI_OVERFLOW) "fixes" are always
wrong...  The 2nd hunk looks ok though

[Bug c++/83271] New: const variable previously declared "extern" results in "weak declaration must be public" error

[alexey.salmin at gmail dot com]

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

Bug ID: 83271
   Summary: const variable previously declared "extern" results in
"weak declaration must be public" error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexey.salmin at gmail dot com
  Target Milestone: ---

The following code works well and produces a global read-only symbol:

extern const int x; // typically comes from a header file
const int x = 0;

But if you add a weak attribute, it fails:

extern const int x;
const int __attribute__((weak)) x = 0;

error: weak declaration of ‘x’ must be public

Even though "const" implies internal linkage in C++, the standard explicitly
makes an exception for names that were previously declared "extern" (see C++17
6.5 "Program and linkage"). The definition in question is already "public", it
should work without the "extern" specifier.

I've encountered this issue with g++ 6.4.0 20171026 (Debian 6.4.0-9) on
x86_64-linux-gnu. It seems to be reproducible with all g++ versions available
on godbolt.org (from 4.4 to 8.0 trunk).

[Bug sanitizer/81281] [6/7/8 Regression] UBSAN: false positive, dropped promotion to long type.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 42785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42785=edit
gcc8-pr81281-test.patch

This was fixed by r251651 for -fsanitize=undefined.  Attaching testcase in
patch form.  That said, without -fsanitize=unreachable the bug is still latent.
If we start just with:
  int a = (int) (-2024172551 - (long long)ci);
then we properly fold it into:
  int a = (int) (2270794745 - (unsigned int) ci);

[Bug libgomp/83270] [OMP 3.1] implement TASKYIELD

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #1 from Jakub Jelinek  ---
Wrong-code makes no sense, our implementation is valid.  taskyield is just an
optimization hint that we could schedule some other task, but without untied
task that doesn't make much sense, the constraints on what other task can be
scheduled are pretty tight in that case.

[Bug libgomp/83270] New: [OMP 3.1] implement TASKYIELD

[janus at gcc dot gnu.org]

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

Bug ID: 83270
   Summary: [OMP 3.1] implement TASKYIELD
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As noted in the TODO list at https://gcc.gnu.org/wiki/openmp and in
https://gcc.gnu.org/ml/gcc-patches/2011-08/msg00080.html, the implementation of
TASKYIELD is still a stub.

I don't really know what it takes to implement this properly, but it would
definitely be useful to have it.

The function 'GOMP_taskyield' in libgomp/task.c is empty on the current trunk.