On Wed, Nov 5, 2014 at 2:05 AM, Dominik Vogt <v...@linux.vnet.ibm.com> wrote: > On Tue, Nov 04, 2014 at 08:16:51PM -0800, Ian Taylor wrote: >> I committed the change to go-test.exp. Thanks. >> >> The other changes are not OK. As described in >> gcc/testsuite/go.test/test/README.gcc, the files in >> gcc/testsuite/go.test/test are an exact copy of the master Go >> testsuite. Any changes must be made to the master Go testsuite first. > > I understand that, but I'm unsure how to handle a set of patches > that all depend on each other but refer to three different > reposiories. So I posted this patch intentionally in the wrong > place, not knowing how to do it in a better way.
Changes to the master Go repository must follow the procedure described at http://golang.org/doc/contribute.html. >> I don't know what's up with the complex number change. In general the >> Go compiler and libraries go to some effort to produce the same >> answers on all platforms. We need to understand why we get different >> answers on s390 (you may understand the differences, but I don't). I >> won't change the tests without a clear understanding of why we are >> changing them. > > It's actually not a Go specific problem, the same deviation occurs > in C code too. The cause is that constant folding is done with a > higher precision and may yield a different result than the run > time calculations. There is a Gcc bug report for that "issue": > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 So far it doesn't sound appropriate to change the Go testsuite for this. If the immediate goal is simply to get the s390 tests to pass, let's change go-test.exp to xfail the test unless and until somebody figures out the whole issue. Ian
