[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[wschmidt at gcc dot gnu.org]

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

--- Comment #34 from Bill Schmidt  ---
Martin, thanks!  I can confirm that building and testing Go on ppc64le works
again.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #33 from Martin Jambor  ---
Fixed.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #32 from Martin Jambor  ---
Author: jamborm
Date: Tue Jun 13 11:40:24 2017
New Revision: 249154

URL: https://gcc.gnu.org/viewcvs?rev=249154=gcc=rev
Log:
[PR80803 2/2] Diligent queuing in SRA grp_write prop

2017-06-13  Martin Jambor  

PR tree-optimization/80803
PR tree-optimization/81063
* tree-sra.c (subtree_mark_written_and_enqueue): Move up in the file.
(propagate_subaccesses_across_link): Enqueue subtree whneve necessary
instead of relying on the caller.

testsuite/
gcc.dg/tree-ssa/pr80803.c: New test.
gcc.dg/tree-ssa/pr81063.c: Likewise.


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

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #31 from Martin Jambor  ---
*** Bug 81063 has been marked as a duplicate of this bug. ***

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #30 from Martin Jambor  ---
I have posted the following two patches to fix this issue to the
mailing list.  The second one also includes two simple C testcases:

  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00833.html
  - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00834.html

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #29 from Ian Lance Taylor  ---
My apologies for not explaining how to find the compilation commands, and I'm
sorry you had to waste time on it.  Using "make GOTESTFLAGS=--trace net/check"
will put the commands in net/check-testlog.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #28 from Martin Jambor  ---
Created attachment 41518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41518=edit
Possible fix

I'm testing the attached two patches which should fix the issue.  If
everything goes well, I will see whether I can up quickly come up with
a C testcase and re-read the patch on Monday to make sure I covered
all corner cases and then post it to the mailing list.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #27 from Martin Jambor  ---
Created attachment 41517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41517=edit
Hack for revealing compiler command lines

Thanks Ian, the above was definitely helpful but did not allow me to
get at the compiler invocation lines, which was what I needed to get
at tree dumps, run the compilation in gdb and so forth.  In the end, i
had to resort to the attached hack to get them.  I do not know how the
trace feature of libgo/gotest script is supposed to work but I had to
redirect them to find them.

It would be great if the testsuite left some libgo.log file with all
necessary command lines to replay the test by hand like all other
testsuites do.  I spent half of the time on this bug so far just
looking for the command lines which does not look reasonable.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #26 from Ian Lance Taylor  ---
This should let you run the test binary:

cd TARGET/libgo
make GOTESTFLAGS=--keep net/check
cd gotest*/test
LD_LIBRARY_PATH=../../.libs ./a.out -test.short

The test binary is simply a.out in the gotestN/test directory.  Run it with
the command line option -test.short to see exactly what happens when you run
`make check-target-libgo`.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #25 from Martin Jambor  ---
(In reply to boger from comment #17)
> I run these tests after a build by first editing the
> src/libgo/testsuite/gotest to set keep=true and trace=true.  Then I go to my
> bld directory:
> 
> cd bld/powerpc64le-linux/libgo
> make fmt/check
> 
> That should give you output with the full gccgo command to build the test,
> the directory containing the a.out and files from the test.  The name of the
> directory is gotestx.
> 
> FAIL
> Keeping gotest32163
> FAIL: fmt
> Makefile:3331: recipe for target 'fmt/check' failed

I have tried the above on gcc112.fsffrance.org but although I can see
the backtraces, I cannot find any commands to build or run the
testcases anywhere.  Is there anything obvious that I am missing?

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[wschmidt at gcc dot gnu.org]

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

--- Comment #24 from Bill Schmidt  ---
Sadly, no.  This continues to be a problem on r248791.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt  ---
Testing now...

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
So, PR 80898 is now fixed.  Can you please check if this is perhaps a
duplicate?  It may as well be.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Jambor  ---
I will have a look after dealing with PR 80898 which seems to be
easier to reproduce.  With some luck, it is going to be the same bug.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski  ---
(In reply to boger from comment #19)
> Is someone building and testing gccgo on x86_64 on a regular basis?  If I
> look at the gcc-testresults output for x86_64 I don't see the go or libgo
> test results like I do for ppc64le.  Maybe it does fail there too.

I am testing go on both x86_64 and aarch64:
latest results for go on x86_64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02832.html

latest results on aarch64 from me:
https://gcc.gnu.org/ml/gcc-testresults/2017-05/msg02770.html

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #19 from boger at us dot ibm.com ---
Is someone building and testing gccgo on x86_64 on a regular basis?  If I look
at the gcc-testresults output for x86_64 I don't see the go or libgo test
results like I do for ppc64le.  Maybe it does fail there too.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor  ---
Lynn, thanks for the detailed investigation.

Martin, Lynn is saying that these problems started with the SRA patch for PR
78687 committed on 2017-05-02.

It's odd that this problem only shows up on PPC64LE, not on x86_64.

In this case we have a three element struct, and we are passing the address of
the struct to a function.  Somehow the writes to two of the fields of the
struct are being dropped.  But since we are taking the address anyhow, I'm not
sure precisely where SRA is kicking in.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[boger at us dot ibm.com]

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

--- Comment #17 from boger at us dot ibm.com ---
Here's more info on the failures and how to reproduce them.  Starting with
commit 247497 there are 7 new failures in the libgo testsuite.

There are 4 that fail with a SEGV at runtime: reflect, archive/tar,
mime/multipart, and net/mail. I looked at 2 and their stacks look similar but
not quite the same.  The SEGV happens because a 0 is passed as the address of
the src argument.

archive/tar shows a stack like this at the point of the SEGV:
Program received signal SIGSEGV, Segmentation fault.
__memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
219 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:219
#1  0x3fffb6350918 in __GI_memmove (dest=0xc208086600, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb7620fd8 in runtime.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:298
#4  0x3fffb76215bc in reflect.typedmemmove (typ=,
dst=, src=)
at ../../../src/libgo/go/runtime/stubs.go:304
#5  0x3fffb75c8384 in reflect.packEface (v=...) at
../../../src/libgo/go/reflect/value.go:113
#6  reflect.valueInterface (param=..., safe=true) at
../../../src/libgo/go/reflect/value.go:821
#7  0x3fffb75c8760 in reflect.Interface.N13_reflect.Value
(pointer=) at ../../../src/libgo/go/reflect/value.go:781
#8  0x3fffb72e570c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)
at ../../../src/libgo/go/fmt/print.go:694
#9  0x3fffb72e623c in fmt.printValue.pN6_fmt.pp (p=,
param=..., verb=, depth=)

With gdb I found that when reflect.typedmemmove calls runtime.typedmemmove, it
is passing a bad argument for the src.

Something similar happens in the reflect test, although that SEGV stack looks
like this:
288 ../sysdeps/powerpc/powerpc64/power7/memcpy.S: No such file or
directory.
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:288
#1  0x3fffb6350918 in __GI_memmove (dest=0xc20800b6d0, src=,
len=) at ../sysdeps/powerpc/memmove.c:54
#2  0x3fffb71567bc in runtime.memmove (p1=, p2=, len=)
at ../../../src/libgo/runtime/go-memmove.c:15
#3  0x3fffb762165c in runtime.typedslicecopy (typ=, dst=...,
src=...) at ../../../src/libgo/go/runtime/stubs.go:329
#4  0x3fffb76216cc in reflect.typedslicecopy (elemType=,
dst=..., src=...) at ../../../src/libgo/go/runtime/stubs.go:336
#5  0x10052c6c in reflect.Copy (param=..., param=...) at value.go:1747
#6  0x100529f4 in reflect.AppendSlice (param=..., param=...) at
value.go:1702
#7  0x10069514 in reflect_test.TestAppend (t=) at
all_test.go:534

And the bad address is passed for the src argument for the call from
reflect.typedslicecopy to runtime.typedslicecopy.

The tests for fmt, net, and debug/dwarf fail when processing code that calls
reflect.DeepEqual followed by a call to Errorf, something like this:

if out := ParseIP(tt.in); !reflect.DeepEqual(out, tt.out) {
  t.Errorf("ParseIP(%q) = %v, want %v", tt.in, out, tt.out)
}

The argument for tt.out is passed incorrectly to DeepEqual, causing it to
return false when it shouldn't, and then passes bad information to the Errorf
function.

I've tried to reproduce this in a smaller testcase but haven't been able to.  I
run these tests after a build by first editing the src/libgo/testsuite/gotest
to set keep=true and trace=true.  Then I go to my bld directory:

cd bld/powerpc64le-linux/libgo
make fmt/check

That should give you output with the full gccgo command to build the test, the
directory containing the a.out and files from the test.  The name of the
directory is gotestx.

FAIL
Keeping gotest32163
FAIL: fmt
Makefile:3331: recipe for target 'fmt/check' failed