[build, libgcc, libgo] Adapt Solaris 12 references

Ian Lance Taylor via gcc-patches gcc-patches@gcc.gnu.org
Tue Nov 14 15:40:00 GMT 2017


On Tue, Nov 14, 2017 at 2:09 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
>
>> With the change in the Solaris release model (no more major releases
>> like Solaris 12 but only minor ones like 11.4), the Solaris 12
>> references in GCC need to be adapted.
>>
>> The following patch does this, consisting mostly of comment changes.
>>
>> Only a few changes bear comment:
>>
>> * Solaris 11.4 introduced __cxa_atexit, so we have to enable it on
>>   *-*-solaris2.11.  Not a problem for native builds which check for the
>>   actual availability of the function.
>>
>> * gcc.dg/torture/pr60092.c was xfailed on *-*-solaris2.11*, but the
>>   underlying bug was fixed in Solaris 12/11.4.  However, now 11.3 and
>>   11.4 have the same configure triplet.  To avoid noise on the newest
>>   release, I've removed the xfail.
>>
>> I've left a few references to Solaris 12 builds in
>> libstdc++-v3/acinclude.m4 because those hadn't been renamed
>> retroactively, of course.
>>
>> install.texi needs some work, too, but I'll address this separately
>> because there's more than just the version change.
>>
>> Bootstrapped without regressions on {i386-pc, sparc-sun}-solaris2.1[01]
>> (both Solaris 11.3 and 11.4).  I believe I need approval only for the
>> libgo parts.
>
> how should we proceed with the libgo part of this patch?  I can checkin
> the rest (which contains functional changes) now and omit the libgo
> part (either for now or completely, given that it consists only of
> comment changes).

Sorry, I've fallen behind a bit on gccgo/libgo patch review.  I've now
committed your patch to libgo trunk.


>> I'm going to backport the patch to the gcc-7 and gcc-6 branches after a
>> bit of soak time.
>
> What's the procedure for libgo here?  IIUC, only the trunk version of
> libgo is imported from upstream, while changes to branches can go in
> directly.

That is correct.  Backporting gcc/go/gofrontend and libgo patches to
release branches is always fine with me if the release managers are OK
with it.

Ian



More information about the Gcc-patches mailing list