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

2017-07-15 Thread vries at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81030

--- Comment #6 from Tom de Vries  ---
There's a call to compute_outgoing_frequencies in find_many_sub_basic_blocks.

But it's not reached for bb4, because STATE(bb4) == BLOCK_TO_SPLIT, and we
trigger the continue here:
...
else
  /* If nothing changed, there is no need to create new BBs.  */
  if (EDGE_COUNT (bb->succs) == n_succs[bb->index])
continue;

compute_outgoing_frequencies (bb);
  }
...

Commenting out the else clause gets rid of the ICE.

[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

2017-07-15 Thread thomas.petazz...@free-electrons.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401

--- Comment #4 from Thomas Petazzoni  ---
Any input?

I'm facing a similar problem with the gpsd software: on gcc 6.x and gcc 7.x,
one file fails to build with an ICE:

rtcm2_json.c: In function 'json_rtcm2_read':
rtcm2_json.c:258:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026

You need the combination of -O2 and -fPIC for the bug to appear. If either -O2
or -fPIC are omitted, the builds works fine:

gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -fPIC -c -x c rtcm2_json.os 
gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -O2  -c -x c rtcm2_json.os 
gpsd-3.16$ microblazeel-buildroot-linux-uclibc-gcc -O2 -fPIC -c -x c
rtcm2_json.os 
rtcm2_json.c: In function 'json_rtcm2_read':
rtcm2_json.c:258:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1026
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I'll attach rtcm2_json.os (preprocessed source code) to ease reproduction of
the build problem.

[Bug target/69401] gcc 5.3.0/6.1.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027

2017-07-15 Thread thomas.petazz...@free-electrons.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401

--- Comment #5 from Thomas Petazzoni  ---
Created attachment 41764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41764&action=edit
Pre-processed code from gpsd

Code from gpsd that triggers an ICE on Microblaze when building with -O2 -fPIC.

[Bug go/81451] New: missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

2017-07-15 Thread mfe at live dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451

Bug ID: 81451
   Summary: missing futex check -
libgo/runtime/thread-linux.c:12:0 futex.h:13:12:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘long’
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mfe at live dot de
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 41765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41765&action=edit
futex of host system

the exact version of GCC:
gcc-7.1.0

the system type:
NetgearReadyNAS Duo
(http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS)

the options given when GCC was configured/built:
configure CC=/opt/gcc-4.6/bin/gcc CXX=/opt/gcc-4.6/bin/g++
--enable-languages=c,c++,go --prefix=/opt/gcc-7.1  --with-cpu=v7
--with-mpc=/usr/local  --with-mpfr=/usr/local --with-gmp=/usr/local
--with-isl=/usr/local/ --disable-libstdcxx-pch 

the complete command line that triggers the bug;
/usr/local/bin/make

the compiler output (error messages, warnings, etc.);
[...]
/bin/sh ./libtool  --tag=CC   --mode=compile /media/gcc-7.1-compiled/./gcc/xgcc
-B/media/gcc-7.1-compiled/./gcc/ -B/opt/gcc-7.1/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-7.1/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I../../../gcc-7.1.0/libgo  -I ../../../gcc-7.1.0/libgo/runtime
-I../../../gcc-7.1.0/libgo/../libffi/include -I../libffi/include -pthread 
-fexceptions -fnon-call-exceptions -fplan9-extensions  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Werror   -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../gcc-7.1.0/libgo/../libgcc -I
../../../gcc-7.1.0/libgo/../libbacktrace -I ../../gcc/include -g -O2 -MT
thread-linux.lo -MD -MP -MF .deps/thread-linux.Tpo -c -o thread-linux.lo `test
-f 'runtime/thread-linux.c' || echo
'../../../gcc-7.1.0/libgo/'`runtime/thread-linux.c
libtool: compile:  /media/gcc-7.1-compiled/./gcc/xgcc
-B/media/gcc-7.1-compiled/./gcc/ -B/opt/gcc-7.1/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-7.1/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-7.1/sparc-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-7.1.0/libgo -I ../../../gcc-7.1.0/libgo/runtime
-I../../../gcc-7.1.0/libgo/../libffi/include -I../libffi/include -pthread
-fexceptions -fnon-call-exceptions -fplan9-extensions -Wall -Wextra
-Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../gcc-7.1.0/libgo/../libgcc -I
../../../gcc-7.1.0/libgo/../libbacktrace -I ../../gcc/include -g -O2 -MT
thread-linux.lo -MD -MP -MF .deps/thread-linux.Tpo -c
../../../gcc-7.1.0/libgo/runtime/thread-linux.c  -fPIC -DPIC -o
.libs/thread-linux.o
In file included from ../../../gcc-7.1.0/libgo/runtime/thread-linux.c:12:0:
/usr/include/linux/futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘long’
 asmlinkage long sys_futex(u32 __user *uaddr, int op, int val,
^~~~
make[4]: *** [Makefile:1944: thread-linux.lo] Error 1

I'm not sure, but it looks like gcc is expecting a newer version of futex.h
than the host system can provide?

I attached the futex header of the host system which is running the Linux
kernel 2.6.17.14.

Maybe --disable-linux-futex would fix the issue? Is it possible to add manual
the configure parameter --disable-linux-futex afterwards to the libgo
dictionary without reconfiguring and recompiling the current gcc?

[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack

2017-07-15 Thread vittorio.romeo at outlook dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180

Vittorio Romeo  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #4 from Vittorio Romeo  ---
Experienced this bug today. Another example + information available here:
https://stackoverflow.com/questions/45117719

Possibly related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

2017-07-15 Thread ian at airs dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451

--- Comment #1 from Ian Lance Taylor  ---
There does seem to be something wrong with your linux/futex.h, which is much
shorter than the one on my system.  But it is also true that the file where the
error occurs no longer needs to #include .  You should just
remove the #include and carry on.  I'll commit a more comprehensive fix to
mainline.

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

2017-07-15 Thread sch...@linux-m68k.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451

--- Comment #2 from Andreas Schwab  ---
That's a stone-age version from linux 2.5.70.

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

2017-07-15 Thread mfe at live dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81451

--- Comment #3 from martin  ---
>You should just remove the #include and carry on.  
Thanks, that worked for me.

[Bug ada/81446] Building Ada on Linux m68k fails due to missing No_Elaboration_Code_All

2017-07-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Jul 15 17:01:03 2017
New Revision: 250224

URL: https://gcc.gnu.org/viewcvs?rev=250224&root=gcc&view=rev
Log:
PR ada/81446
* system-linux-m68k.ads: Add pragma No_Elaboration_Code_All.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/system-linux-m68k.ads

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Jul 15 17:01:08 2017
New Revision: 250225

URL: https://gcc.gnu.org/viewcvs?rev=250225&root=gcc&view=rev
Log:
PR ada/81446
* system-linux-m68k.ads: Add pragma No_Elaboration_Code_All.
(Backend_Overflow_Checks): Set to True.

Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/system-linux-m68k.ads

[Bug ada/81446] Building Ada on Linux m68k fails due to missing No_Elaboration_Code_All

2017-07-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Jul 15 17:01:03 2017
New Revision: 250224

URL: https://gcc.gnu.org/viewcvs?rev=250224&root=gcc&view=rev
Log:
PR ada/81446
* system-linux-m68k.ads: Add pragma No_Elaboration_Code_All.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/system-linux-m68k.ads

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Sat Jul 15 17:01:08 2017
New Revision: 250225

URL: https://gcc.gnu.org/viewcvs?rev=250225&root=gcc&view=rev
Log:
PR ada/81446
* system-linux-m68k.ads: Add pragma No_Elaboration_Code_All.
(Backend_Overflow_Checks): Set to True.

Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/system-linux-m68k.ads

[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

2017-07-15 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331

--- Comment #9 from Jan Hubicka  ---
OK, found it.  The problem is in EH table entries like:

.uleb128 .LEHB8-.LCOLDB1
.uleb128 .LEHE8-.LEHB8
.uleb128 .L16-.LCOLDB1
.uleb128 0x1

Now the third entry is landing pad.  If L16 happens to be the first label of
cold section then .L16-.LCOLDB1 == 0. In this case it is misinterpreted by the
runtime as no landing pad and EH is not delivered.

I suppose we can always arrange cold sections to not start by EH receiver...

Honza

[Bug ada/81446] building Ada fails due to missing No_Elaboration_Code_All

2017-07-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.2
Summary|Building Ada on Linux m68k  |building Ada fails due to
   |fails due to missing|missing
   |No_Elaboration_Code_All |No_Elaboration_Code_All

--- Comment #4 from Eric Botcazou  ---
Thanks, applied.

[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

2017-07-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #10 from Eric Botcazou  ---
This also happens for a couple of ACATS tests on Linux.

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

2017-07-15 Thread bernd.edlinger at hotmail dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361

--- Comment #8 from Bernd Edlinger  ---
It looks like -m32 simply generates less diagnostics than
with -m64, this has probably nothing to do with pentium2.


gcc -m32 -fsanitize=float-cast-overflow -O2 float-cast-overflow-1.c
./a.out 2> test-32.txt
gcc -m64 -fsanitize=float-cast-overflow -O2 float-cast-overflow-1.c
./a.out 2> test-64.txt
diff -u test-32.txt test-64.txt 
--- test-32.txt 2017-07-15 19:50:01.758377541 +0200
+++ test-64.txt 2017-07-15 19:50:17.444378403 +0200
@@ -79,6 +79,11 @@
 float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
 float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
 float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
+float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
+float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
+float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
+float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
+float-cast-overflow-1.c:80:3: runtime error: value 9.22337e+18 is outside the
range of representable values of type 'long long int'
 float-cast-overflow-1.c:81:3: runtime error: value nan is outside the range of
representable values of type 'long long int'
 float-cast-overflow-1.c:81:3: runtime error: value -nan is outside the range
of representable values of type 'long long int'
 float-cast-overflow-1.c:81:3: runtime error: value inf is outside the range of
representable values of type 'long long int'
@@ -86,6 +91,10 @@
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
+float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
+float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
+float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
+float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'
 float-cast-overflow-1.c:85:3: runtime error: value 1.84467e+19 is outside the
range of representable values of type 'long long unsigned int'

[Bug tree-optimization/81452] New: warn on realloc(p, 0)

2017-07-15 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81452

Bug ID: 81452
   Summary: warn on realloc(p, 0)
   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: ---

C11 DR 400 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400)
points out a problem with calling realloc(p, 0).  In response to the DR,
calling realloc with a size of zero has been deprecated in C17.  Enhancing GCC
to issue a warning for this case would help detect the problem.  See also Glibc
bug number 12547 (https://sourceware.org/bugzilla/show_bug.cgi?id=12547) and
Austin Group defect number 400 (http://austingroupbugs.net/view.php?id=400).

See also GCC bug 56370 for another request for a warning related to another
realloc misuse.

[Bug tree-optimization/81452] warn on realloc(p, 0)

2017-07-15 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81452

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
URL||http://www.open-std.org/jtc
   ||1/sc22/wg14/www/docs/summar
   ||y.htm#dr_400
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56370
   Severity|normal  |enhancement

[Bug go/56827] Building Go support for gcc 4.8.0 fails on Linux: undefined type ‘SockFilter’

2017-07-15 Thread mfe at live dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56827

martin  changed:

   What|Removed |Added

 CC||mfe at live dot de

--- Comment #3 from martin  ---
I think I ran into the same issue? 

the exact version of GCC:
gcc-7.1.0

the system type:
NetgearReadyNAS Duo
(http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS)

the options given when GCC was configured/built:
configure CC=/opt/gcc-4.6/bin/gcc CXX=/opt/gcc-4.6/bin/g++
--enable-languages=c,c++,go --prefix=/opt/gcc-7.1  --with-cpu=v7
--with-mpc=/usr/local  --with-mpfr=/usr/local --with-gmp=/usr/local
--with-isl=/usr/local/ --disable-libstdcxx-pch 

the complete command line that triggers the bug;
/usr/local/bin/make

the compiler output (error messages, warnings, etc.);
[...]
ruct.go libcalls.go sysinfo.go syscall_arch.go epoll.go  -fPIC -o
.libs/syscall.o
../../../gcc-7.1.0/libgo/go/syscall/exec_linux.go:197:27: error: reference to
undefined name ‘SYS_UNSHARE’
   _, _, err1 = RawSyscall(SYS_UNSHARE, sys.Unshareflags, 0, 0)
   ^
../../../gcc-7.1.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error:
reference to undefined name ‘_AT_FDCWD’
  err = utimensat(_AT_FDCWD, path, (*[2]Timespec)(unsafe.Pointer(&ts[0])), 0)
  ^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type ‘SockFilter’
 func LsfStmt(code, k int) *SockFilter {
^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type ‘SockFilter’
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:74:8: error: use of undefined
type ‘SockFprog’
  var p SockFprog
^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:75:3: error: reference to
field ‘Len’ in object which has no fields or methods
  p.Len = uint16(len(i))
   ^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:76:3: error: reference to
field ‘Filter’ in object which has no fields or methods
  p.Filter = (*SockFilter)(unsafe.Pointer(&i[0]))
   ^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:76:15: error: reference to
undefined name ‘SockFilter’
  p.Filter = (*SockFilter)(unsafe.Pointer(&i[0]))
   ^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:76:14: error: expected pointer
  p.Filter = (*SockFilter)(unsafe.Pointer(&i[0]))
  ^
../../../gcc-7.1.0/libgo/go/syscall/socket_linux.go:173:22: error: reference to
undefined name ‘SizeofIPv6MTUInfo’
  vallen := Socklen_t(SizeofIPv6MTUInfo)
  ^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type ‘SockFilter’
 func LsfStmt(code, k int) *SockFilter {
^
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type ‘SockFilter’
../../../gcc-7.1.0/libgo/go/syscall/lsf_linux.go:14:28: error: use of undefined
type ‘SockFilter’
../../../gcc-7.1.0/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type ‘IPv6MTUInfo’
 func GetsockoptIPv6MTUInfo(fd, level, opt int) (*IPv6MTUInfo, error) {
  ^
../../../gcc-7.1.0/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type ‘IPv6MTUInfo’
make[4]: *** [Makefile:3331: syscall.lo] Error 1

[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

2017-07-15 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331

--- Comment #11 from Jan Hubicka  ---
Created attachment 41766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41766&action=edit
Patch I am testing

Hi,
this patch adds sanity check that turns the nasty wrong code issue into ICE and
a hack to bb-reorder that should prevent it from placing EH landing pads very
first.  I am not quite sure this is robust enough, but can't think of better
fix. We may end up outputting extra NOP in case we fail to find right order.

Honza

[Bug c/81453] New: relational expression involving null pointer not diagnosed with -Wall

2017-07-15 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453

Bug ID: 81453
   Summary: relational expression involving null pointer not
diagnosed with -Wall
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C, relational expressions are defined only for pointers to the same object
or array.  Using a null pointer in such expressions is undefined.  Using a null
pointer constant in a relational expression is a common mistake, yet GCC only
diagnoses such uses with -Wextra or -Wpedantic but not with -Wall.  For
example, the following doesn't trigger a warning unless -Wextra is used, even
though the if statement is eliminated because the comparison is false
regardless of the value of i.

The history of the warning suggests that r9580 enabled it under -Wextra in
addition to -pedantic, but the commit comment indicates that -Wall may have
been intended.  Unfortunately, no test was added at the time to break the tie.

$ cat a.c && gcc -O2 -S -Wall a.c
int f (int *i)
{
  if (i < 0)
return -1;
  return 1;
}

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

2017-07-15 Thread daniel.kruegler at googlemail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162

--- Comment #14 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > Richard also says the overload shouldn't exist and is a bug, but the
> > overload has to exist, because the C++17 draft is defective.
> 
> That's https://wg21.link/lwg2946

The problem here is that the current gcc implementation differs from the LWG
2949 wording. The wording suggests to use

template
basic_string& operator=(const T& t);

but the existing gcc approach uses effectively a by-value signature:

template
basic_string& operator=(T t);

In the example code, the model type llvm::cl::opt is not copy-constructible,
but the constraints accept it, because it is (a) convertible to
std::string_view (Because it inherits from std::string) and (b) it is not
convertible to char*. Now after acceptance of the constraints, the template
signature is instantiated, because it is a (slightly) better match than the
copy_assignment operator of std::string. When this has happened, the compile
error arises, because it is attempted to call the deleted (and private) copy
constructor of llvm::cl::opt.

It seems to me that it would suffice to change the signature of the constrained
assignment operator to use const T& instead of T, as suggested by the issue
resolution proposal.

Here is a reproducer for the situation:

#include 

template 
class opt : public DataType
{
  opt(const opt &) = delete;
  opt &operator=(const opt &) = delete;
public:
  opt() {}
};

int main() 
{
  opt PGOTestProfileFile;
  std::string ProfileFileName;
  ProfileFileName = PGOTestProfileFile;
}

Here is a minimized emulation of basic_string that shows that the suggested fix
should work (Please uncomment '#define USE_FIX' below):

#include 
#include 
#include 
#include 

namespace xstd {

  template>
  struct basic_string_view
  {
 using traits_type = Traits;
 using size_type = std::size_t;

 constexpr basic_string_view() noexcept
  : len{0}, str{nullptr}
  {}

 constexpr basic_string_view(const CharT* str) 
   : len{str == nullptr ? 0 : traits_type::length(str)},
 str{str}
  {}

  constexpr size_type
  size() const noexcept
  { return this->len; }

  constexpr const CharT*
  data() const noexcept
  { return this->str; }

  private:
 size_type len;
 const CharT* str;
  };

  template>
  struct basic_string
  {
  private:
  using sv_type = basic_string_view;

  template
  using If_sv = std::enable_if_t<
 std::__and_<
   std::is_convertible,
   std::__not_>
 >::value,
 Res>;

  public:

  using size_type = std::size_t;

  static const size_type npos = static_cast(-1);

  basic_string&
  operator=(const basic_string& str);

  basic_string&
  operator=(const CharT* s);

  basic_string&
  operator=(CharT c);

  basic_string&
  operator=(std::initializer_list);

  basic_string&
  operator=(basic_string&& str);

//#define USE_FIX  

#ifndef USE_FIX
  template
  If_sv
  operator=(T sv);
#else
  template
  If_sv
  operator=(const T& sv);
#endif

 operator sv_type() const noexcept;

};

using string = basic_string;

}

namespace llvm {
namespace cl {

template 
class opt_storage : public DataType
{
};

template 
class opt : public opt_storage 
{
  opt(const opt &) = delete;
  opt &operator=(const opt &) = delete;
public:
  opt();
};

}
}

using namespace llvm;
cl::opt
PGOTestProfileFile;

namespace {
class PGOInstrumentationUseLegacyPass {
  PGOInstrumentationUseLegacyPass(xstd::string)
  {
  ProfileFileName = PGOTestProfileFile;
  }
  xstd::string ProfileFileName;
};
}

int main() 
{
}

[Bug ada/81424] [7 regression] internal error on GPRbuild with -O2

2017-07-15 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81424

Eric Botcazou  changed:

   What|Removed |Added

 Target||i686-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-15
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|gnat bugbox on i386 |[7 regression]  internal
   ||error on GPRbuild with -O2
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Confirmed, but how can it block anything since the workaround is trivial?

[Bug tree-optimization/81454] New: missing strcmp optimization on duplicate call with an unknown string

2017-07-15 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81454

Bug ID: 81454
   Summary: missing strcmp optimization on duplicate call with an
unknown string
   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 second call to strcmp() in the following function is redundant.: either the
first call returns zero and the second call isn't reached, or it returns a
non-zero value in which case so must the second.  The second call can be safely
eliminated.  This is a missed optimization opportunity.

This type of duplicate comparison is often a logic error.  In addition to
optimizing the redundant call, GCC should issue a warning pointing the
redundancy out.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c

const char foo[] = "123";
const char bar[] = "123";

int f (const char *s)
{
  if (!__builtin_strcmp (s, foo))
return 0;
  if (!__builtin_strcmp (s, bar))   // redundant, can be eliminated
return 1;

  return -1;
}

;; Function f (f, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=2)

Removing basic block 4
Removing basic block 6
f (const char * s)
{
  int _1;
  int _2;
  int _3;

   [100.00%] [count: INV]:
  _1 = __builtin_strcmp (s_5(D), &foo);
  if (_1 == 0)
goto ; [34.00%] [count: INV]
  else
goto ; [66.00%] [count: INV]

   [66.00%] [count: INV]:
  _2 = __builtin_strcmp (s_5(D), &bar);
  if (_2 == 0)
goto ; [96.19%] [count: INV]
  else
goto ; [3.81%] [count: INV]

   [63.49%] [count: INV]:

   [100.00%] [count: INV]:
  # _3 = PHI <_1(2), 1(4), -1(3)>
  return _3;

}