Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of r1mikey@gmail.com designates
 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=brnmzkMTv77zyVU8SNZfyincsnm2pIVyrcpSkx3eoSMx8JZTzSVkvJGGklHLUFGo0SpMJdcfiX6w8CgduJzv3PM7G6FxI+o99lncYaNKB2Gsy2DSc9fkCH1pwcstU0CWl8rnJZBQhsNWjAxAHcI66Pk6iR5Gdx+xENY9E8n/hFc=
Message-ID: <d21d65950707071532m4b97f2a8l692b6d925dc41686@mail.gmail.com>
Date: Sun, 8 Jul 2007 00:32:15 +0200
From: "Michael van der Westhuizen" <r1mikey@gmail.com>
To: stdcxx-dev@incubator.apache.org
Subject: Re: config with wide has no effect on Solaris/Intel + patch
In-Reply-To: <469000DE.9070404@roguewave.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d21d65950707071209r1fe0b9b3wdc96b221477c9094@mail.gmail.com>
	 <d21d65950707071227k1fd1438aud54dee6b271f5205@mail.gmail.com>
	 <469000DE.9070404@roguewave.com>

Hi Martin,

On 7/7/07, Martin Sebor <sebor@roguewave.com> wrote:
[snip]
>
> I recall reading somewhere that Sun C++ 5.9 supports the gcc -m64
> option but I can't find the reference. Do you happen to have a link?
> The x86 equivalent I was able to find in the online documentation is
> still -xarch=amd64 (I couldn't find -m64 in the manual):
> http://docs.sun.com/source/819-3690/Comp_Options_App.html#pgfId-999544

I picked the flags up here -
http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html

The xarch flags used result in compile-time warnings with C++ 5.9, so
the -mXX options are really necessary.

It's possible to further tune the generated code using non-deprecated
-xarch options - there are details in the links above.

> We're only just getting around to setting up the compiler but once it's
> up and running we'll test your patch with it.

I've found quite a few issues with C++ 5.9, so we'll probably stick to
5.8+patches for now - at least until the obvious optimiser bugs are
worked out.

I've logged a compile-time showstopper (a ube assertion that crops up
in both 4.1.3 and 4.2.0) with bugs.sun.com, but I haven't logged a
runtime problem with the numeric limits configuration test which makes
it impossible to compile with any optimisation on sparcv8/sparcv9 (I
haven't had time to look into the problem).

I'm also seeing the support/atomic* tests timing out on the i386 and
amd64 - this is unexpected, but I haven't had time to look into this
yet.

Some of the tests are also hitting backend corner cases - I've never
seen the UBE take as much memory as it does now, and I've never seen
it use a whole CPU before:
  7723 michael   315M  312M cpu0     0    0   0:05:43  50% ube/1

Michael