This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libgo patch committed: Update to 1.7rc3
- From: Ian Lance Taylor <iant at golang dot org>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>
- Date: Thu, 4 Aug 2016 07:51:41 -0700
- Subject: Re: libgo patch committed: Update to 1.7rc3
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4Y+VPYZvybzR143yxKjX=eVCqachV+qRMi=_sKqtcamqg@mail.gmail.com> <yddwpjwvil9.fsf@CeBiTec.Uni-Bielefeld.DE>
On Thu, Aug 4, 2016 at 5:12 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Hi Uros,
>
>>> I have committed a patch to update libgo to the 1.7rc3 release
>>> candidate. This is very close to the upcoming 1.7 release. As usual
>>> with libgo updates, the patch is too large to include in this e-mail
>>> message. I've appended the changes to the gccgo-specific directories.
>>
>> There is an issue with
>>
>> libgo/go/crypto/sha1/issue15617_test.go.
>>
>> The test crypto/sha1 fails on alpha-linux-gnu with:
>>
>> --- FAIL: TestOutOfBoundsRead (0.00s)
>> panic: invalid argument [recovered]
>> panic: invalid argument
>> ...
>>
>> since the test hard-codes 4k pages, but alpha uses 8k pages.
>>
>> It looks that the second line of build directives in the test:
>>
>> // +build amd64
>> // +build linux darwin
>>
>> overwrites the first one, so the test runs also on non-amd64
>> architecture linux OS. I have confirmed this by removing the second
>> build directive, and crypto/sha1 test then passed, since
>> issue15617_test.go was not linked into the final executable.
>>
>> Another possible solution is to avoid hard-coding 4k pages in the
>> test. The mentioned test will pass on alpha when
>>
>> const pageSize = 4 << 10
>>
>> is changed to
>>
>> const pageSize = 8 << 10
>
> just FTR, I've been seeing the same failure on Solaris/SPARC, which
> uses 8k pages.
That test was only supposed to be run on x86_64. It was a bug that it
was run on any other target. I committed a patch yesterday to fix
that, so you should no longer see this test failure.
Ian