GCC 4.7.0 Release Candidate available from gcc.gnu.org

Dennis Clarke dclarke at blastwave.org
Fri Mar 2 21:34:40 CET 2012


> Dennis Clarke <dclarke at blastwave.org> writes:
>
>>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>>
>>> The first release candidate for GCC 4.7.0 is available from
>>>
>>>  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
>>>
>>> and shortly its mirrors.  It has been generated from SVN revision 184777.
>>>
>>> I have so far bootstrapped and tested the release candidate on
>>> x86_64-linux.  Please test it and report any issues to bugzilla.
>>>
>>> If all goes well, I'd like to release 4.7.0 in about three weeks.
>>
>> I'll drop it on Solaris. Give it a push. Do we realy really need that
>> ppl/cloog stuff? I have never seen it build and pass any tests, ever,
>> even once, on Solaris with or without Sun Studio compilers or GCC or
>> prayer and geek magic under a full moon.  Seriously.
>
> Given that PPL is a C++ library, you need to build it with g++ since
> Studio CC and g++ aren't ABI-compatible.
>
> That said, I'm using them in my Solaris GCC bootstraps, although it
> admittedly took some effort to build initially and using it requires you
> to jump through hoops to get the configure options right.  I agree that
> this is an incredible mess right now.
>
>> So really, it that stuff a "need" or a "nice to have" ?
>
> install.texi documents them as optional:
>
> Necessary to build GCC with the Graphite loop optimizations.
>
> but that sentence could probably be clarified.
>
> 	Rainer

Well this topic is in play for me right now and I'd love your input
also.

I just finished a prep for bootstrapping gcc 4.6.3 and 4.7.0-RC1 on
Solaris 8 sparc and i386 here. One of the initial steps is to ensure
we have gmp/mpfr/mpc flawless which I do :


.
.
.
PASS: tsub_ui
PASS: ttan
PASS: ttanh
PASS: tui_div
PASS: tui_ui_sub
GMP: include 5.0.4, lib 5.0.4
MPFR: include 3.1.0, lib 3.1.0
MPC: include 0.9, lib 0.9
PASS: tget_version
===================
All 60 tests passed
===================
gmake[2]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests'
gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/tests'
Making check in doc
gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc'
gmake[1]: Nothing to be done for `check'.
gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001/doc'
gmake[1]: Entering directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001'
gmake[1]: Leaving directory `/opt/bw/src/mpc-0.9-SunOS5.8-i386.001'
$
$ uname -a
SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc
$ cat /etc/release
                       Solaris 8 2/02 s28x_u7wos_08a INTEL
           Copyright 2002 Sun Microsystems, Inc.  All Rights Reserved.
                           Assembled 18 December 2001
$ psrinfo -v
Status of virtual processor 0 as of: 03/02/12 20:25:50
  on-line since 04/28/11 17:39:44.
  The i386 processor operates at 400 MHz,
        and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 03/02/12 20:25:50
  on-line since 04/28/11 17:39:48.
  The i386 processor operates at 400 MHz,
        and has an i387 compatible floating point processor.
$

So I have had no issues with old Solaris 8 and Sparc32 or Sparc 64-bit
regardless if it is Sparc64 Fujitsu, Niagara T2 or old UltraSparc II.
I know I have to compile for x86_64 on Solaris 10. That is a given.

The question on my mind that requires ( or begs ) your input is should
I continue to trust the golden rule of the ABI and build, test and
release based on Solaris 8?  I don't really want to do the same
process over and over on Solaris 10 or 11 when I *know* that old
Solaris 8 is rock solid stable and the baseline ABI to be used.

Your thoughts ?

Dennis



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke at blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+



More information about the gmp-discuss mailing list