On Fri, Jan 6, 2017 at 6:35 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > Hi Ian, > >> On Thu, Jan 5, 2017 at 1:20 AM, Rainer Orth <r...@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
