[Bug lto/78908] [6/7 Regression] lto1: internal compiler error: in lto_read_decls, at lto/lto.c:1814

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r231640.

[Bug fortran/59781] [5/6 Regression] [F03] Incorrect initialisation of derived type

2016-12-23 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

--- Comment #13 from janus at gcc dot gnu.org ---
Also the dump for comment 1 looks ok on trunk, showing the correct
initialization for the c_ptr variable:

{
  void * c_ptr.1;

  c_ptr.1 = 0B;
  dsfmt_t.0.dsfmt_state = c_ptr.1;
}

If one can identify the commit that fixed it on trunk, it could be backported
to the release branches.

[Bug tree-optimization/78910] New: [7 Regression] Wrong print-return-value for a negative number

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78910

Bug ID: 78910
   Summary: [7 Regression] Wrong print-return-value for a negative
number
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The issue can be seen in ICU package test-suite, in section decorated:
"Get really crazy with the formatting."

$ cat /tmp/printf-test.c
int main()
{
  char b[128];
  int l = __builtin_sprintf (b, "%.2d", -1);
  __builtin_printf ("b: '%s', length: %d\n", b, l);
  if (l != 3)
__builtin_abort ();
  return 0;
}

$ gcc /tmp/printf-test.c -O2 && ./a.out 
b: '-01', length: 2
Aborted (core dumped)

[Bug tree-optimization/78910] [7 Regression] Wrong print-return-value for a negative number

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78910

Martin Liška  changed:

   What|Removed |Added

  Known to work||6.2.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug c/78911] New: Infinite loop while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread t.artem at mailcity dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

Bug ID: 78911
   Summary: Infinite loop while trying to compile server.c from
Wine-2.0-rc2
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

Created attachment 40408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40408&action=edit
Sources

gcc -c -o server.o server.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_
-D_REENTRANT -fPIC -Wall \
  -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
-Wignored-qualifiers \
  -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits
-Wunused-but-set-parameter -Wvla \
  -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -O2
-march=pentium-m -m32 -pipe -D__i386__

gcc --version
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)

gcc -c -o server.o server.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_
-D_REENTRANT -fPIC -Wall \
>   -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body 
> -Wignored-qualifiers \
>   -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits 
> -Wunused-but-set-parameter -Wvla \
>   -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -O2 
> -march=pentium-m -m32 -pipe -D__i386__ -v -save-temps

gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-o' 'server.o' '-I' '.' '-I' '../../include' '-D'
'__WINESRC__' '-D' '_NTSYSTEM_' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe'
'-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wempty-body'
'-Wignored-qualifiers' '-Wshift-overflow=2' '-Wstrict-prototypes'
'-Wtype-limits' '-Wunused-but-set-parameter' '-Wvla' '-Wwrite-strings'
'-Wpointer-arith' '-Wlogical-op' '-fno-omit-frame-pointer' '-O2'
'-march=pentium-m' '-m32' '-pipe' '-D' '__i386__' '-v' '-save-temps'
 /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -E -quiet -v -I . -I
../../include -imultilib 32 -D __WINESRC__ -D _NTSYSTEM_ -D _REENTRANT -D
__i386__ server.c -march=pentium-m -m32 -Wall -Wdeclaration-after-statement
-Wempty-body -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes
-Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith
-Wlogical-op -fPIC -fno-strict-aliasing -fno-omit-frame-pointer -O2
-fpch-preprocess -o server.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.2.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../include
 /usr/lib/gcc/x86_64-redhat-linux/6.2.1/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-o' 'server.o' '-I' '.' '-I' '../../include' '-D'
'__WINESRC__' '-D' '_NTSYSTEM_' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe'
'-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wempty-body'
'-Wignored-qualifiers' '-Wshift-overflow=2' '-Wstrict-prototypes'
'-Wtype-limits' '-Wunused-but-set-parameter' '-Wvla' '-Wwrite-strings'
'-Wpointer-arith' '-Wlogical-op' '-fno-omit-frame-pointer' '-O2'
'-march=pentium-m' '-m32' '-pipe' '-D' '__i386__' '-v' '-save-temps'
 /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -fpreprocessed server.i -quiet
