https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803
Bug ID: 80803
Summary: libgo appears to be miscompiled on powerpc64le since
r247923
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Since r247923 was committed, I've been observing a strange problem when running
the libgo testsuite. A very long numeric string (over 5 GB) is written to (I
believe) stderr, flooding the terminal window where the tests are being run.
I traced this to a process running "cat net/check-testlog". I found this file
in the libgo portion of my build directory:
wschmidt@pike:~/gcc/build/gcc-mainline-base/powerpc64le-unknown-linux-gnu/libgo/net$
ls -l
total 5819528
-rw-rw-r-- 1 wschmidt wschmidt 5949542309 May 15 14:48 check-testlog
drwxrwxr-x 3 wschmidt wschmidt 4096 May 15 10:14 http
-rw-rw-r-- 1 wschmidt wschmidt 102960 May 15 10:14 http.gox
...
I asked Ian about this offline, and this was his response:
=====
I'm sorry, I have no idea what is going on. Clearly the Go library is
being miscompiled somehow. The test uses a value computed at init
time, before the main function runs. That value seems to be corrupt:
it should be only four bytes long, but in your log it is clearly
vastly longer than that. Or maybe the bug is a miscompilation in the
code that prints out the value, I don't really know.
You can debug further by changing to the libgo build directory and
running `make GOTESTFLAGS=--keep net`. That should dump the long
string you have been seeing. It will create a gotestNNNN directory.
In gotestNNNN/test, there will be a program a.out. You can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.run=TestParseIP` and you
will presumably see the same long string. At that point, I have no
idea what to do next.
If the revision you mentioned is where the problem reliably starts,
then it seems that GCC is miscompiling itself in a way that produces
this problem. That is very unlikely but I've seen it happen before,
though not with Go.
=====
I agree that it is probably a miscompilation, but I don't really see how this
particular revision (which just moves some interfaces around) could be at
fault. So we will need to dig deeper.
Component set to "other" since I have no idea yet whence the problem arises.
I will try to refine the bug report, but I may not have time for a while. I
have had another developer confirm the problem on powerpc64le. I have not yet
tried on any other targets.
