From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28847 invoked by alias); 28 Mar 2003 23:46:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28840 invoked from network); 28 Mar 2003 23:46:48 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 28 Mar 2003 23:46:48 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id E92C94DE31; Sat, 29 Mar 2003 00:46:49 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Sat, 29 Mar 2003 00:46:52 +0100 Date: Sat, 29 Mar 2003 05:19:00 -0000 From: Jan Hubicka To: Casey Leedom Cc: Jan Hubicka , Joe Buck , dann@godzilla.ics.uci.edu, mark@codesourcery.com, gcc@gcc.gnu.org, dan@dberlin.org, aj@suse.de Subject: Re: SPEC2000 252.eon generates invalid results when compiled -O3 with g++ 3.3 Message-ID: <20030328234652.GD18851@kam.mff.cuni.cz> References: <20030328012156.GA10149@kam.mff.cuni.cz> <20030328214304.47039.qmail@web13104.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030328214304.47039.qmail@web13104.mail.yahoo.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-03/txt/msg01737.txt.bz2 > / Date: Fri, 28 Mar 2003 02:21:56 +0100 > | From:"Jan Hubicka" > | > | > Okay, adding -fpmath=sse solved the problem. Interestingly enough adding > | > "-march=k8 -mcpu=k8" wasn't good enough. I would have thought that it > | > would have been from reading gcc/config/i386/i386.c:override_options() ... > | > | We've been chatting about this with glibc folks and they don't like the > | idea of losing the extra precisity 80bit temrporaries give, so > \ -mfpmath=sse can't be the default, unforutnately :( > > Okay, I understand that. So let me see if I'm 100% on the same page (I'm > very new to the x86 instruction set and it's history): > > 1. x87 is a stack-based floating point co-processor (originally on a separate > chip). It performs calulations in 80-bit arithmetic for "double"s? > > 2. SSE is a register-file floating point engine. It was designed to support > digital media applications and performs 64-bit arithmetic for "doubles"? SSE does only "floats" > > 3. SSE2 is an update of SSE that extends the arithmetic to use 128-bit > (80-bit?) arithmetic for "doubles"? and SSE2 does doubles, 80-bit needs to be done in x87. SSE can do 128bit operations on vector of 4 floats, SSE2 can deal with vectors of 2 doubles. > > I'm a bit confused because SPEC2000 252.eon fails with x87 in 32-bit mode but > succeeds with -mfpmath=sse in 32-bit mode. Unfortunately, 301.apsi fails with > SSE in 32-bit mode. And then of course, they all succeed in 64-bit mode which This looks like a bug. I am not testing 32bit SSE support too much, so it is possible. If you have idea what is getting wrong with it, it would be helpfull - I am not particulary good on hunting bugs in fortran code. > defaults to SSE/SSE2 ... > > Which brings us to a different issue: the default math mode is dependent on > the 32- vs. 64-bit compilation mode rather than the fundamental CPU > architecture capabilities. For instance, here's the relevant portion of > gcc/config/i386/i386.c:override_options(): Yes, this is because the math is part of ABI (FLT_EVAL_METHOD) at least according to the glibc people - the FLT_EVAL_METHOD is C99 thing and the PSABI is pre-C99 so it is not specified explicitly. > > if (TARGET_64BIT) > { > if (TARGET_ALIGN_DOUBLE) > error ("-malign-double makes no sense in the 64bit mode"); > if (TARGET_RTD) > error ("-mrtd calling convention not supported in the 64bit mode"); > /* Enable by default the SSE and MMX builtins. */ > target_flags |= (MASK_SSE2 | MASK_SSE | MASK_MMX | > MASK_128BIT_LONG_DOUBLE); > ix86_fpmath = FPMATH_SSE; > } > else > ix86_fpmath = FPMATH_387; > > Worse yet, there's no way I can find to turn on SSE2 explicitly. This is just > plain confusing and doesn't make sense. If there are default math options that > vary by compilation, those defaults ought to be based on the target CPU > architecture, not the 32- vs. 64-bit compilation mode. All these flags can be handled manually - you do have -msse/-msse2 and -march switches to enable support for SSE/SSE2 instruction set and you do have -mfpmath=sse to enable automatical generation of scalar floating point in the SSE To get same results in 32bit as for 64bit you need -msse2 -mfpmath=sse. Honza