----- Original Message ----- From: Eric Botcazou <ebotcazou@xxxxxxxxxxx> Date: Saturday, November 17, 2012 6:41 pm Subject: Re: A not so stellar result on Solaris 10 To: Dennis Clarke <dclarke@xxxxxxxxxxxxx> Cc: gcc-help@xxxxxxxxxxx, ryan.johnson@xxxxxxxxxxxxxx, iant@xxxxxxxxxx, jwakely.gcc@xxxxxxxxx > > 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
