A not so stellar result on Solaris 10

[Dennis Clarke]

----- Original Message -----
From: Eric Botcazou <ebotcazou@adacore.com>
Date: Saturday, November 17, 2012 6:41 pm
Subject: Re: A not so stellar result on Solaris 10
To: Dennis Clarke <dclarke@blastwave.org>
Cc: gcc-help@gcc.gnu.org, ryan.johnson@cs.utoronto.ca, iant@google.com, jwakely.gcc@gmail.com


> >     So after a pile of noises made I was ableto finally posts ome 
> sort of
> > result :
> > 
> >         http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg01367.html
> > 
> >     Not exactly what I was hoping for but it seems to be a step in 
> the right
> > direction. Notice that I gave up on the --disable-multilib option 
> and did
> > embrace the --disable-nls which allowed stage 1 to complete.
> > 
> > Not too sure what to make of all those failures with g++ or gcc for 
> that
> > matter. Everything else was flawless.
> 
> I think that the visibility failures are expected - because of the 
> antiquated 
> assembler.  You need to use the GNU assembler if you want to have all 
> the 
> fancy C++ features, as well as other advanced features.

Mostly I want a clean GCC compiler. So therefore I see binutils-2.23.1 was just
released last week. Perhaps I will give that a build ( with this GCC ) and then
ensure it has the "g" prefix and try a re-bootstrap of GCC again with gas as the
assembler. This may provide the cleaner results I am looking for. 

> The gnat.dg/lto14.adb failure is also expected (it's adjusted on the branch).

I guess that is fixed in 4.7.3 then .. no worries there. Maybe there is a simply patch
that can be applied at this time ? 

> The g++.dg/cpp0x/nullptr28.C and libgomp.c/sort-1.c failures aren't expected.

I have no idea where they are coming from however, no worries, could be a symptom
of not using gas and/or some other non-obvious factor in the GNU stack I have.  The plan
at some point is to have a single GNU stack in /usr/local which is 64-bit everywhere 
but with a GCC compiler in /usr/local/gcc4 that is happy to handle either 32-bit or 
64-bit tasks. 

Something I did notice was that the GCC 4.7.2 manual still refers to a -mcpu option of v7 
and also v8 as if they would result in different assembler output. Thus far I have tested 
this gcc 4.7.2 with -mcpu=v7 and v8 and checked the output assembly and seen no change. 
I would think v7 has long since been dropped as a supported processor. I don't think I have
seen one in years.  Not even in a junk pile. 

Dennis