This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [build, libgo, libstdc++] Build libgo with -Wa,-nH if possible (PR go/78978)
- From: Ian Lance Taylor <iant at golang dot org>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Paolo Bonzini <bonzini at gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>
- Date: Fri, 6 Jan 2017 08:04:03 -0800
- Subject: Re: [build, libgo, libstdc++] Build libgo with -Wa,-nH if possible (PR go/78978)
- Authentication-results: sourceware.org; auth=none
- References: <CAKOQZ8yY-q4zDULuSxpX_9FApR=wDaz1suMsv1rT=QwvpXyhyA@mail.gmail.com> <yddk2a89rz8.fsf@CeBiTec.Uni-Bielefeld.DE>
On Fri, Jan 6, 2017 at 6:35 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Hi Ian,
>
>> On Thu, Jan 5, 2017 at 1:20 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>>> As could have been expected, the static libgo.a causes the same problem
>>> with hardware capabilities on Solaris/x86 as was solved for libgo.so
>>> with
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html
>>>
>>> Instead of trying to pass -mclear-hwcap with -static-libgo, it was
>>> deemed easier to solve both problems the same way and disable hwcaps
>>> support in the assembler in the first place.
>>>
>>> This has already been done in libstdc++, so I've moved the corresponding
>>> autoconf macro to config/hwcaps.m4 and adapted it to set HWCAP_CFLAGS
>>> instead of HWCAP_FLAGS to better differntiate from HWCAP_LDFLAGS.
>>> Everything else is straightforward, I believe.
>>>
>>> Bootstrapped without regressions on i386-pc-solaris2.1[02] with as/ld
>>> (where as supports -nH) and sparc-sun-solaris2.12 with as/ld (where as
>>> doesn't, or rather it's called -hwcap={1|0}), and the libgo
>>> runtime/pprof failure is gone.
>>>
>>> Ok for mainline?
>>>
>>> Once approved, how should we proceed with checking? Ian, will you take
>>> care of the libgo part once the rest is in?
>>
>> This patch is OK. Yes, please commit the config and libstdc++
>> portions. Then I will commit the libgo portions to the external repo
>> and mirror them in. Thanks.
>
> done, thanks. While preparing the partial commit, I noticed that I'd
> created the libgo part of the patch on top of a tree that contained a
> workaround for PR go/64900.
>
> Here's the libgo part again, this time on top of a vanilla tree.
Thanks. Committed.
Ian