From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19253 invoked by alias); 18 Nov 2012 00:12:40 -0000 Received: (qmail 19097 invoked by uid 22791); 18 Nov 2012 00:12:34 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_VIA_APNIC X-Spam-Check-By: sourceware.org Received: from comm.purplecow.org (HELO comm.purplecow.org) (210.87.62.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 18 Nov 2012 00:12:28 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from comm.purplecow.org ([127.0.0.1]) by comm.purplecow.org (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTP id <0MDN0013TPWRS010@comm.purplecow.org> for gcc-help@gcc.gnu.org; Sun, 18 Nov 2012 11:12:27 +1100 (EST) Received: from comm.purplecow.org ([127.0.0.1] helo=comm.purplecow.org) with IPv4:25 by ASSP.nospam; Sun, 18 Nov 2012 11:12:27 +1100 Received: from [66.103.52.207] by comm.purplecow.org (mshttpd); Sat, 17 Nov 2012 19:12:27 -0500 From: Dennis Clarke To: Eric Botcazou Cc: gcc-help@gcc.gnu.org, ryan.johnson@cs.utoronto.ca, iant@google.com, jwakely.gcc@gmail.com Message-id: Date: Sun, 18 Nov 2012 00:12:00 -0000 Subject: Re: A not so stellar result on Solaris 10 In-reply-to: <1644592.hNC6Drk1kz@polaris> References: <1644592.hNC6Drk1kz@polaris> X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00129.txt.bz2 ----- Original Message ----- From: Eric Botcazou Date: Saturday, November 17, 2012 6:41 pm Subject: Re: A not so stellar result on Solaris 10 To: Dennis Clarke 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