On Tue, Nov 14, 2017 at 2:09 AM, Rainer Orth
<r...@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