-dumpbase server.c -march=pentium-m -m32 -auxbase-strip server.o -O2 -Wall
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers
-Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter
-Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -version -fPIC
-fno-strict-aliasing -fno-omit-frame-pointer -o server.s
GNU C11 (GCC) version 6.2.1 20160916 (Red Hat 6.2.1-2) (x86_64-redhat-linux)
compiled by GNU C version 6.2.1 20160916 (Red Hat 6.2.1-2), GMP version
6.1.1, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13
warning: MPFR header version 3.1.4 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.2.1 20160916 (Red Hat 6.2.1-2) (x86_64-redhat-linu

[Bug middle-end/78911] Infinite loop while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread t.artem at mailcity dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

--- Comment #1 from Artem S. Tashkinov  ---
Update:

various -march variants have no effect.

-O3 : still hangs

-Os : compiles

[Bug fortran/59781] [5/6 Regression] [F03] Incorrect initialisation of derived type

2016-12-23 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

--- Comment #14 from Dominique d'Humieres  ---
> Also the dump for comment 1 looks ok on trunk, showing the correct
> initialization for the c_ptr variable:
>
> {
>   void * c_ptr.1;
>
>   c_ptr.1 = 0B;
>   dsfmt_t.0.dsfmt_state = c_ptr.1;
> }
>
> If one can identify the commit that fixed it on trunk, it could be backported
> to the release branches.

AFAICT the above piece of dump appeared between revisions r241883 (2016-11-06,
none) and r241924 (2016-11-07, present), likely r241885. If I am correct, I am
not sure that the commit qualifies for back port.

[Bug fortran/59781] [5/6 Regression] [F03] Incorrect initialisation of derived type

2016-12-23 Thread janus at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #14)
> AFAICT the above piece of dump appeared between revisions r241883
> (2016-11-06, none) and r241924 (2016-11-07, present), likely r241885.

Yes, very likely. Thanks for pinpointing this, Dominique.


> If I
> am correct, I am not sure that the commit qualifies for back port.

Andre, do you think it would be reasonable to backport r241885?

[Bug middle-end/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

Martin Liška  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-23
 CC||marxin at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
Summary|Infinite loop at -O2/O3 |[5/6/7 Regression] Infinite
   |optimization levels while   |loop at -O2/O3 optimization
   |trying to compile server.c  |levels while trying to
   |from Wine-2.0-rc2   |compile server.c from
   ||Wine-2.0-rc2
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r221983. I'm reducing the test-case.

[Bug middle-end/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Spins in lra:

  32.64%  cc1[.] lra_create_live_ranges_1
  10.52%  cc1[.] lra_assign
   7.57%  cc1[.] bitmap_set_bit

Trunk works fine for me.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

--- Comment #4 from Martin Liška  ---
The mentioned revision is probably not probably the culprit.
Reduced test-case:

$ cat tc.i
a, b, d, e;
*c;
static interlocked_cmpxchg64 (long long *p1)
{
  __sync_val_compare_and_swap (p1, b, a);
}
get_cached_fd ()
{
  if (!c)
return;
  e = interlocked_cmpxchg64 (&c[d]);
}

$ timeout 10 gcc -O3 -march=pentium-m -m32 -c  -fPIC -Wall  
-fno-strict-aliasing -fno-omit-frame-pointer tc.i
[triggers time-out]

Can you see it also on trunk?

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #4)
> Can you see it also on trunk?

Yes, but only with -O3.

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

2016-12-23 Thread jdanek at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763

Jiri Danek  changed:

   What|Removed |Added

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

--- Comment #10 from Jiri Danek  ---
I am trying to compile qpid-proton with gcc snapshot (again in docker,
https://hub.docker.com/r/jdanekrh/nightly-gccgo-trunk-docker-image/) and as far
as I can tell, the go binding package does compile successfully. So I'd say
this bug is resolved.

What _does_ fail though is compilation of the go sample program which uses the
binding package. It is quite likely this is a bug in the build script which was
never before tested with gccgo.

FYI, the compilation error when compiling the sample program

make[2]: Entering directory '/qpid-proton/build'
/usr/bin/python /qpid-proton/proton-c/env.py --
GOPATH=/qpid-proton/proton-c/bindings/go
CGO_CFLAGS=-I/qpid-proton/proton-c/include\
-I/qpid-proton/build/proton-c/include CGO_LDFLAGS=-L/qpid-proton/build/proton-c
PN_INTEROP_DIR=/qpid-proton/tests/interop /usr/local/bin/go build -gccgoflags
-Wl,-rpath=/qpid-proton/build/proton-c -o
/qpid-proton/build/examples/go/electron/broker
/qpid-proton/examples/go/electron/broker.go
# command-line-arguments
../examples/go/electron/broker.go:30:9: error: import file '../util' not found
  "../util"
 ^
../examples/go/electron/broker.go:69:16: error: expected package
  queuesutil.Queues   // A collection of queues.
^
../examples/go/electron/broker.go:79:8: error: expected package
  q util.Queue
^
../examples/go/electron/broker.go:57:14: error: reference to undefined name
'util'
   queues:util.MakeQueues(*qsize),
  ^
../examples/go/electron/broker.go:97:4: error: reference to undefined name
'util'
util.Debugf("Accept error: %v", err)
^
../examples/go/electron/broker.go:102:3: error: reference to undefined name
'util'
   util.Debugf("Accepted %v", c)
   ^
../examples/go/electron/broker.go:137:3: error: reference to undefined name
'util'
   util.Debugf("incoming: %v", in)
   ^
../examples/go/electron/broker.go:115:2: error: range clause must have array,
slice, string, map, or channel type
  for in := range c.connection.Incoming() {
  ^
../examples/go/electron/broker.go:139:2: error: reference to undefined name
'util'
  util.Debugf("incoming closed: %v", c.connection)
  ^
../examples/go/electron/broker.go:147:4: error: reference to undefined name
'util'
util.Debugf("%v: received %v", receiver, util.FormatMessage(rm.Message))
^
../examples/go/electron/broker.go:147:45: error: reference to undefined name
'util'
util.Debugf("%v: received %v", receiver, util.FormatMessage(rm.Message))
 ^
../examples/go/electron/broker.go:151:4: error: reference to undefined name
'util'
util.Debugf("%v error: %v", receiver, err)
^
../examples/go/electron/broker.go:162:4: error: reference to undefined name
'util'
util.Debugf("%v closed: %v", sender, sender.Error())
^
../examples/go/electron/broker.go:168:4: error: reference to undefined name
'util'
util.Debugf("%v: sent %v", sender, util.FormatMessage(m))
^
../examples/go/electron/broker.go:168:39: error: reference to undefined name
'util'
util.Debugf("%v: sent %v", sender, util.FormatMessage(m))
   ^
../examples/go/electron/broker.go:185:13: error: invalid type for make function
  sentMap := make(map[sentMessage]bool)
 ^
../examples/go/electron/broker.go:196:4: error: argument 1 must be a map
delete(sentMap, sm)
^
../examples/go/electron/broker.go:199:5: error: reference to undefined name
'util'
 util.Debugf("message %v put back, status %v, error %v",
 ^
../examples/go/electron/broker.go:200:6: error: reference to undefined name
'util'
  util.FormatMessage(sm.m), outcome.Status, outcome.Error)
  ^
../examples/go/electron/broker.go:115:6: error: invalid type for range clause
  for in := range c.connection.Incoming() {
  ^
../examples/go/electron/broker.go:167:3: error: expected channel
   case m := <-q:
   ^
../examples/go/electron/broker.go:188:3: error: expected channel
   case sm, ok := <-b.sent: // A local sender records that it has sent a
message.
   ^
../examples/go/electron/broker.go:194:3: error: expected channel
   case outcome := <-b.acks: // The message outcome is available
   ^
../examples/go/electron/broker.go:167:15: error: expected channel
   case m := <-q:
   ^
../examples/go/electron/broker.go:188:21: error: expected channel
   case sm, ok := <-b.sent: // A local sender records that it has sent a
message.
 ^
../examples/go/electron/broker.go:194:22: error: expected channel
   case outcome := <-b.acks: // The message outcome is available
  ^
make[2]: *** [examples/go

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911

--- Comment #6 from Martin Liška  ---
Created attachment 40409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40409&action=edit
head -n70 tc.i.274r.reload

So the problem is older than r221983.

[Bug go/78912] New: Relative import when compiling with `go build` is not resolved

2016-12-23 Thread jdanek at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78912

Bug ID: 78912
   Summary: Relative import when compiling with `go build` is not
resolved
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: jdanek at redhat dot com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 40410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40410&action=edit
reproducer_project.zip

The attached project compiles with go tool

$ go version
go version go1.7.3 linux/amd64
$ GOPATH=`pwd` go build electron/broker.go
$ ./broker
Print from broker.go
Print from util.go

It does not compile with gccgo (I am running gcc in Docker)

$ docker run -v `pwd`:/mnt --rm -it jdanekrh/nightly-gccgo-trunk-docker-image
root@d454c37d5d3e:/# cd /mnt
root@d454c37d5d3e:/mnt# go version
go version go1.7.1 gccgo (GCC) 7.0.0 20161223 (experimental) linux/amd64
root@d454c37d5d3e:/mnt# GOPATH=`pwd` go build electron/broker.go
# command-line-arguments
electron/broker.go:4:12: error: import file '../util' not found
 "../util"
^
electron/broker.go:10:5: error: reference to undefined name 'util'
 util.PrintSomething()

I have tried setting the -fgo-relative-import-path option, (GOPATH=`pwd` go
build -gccgoflags -fgo-relative-import-path=`pwd`/electron electron/broker.go)
but I could not make it work that way either.

This bug may be similar to https://github.com/golang/go/issues/3759. The
reproducer from that bug compiles fine for me (relative import in that
reproducer starts ./, not ../ like in this case).

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

2016-12-23 Thread jdanek at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763

--- Comment #11 from Jiri Danek  ---
I am opening "Bug 78912 - Relative import when compiling with `go build` is not
resolved" for the relative import error.

[Bug rtl-optimization/78883] [avr] ICE triggered by change to combine.c (r243578)

2016-12-23 Thread vogt at linux dot vnet.ibm.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883

--- Comment #3 from Dominik Vogt  ---
Simplified test case:

void foo (int *p)
{
  int i;
  for (i = 0; i < 5; i++)
{
  if (p[i] & 1)
return;
}
}

$ avr-gcc -S -O1 pr78883.c

[Bug lto/78908] [6/7 Regression] lto1: internal compiler error: in lto_read_decls, at lto/lto.c:1814

2016-12-23 Thread ppalka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908

--- Comment #3 from Patrick Palka  ---
Interesting.  The patch in question just delays overloaded operator call
resolution to template instantiation time as opposed to template definition
time, like what was already being done for regular function calls.  It makes
the compiler more consistent by making uses of overloaded operators within
templates behave the same as explicit calls to the operatorX() functions with
respect to overload resolution.  I'll try to understand this regression.

First off if I replace the uses of overloaded operators with explicit calls to
the operatorX() functions then the ICE goes away.  In fact it looks like only
the use of << on line 62 needs to be kept order to trigger the ICE.

--- a/78908-orig.C
+++ b/78908.C
@@ -51,7 +51,7 @@ struct H {
   template  void insert(T const &);
   decltype(__trans_tmp_4) wep_;
 };
-template  void H::insert(T const &) { wep_->emplace(); }
+template  void H::insert(T const &) {
wep_.operator->()->emplace(); }
 template  struct L {
   template  void insert(T const &);
   I backend_;
@@ -62,7 +62,7 @@ template  template  void
L::insert(T const &p1) {
 G> b, c;
 template 
 void O::on_inner_remove(unsigned long, A const &p2) try {
-  b << p2.depth;
+  operator<< (b, p2.depth);
 } catch (...) {
 }
 struct M;
@@ -84,7 +84,7 @@ template  int const
*N::process() {
 }
 template 
 void N::process(int const &, int const &, unsigned short) try {
-  c << expected_detail_level_;
+  operator<<(c, expected_detail_level_);
 } catch (...) {
 }
 template

[Bug c/78380] GCC crash with internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025

2016-12-23 Thread mario-baumann at web dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78380

Mario Baumann  changed:

   What|Removed |Added

 CC||mario-baumann at web dot de

--- Comment #3 from Mario Baumann  ---
Created attachment 40411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40411&action=edit
simple testcase

[Bug c/78380] GCC crash with internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025

2016-12-23 Thread mario-baumann at web dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78380

--- Comment #4 from Mario Baumann  ---
Hi, have a similar problem with
/Gcc/6.3.0/bin/gcc -c foo.c -m32 -mfpmath=sse

> /Gcc/6.3.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Gcc/6.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/Gcc/6.3.0/libexec/gcc/x86_64-apple-darwin16/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: /Build/zulu/gcc/6.3.0-src/configure --prefix=/Gcc/6.3.0
--build=x86_64-apple-darwin16 --enable-languages=c,c++,fortran --enable-lto
--enable-stage1-checking --enable-libstdcxx-time --disable-nls
--disable-libquadmath --disable-libquadmath-support --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-as=/opt/local/bin/as --with-system-zlib
Thread model: posix
gcc version 6.3.0 (GCC)

[Bug tree-optimization/78913] New: Probably wrong -Wformat-length= error message

2016-12-23 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913

Bug ID: 78913
   Summary: Probably wrong -Wformat-length= error message
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Isolated from fcoe-utils:

$ cat /tmp/sprintf.c
struct buffer
{
  char path[512];
};

int main(int argc, char **argv)
{
  static struct buffer a;
  struct buffer out;
  __builtin_strcpy (a.path, "test");

  __builtin_snprintf (out.path, sizeof (struct buffer), "%s/_\n", a.path);
  __builtin_printf (out.path);
}

$ ./xgcc -B. /tmp/sprintf.c  -Wall -O2 && ./a.out 1
/tmp/sprintf.c: In function ‘main’:
/tmp/sprintf.c:12:61: warning: output may be truncated before the last format
character [-Wformat-length=]
   __builtin_snprintf (out.path, sizeof (struct buffer), "%s/_\n", a.path);
 ^~~
/tmp/sprintf.c:12:3: note: format output between 4 and 515 bytes into a
destination of size 512
   __builtin_snprintf (out.path, sizeof (struct buffer), "%s/_\n", a.path);
   ^~~
test/_

I guess it's bogus as considering that strlen of path would be 512 is kind of
misleading.

Thanks,
Martin

[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-23
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The warning in this case is based on the knowledge that the longest string that
fits into a.path is 511 characters, which given the format string of "%s/_\n"
would result in 515 characters being written in to the the 512 element array
(and characters past the 511th being truncated).

The expectation is that the call be written like so:

  snprintf (out.path, sizeof (struct buffer), "%.508s/_\n", a.path);

I would at some point like to add fixit hints with this suggestion (I'm
tracking the feature request in bug 77831).

One other possibility I considered is adding a new option (distinct from
-Wformat-length) to control the snprintf truncation case.  Yet another possible
"feature" is to distinguish the case when the snprintf return value is used vs
ignored (the latter likely being a bug). Though that wouldn't change anything
in this case.

Let me know your thoughts.

[Bug tree-optimization/78910] Wrong print-return-value for a negative number

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78910

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-23
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Thanks!  Precision gives the minimum number of digits with d, which doesn't
include the sign, so printf("%.2d", -1) should produce the three bytes "-01".

[Bug middle-end/77831] add fixit hints to -Wformat-length

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77831

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-23
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78913
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
See also bug 78913 for another case (similar to bug 77690).

[Bug fortran/59781] [5/6 Regression] [F03] Incorrect initialisation of derived type

2016-12-23 Thread jvdelisle at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #16 from Jerry DeLisle  ---
If it fixes this regression, I do not see why not, unless you suspect it may
regress something else. Just mt 2 cents worth.

[Bug middle-end/78914] New: missing -Wnonnull for a trivial null pointer dereference

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78914

Bug ID: 78914
   Summary: missing -Wnonnull for a trivial null pointer
dereference
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Now that the -Wnonnull warning has been made smarter (bug 17308) it would be
nice if, in addition to calls to functions declared with attribute nonnnull, it
could also diagnose other null pointer dereferences such as the one in the test
case below.  As is evident from __builtin_trap() in the dump, GCC already
"knows" that the pointer being dereferenced is null, but issuing a warning
would help catch that case earlier than at runtime.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout z.c
struct S { int i; };

int foo (struct S *s)
{
  if (s)
return 6;

  return s->i;
}


;; Function foo (foo, funcdef_no=0, decl_uid=1797, cgraph_uid=0,
symbol_order=0)

foo (struct S * s)
{
  int _4;

   [100.00%]:
  if (s_2(D) != 0B)
goto ; [51.18%]
  else
goto ; [48.82%]

   [48.82%]:
  _4 ={v} MEM[(struct S *)0B].i;
  __builtin_trap ();

   [100.00%]:
  return 6;

}

[Bug middle-end/78915] New: missing -Wuninitialized accessing allocated memory

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78915

Bug ID: 78915
   Summary: missing -Wuninitialized accessing allocated memory
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

All three functions in the test case below read uninitialized memory but only
f0 is diagnosed with the -Wuninitialized warning.  All three should be.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
int f0 (void)
{
  int i;

  ++i;

  return i;
}

int f1 (unsigned n)
{
  int *p = (int*)__builtin_alloca (n);

  ++*p;

  return *p;
}

int f2 (unsigned n)
{
  int *p = (int*)__builtin_malloc (n);
  if (!p)
return -1;

  ++*p;

  return *p;
}

z.c: In function ‘f0’:
z.c:5:3: warning: ‘i’ is used uninitialized in this function [-Wuninitialized]
   ++i;
   ^~~

[Bug tree-optimization/78916] New: suboptimal code for x % C1 == C2

2016-12-23 Thread rv at rasmusvillemoes dot dk 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78916

Bug ID: 78916
   Summary: suboptimal code for x % C1 == C2
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rv at rasmusvillemoes dot dk
  Target Milestone: ---

Everything below applies to the case of unsigned operands; signed division is a
whole other matter.

When a is an odd constant, the expression x % a == 0 is equivalent to x*inv(a)
<= ~0U/a, where inv(a) is the mod-2^32 multiplicative inverse of a. More
generally, x % a == b can be rewritten as x*inv(a) - b*inv(a) <= (~0U - b)/a,
where everything but the first multiplication are compile-time constants, and
the comparison is unsigned. gcc seems to always compute the full remainder and
compare that to the RHS.

For example,

int f(unsigned x) { return x % 3 == 0; }

could compile to

  20:   69 ff ab aa aa aa   imul   $0xaaab,%edi,%edi
  26:   31 c0   xor%eax,%eax
  28:   81 ff 55 55 55 55   cmp$0x,%edi
  2e:   0f 96 c0setbe  %al
  31:   c3  retq   

but gcc generates

   0:   89 f8   mov%edi,%eax
   2:   ba ab aa aa aa  mov$0xaaab,%edx
   7:   f7 e2   mul%edx
   9:   d1 ea   shr%edx
   b:   8d 04 52lea(%rdx,%rdx,2),%eax
   e:   39 c7   cmp%eax,%edi
  10:   0f 94 c0sete   %al
  13:   0f b6 c0movzbl %al,%eax
  16:   c3  retq   

If gcc needs to compute the quotient x/a anyway, computing the remainder from
that may be optimal, but in the somewhat realistic case where the quotient is
only used if the division is exact, it's much better to compute the tentative
quotient as above and test that, e.g.

unsigned f(unsigned x);
unsigned g(unsigned x)
{
return (x % 7U == 0) ? f(x / 7U) : 0;
}

should/could be compiled as

unsigned h(unsigned x)
{
return (x * 3067833783U <= (~0U)/7) ? f(x * 3067833783U) : 0;
}

0080 :
  80:   89 f8   mov%edi,%eax
  82:   ba 25 49 92 24  mov$0x24924925,%edx
  87:   f7 e2   mul%edx
  89:   89 f8   mov%edi,%eax
  8b:   29 d0   sub%edx,%eax
  8d:   d1 e8   shr%eax
  8f:   01 c2   add%eax,%edx
  91:   c1 ea 02shr$0x2,%edx
  94:   8d 04 d5 00 00 00 00lea0x0(,%rdx,8),%eax
  9b:   29 d0   sub%edx,%eax
  9d:   39 c7   cmp%eax,%edi
  9f:   74 07   je a8 
  a1:   31 c0   xor%eax,%eax
  a3:   c3  retq   
  a4:   0f 1f 40 00 nopl   0x0(%rax)
  a8:   89 d7   mov%edx,%edi
  aa:   e9 00 00 00 00  jmpq   af 
  af:   90  nop

00b0 :
  b0:   69 ff b7 6d db b6   imul   $0xb6db6db7,%edi,%edi
  b6:   81 ff 24 49 92 24   cmp$0x24924924,%edi
  bc:   76 0a   jbec8 
  be:   31 c0   xor%eax,%eax
  c0:   c3  retq   
  c1:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  c8:   e9 00 00 00 00  jmpq   cd

[Bug middle-end/78917] New: missing -Wnonnull passing null to a nonnull function

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917

Bug ID: 78917
   Summary: missing -Wnonnull passing null to a nonnull function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While experimenting with the enhanced -Wnonnull warning added in GCC 7.0 (bug
17308) I noticed that it fails to detect the following trivial case of  passing
a null pointer to a function declared nonnull.  This is different from bug
78914 where the null pointer is being dereferenced directly.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout z.c
int g (int i, int j)
{
  char *p = i <= 0 ? (char*)0 : "123";
  char *q = 0 != i ? (char*)0 : "4567";
  char *r = i ? q : p;

  return __builtin_strlen (r);
}

z.c: In function ‘g’:
z.c:1:19: warning: unused parameter ‘j’ [-Wunused-parameter]
 int g (int i, int j)
   ^

;; Function g (g, funcdef_no=0, decl_uid=1796, cgraph_uid=0, symbol_order=0)

g (int i, int j)
{
  long unsigned int _1;
  int _7;

   [100.00%]:
  _1 = __builtin_strlen (0B);
  _7 = (int) _1;
  return _7;

}

[Bug c/60256] No -Wuninitialized warning for strcpy copying to self

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-24
 CC||msebor at gcc dot gnu.org
Summary|No -Wuninitialized warning  |No -Wuninitialized warning
   |for strcpy  |for strcpy copying to self
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #7 from Martin Sebor  ---
I'll confirm this on the grounds that a strcpy(s, s) call is invalid because it
violates the strict aliasing rules (strcpy arguments are declared restrict). 
The invalid strcpy(s, s) call should also be diagnosed by -Wrestrict.

The test case seems contrived but I think this type of a bug can easily be
lurking in more complicated code.

[Bug middle-end/78918] New: missing -Wrestrict on memcpy copying over self

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78918

Bug ID: 78918
   Summary: missing -Wrestrict on memcpy copying over self
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Calling memcpy to copy objects that overlap violates the strict aliasing rules
and is undefined.  As the dump below shows, GCC eliminates some such calls
implying it "knows" the objects overlap (even though optimizing undefined code
seems questionable) but it doesn't issue any diagnostic.  With the -Wrestrict
warning GCC should flag at least the basic cases.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wrestrict
-fdump-tree-optimized=/dev/stdout z.c
void f (void *p, void *q, unsigned n)
{
  p = q;
  __builtin_memcpy (p, q, n);
}

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

f (void * p, void * q, unsigned int n)
{
   [100.00%]:
  return;

}

[Bug middle-end/78918] missing -Wrestrict on memcpy copying over self

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78918

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 60256 for a similar case involving strcpy.

[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length

2016-12-23 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913

--- Comment #2 from Martin Sebor  ---
I should have mentioned: the -Wformat-length pass would benefit from the
results of the strlen pass.  It would also benefit from better range
information.  Having the pass run later, after the VRP pass, would improve the
range information but I don't think it will help with the string length info. 
To avoid the warning in this case I suspect the two passes (strlen and sprintf)
would either need to communicate (i.e., strlen would need to somehow expose the
string length data to subsequent passes similarly to how VRP does via the
get_range_info API) or be merged.  It's something I'd like to look into in the
GCC 8 cycle.

[Bug c++/78919] New: Lambdas, default parameters and std::functional cause assembly error

2016-12-23 Thread kirit.saelensminde at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78919

Bug ID: 78919
   Summary: Lambdas, default parameters and std::functional cause
assembly error
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirit.saelensminde at gmail dot com
  Target Milestone: ---

There seems to be some odd interaction with default parameters, lambdas and
std::function.

// Compile with:
//  g++ --std=c++11 -Wall -Wextra bug.cpp
//  g++ --std=c++14 -Wall -Wextra bug.cpp
#include 
#include 

template
void foo(F fn, std::function = [](){}) {
fn();
}

int main() {
foo([](){ std::cout << "First" << std::endl;});
foo([](){ std::cout << "Second" << std::endl;});
}


If the second call to `foo` is removed then it works fine. Otherwise there are
assembler errors like the below:

/tmp/ccwG9slS.s: Assembler messages:
/tmp/ccwG9slS.s:252: Error: symbol `_ZNKUlvE_clEv' is already defined
/tmp/ccwG9slS.s:537: Error: symbol
`_ZSt4moveIRUlvE_EONSt16remove_referenceIT_E4typeEOS3_' is already defined
/tmp/ccwG9slS.s:555: Error: symbol `_ZNSt8functionIFvvEEC2IUlvE_vvEET_' is
already defined
/tmp/ccwG9slS.s:813: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E21_M_not_empty_functionIS1_EEbRKT_'
is already defined
/tmp/ccwG9slS.s:830: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E15_M_init_functorERSt9_Any_dataOS1_'
is already defined
/tmp/ccwG9slS.s:871: Error: symbol
`_ZNSt17_Function_handlerIFvvEUlvE_E9_M_invokeERKSt9_Any_data' is already
defined
/tmp/ccwG9slS.s:894: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation'
is already defined
/tmp/ccwG9slS.s:1122: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E15_M_init_functorERSt9_Any_dataOS1_St17integral_constantIbLb1EE'
is already defined
/tmp/ccwG9slS.s:1151: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E14_M_get_pointerERKSt9_Any_data' is
already defined
/tmp/ccwG9slS.s:1176: Error: symbol
`_ZNSt9_Any_data9_M_accessIPUlvE_EERT_v' is already defined
/tmp/ccwG9slS.s:1196: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E8_M_cloneERSt9_Any_dataRKS3_St17integral_constantIbLb1EE'
is already defined
/tmp/ccwG9slS.s:1225: Error: symbol
`_ZNSt14_Function_base13_Base_managerIUlvE_E10_M_destroyERSt9_Any_dataSt17integral_constantIbLb1EE'
is already defined
/tmp/ccwG9slS.s:1306: Error: symbol
`_ZNKSt9_Any_data9_M_accessIUlvE_EERKT_v' is already defined
/tmp/ccwG9slS.s:1326: Error: symbol `_ZSt11__addressofIKUlvE_EPT_RS2_' is
already defined
/tmp/ccwG9slS.s:1344: Error: symbol `_ZNSt9_Any_data9_M_accessIUlvE_EERT_v'
is already defined


As well as 5.4.1 this bug happens in 6.2.0 and 6.2.1. We've tried this on
Ubuntu versions and Arch linux versions of the compilers.


This looks somewhat similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65919 but the errors appear quite
different.

[Bug c++/78920] New: libstdc++ defines a macro named "major"

2016-12-23 Thread zhouyan at me dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78920

Bug ID: 78920
   Summary: libstdc++ defines a macro named "major"
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhouyan at me dot com
  Target Milestone: ---

Here is a minimal example,

#include 

#ifdef major
#error
#endif

The example check if there's a macro named "major" defined. I observed this
recently when one of my function in my library named "major" started to break,
and the compiler error message says that "gnu_dev_major" was called with
incorrect number of arguments. This is the typical error when a function takes
the same name as a macro.

The above example will compile fine (major macro not defined) with clang 3.9.1,
g++ 4.8.5, as well as g++ 6.3.1 on macOS. However, it will emit error with g++
6.3.1 on Linux.

I saw I very old bug report #17130 about the same issue. But the system GCC
4.8.5 somehow undefined this macro while the vanilla GCC 6.3 (installed without
any special configuration options, except --prefix and --program-suffix) does
not. Are there some configuration options during installation that lead to the
behavior of the system compiler?

[Bug c++/78920] libstdc++ defines a macro named "major"

2016-12-23 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78920

--- Comment #1 from Andrew Pinski  ---
This comes from glibc headers. G++ defines _GNU_SOURCE which is why this
happens.  There is a duplicate already.

[Bug libstdc++/78920] libstdc++ defines a macro named "major"

2016-12-23 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78920

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 11196.

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

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

2016-12-23 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhouyan at me dot com

--- Comment #15 from Andrew Pinski  ---
*** Bug 78920 has been marked as a duplicate of this bug. ***

[Bug libstdc++/78920] libstdc++ defines a macro named "major"

2016-12-23 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78920

--- Comment #3 from Andrew Pinski  ---
Also see https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html for the
libc patch which is going to remove them.