Re: EGCS-1.0.2 pre fails on Spec CPU 95

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Richard Henderson]

On Mon, Mar 09, 1998 at 11:38:51AM -0800, Bill Broadley wrote:
> Running '146.wave5'
> Error comparing benchmark '146.wave5'

Turns out this is a problem between the spec test and the i386 fpu. 
Having the calculations done at the wrong precision results in 
slightly different end results.

There are two solutions: -ffloat-store, which will completely kill
any sort of performance, or changing the rounding mode in the fpu.

I would go for the later.  On Linux at least, the attached program
may be compiled with

  gcc -O -o libieee-dbl.a libieee-dbl.c

install the result in some convenient directory and add

  146.wave5=default=default:
  EXTRA_LIBS= -lieee-dbl

to your Spec95 config file.  Other Intel operating systems will only
require minor modifications, possibly using inline asm rather than a
library function.


r~

EGCS-1.0.2 pre fails on Spec CPU 95

[Bill Broadley]

I recently tried to compile and run  Spec's CPU 95 benchamrk.  It's a collection
of 9 C benchmarks (350k lines of source), and 9 Floating point Fortran 
codes  (31 k lines of source).

It's particularly good at exposing compiler errors because of the many 
different types of codes, as well as know correct answers for the 
simulations, all 18 programs take several hours to run.  It's also very
good at showing any effects of optimization/performance changes in the 
compiler.   Results are available on intel using the Intel reference compiler
which gets very good numbers. 

egcs-1.0.1/g77  failed on -O2, but works with -O1.

egcs-1.0.2 worked with -O2 but did NOT work with -m486 -fomit-frame-pointer -O2
It finished all the benchmarks but one then failed and produced the wrong
output.

Unfortunately I can't give out the source, but I would be happy to help out
on this end or contribute towards the $300 license for the egcs group. The
license is per organization.

So let me know what I can do to help, the machine I was using is a
up to date (redhats newest glibc etc)  Redhat-5.0 P6-200 with 80 mb ram.  

Any suggestions for narrowing down the actual cause of the different
in output welcome.

Reading specs from /opt/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.90.25/specs
gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)

Linux bee2.math.ucdavis.edu 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i686 unknown 

cat /etc/redhat-release 
release 5.0 (Hurricane)

[root@bee2 result]# rpm -qa | grep glibc
glibc-debug-2.0.6-9
glibc-profile-2.0.6-9
glibc-2.0.6-9
glibc-devel-2.0.6-9



-- 
Bill Broadley           Bill@math.ucdavis.edu               UCD Math Sys-Admin
Linux is great.         http://math.ucdavis.edu/~bill			PGP-ok

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Dave Love]

>>>>> "Bill" == Bill Broadley <bill@math.ucdavis.edu> writes:

 Bill> Results are available on intel using the Intel reference
 Bill> compiler which gets very good numbers.

Presumably it's tuned to be fast and correct for this case :-).  I've
heard the Fortran compiler compared unfavourably to g77 elswhere...

 Bill> egcs-1.0.1/g77  failed on -O2, but works with -O1.

 Bill> egcs-1.0.2 worked with -O2 but did NOT work with -m486
 Bill> -fomit-frame-pointer -O2 It finished all the benchmarks but one
 Bill> then failed and produced the wrong output.

This sounds suspiciously like a numerical problem with the code.  Is
it cured (with the expected slowdown) by -ffloat-store or other
options from the `Working Code' (?) node of the g77 manual?  A
surprisingly large number of Fortran benchmarks have programming
problems of one sort or another which g77 exposes, although it's often
difficult to persuade people of this.

 Bill> Unfortunately I can't give out the source, 

What is the program at issue?  Perhaps we can find source elsewhere
(if, as I understand, Spec is compiled from original freely-available
sources).  Alternatively I can suggest sources of tools with which to
check it.

Regarding speed, the usual x86 problems with alignment of doubles
(when are we going to get that fixed??), -funroll-loops and
-fforce-addr at least may be relevant, but I don't know anything about
what's in spec95.

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Jeffrey A Law]

  In message < rzqlnulkkm0.fsf@djlvig.dl.ac.uk >you write:
  > Regarding speed, the usual x86 problems with alignment of doubles
  > (when are we going to get that fixed??), -funroll-loops and
  > -fforce-addr at least may be relevant, but I don't know anything about
  > what's in spec95.
Just a note, someone did take my suggestion and send patches which
crank up DATA_ALIGNMENT on the x86, which will allow us to align
arrays in the static store without ABI breakage (as is the case
with most fortran code).  I haven't had a chance to look at them
yet, but I'm hopefully optimistic :-)

jeff

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> Just a note, someone did take my suggestion and send patches
 Jeff> which crank up DATA_ALIGNMENT on the x86, which will allow us
 Jeff> to align arrays in the static store without ABI breakage (as is
 Jeff> the case with most fortran code).

Do I misunderstand what `static store' is?  We can already
-malign-double happily for Fortran to get static data (is that the
right term?) aligned properly, e.g. in COMMON.  However, stack
allocation (arrays or not) may still be a killer, as with the code
where the problem was discovered originally.  I understood the stack
problem was sorted, modulo appropriate crt, by a Schmidt/Lehmann
patch, waiting on paperwork from Lehmann which seems never to have
turned up according to copyright.list.

I wish I understood all this :-(.

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Jeffrey A Law]

  In message < rzqg1ksvxte.fsf@djlvig.dl.ac.uk >you write:
  > Do I misunderstand what `static store' is?

  > We can already
  > -malign-double happily for Fortran to get static data (is that the
  > right term?) aligned properly, e.g. in COMMON. 
Doesn't -malign-double effect the alignment of stack variables and
parameters?

  > However, stack
  > allocation (arrays or not) may still be a killer, as with the code
  > where the problem was discovered originally.  I understood the stack
  > problem was sorted, modulo appropriate crt, by a Schmidt/Lehmann
  > patch, waiting on paperwork from Lehmann which seems never to have
  > turned up according to copyright.list.
It's more than that.  Changing the alignment of doubles in the stack
changes the ABI; you've got to be careful as hell to make sure that
old code still works correctly.

I've got a copy of Marc's assignment, but haven't had the opportunity
to go back and do anything with the double patches.  Damn I'll be
glad when 1.0.2 gets out the door!


jeff

Re: EGCS-1.0.2 pre fails on Spec CPU 95

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> Doesn't -malign-double effect the alignment of stack variables
 Jeff> and parameters?

AFAIK it affects the stack only with something like this change from
the current (against gcc 2.7) g77 patches, relevant on a glibc2
system.  [BTW, I've no memory of this going into g77-0.5.21 and may
have been misleading people by suggesting it wasn't there...]

	* config/i386/i386.h (STACK_BOUNDARY): Define as BIGGEST_ALIGNMENT
	so that -malign-double works for stack-allocated data.

I think parameter alignment is controlled by something else
(PARM_BOUNDARY?).  [Note that in Fortran args are passed by reference
for EXTERNALs, though intrinsics implementations may get doubles by
value.]

 Jeff> Changing the alignment of doubles in the stack changes the ABI;

I'm specifically talking about -malign-double with Fortran, though
(wot's a struct?).

 Jeff> you've got to be careful as hell to make sure that old code
 Jeff> still works correctly.

Experimentally it (Fortran) does, unless it ill-advisedly has
non-portable and inconsistent COMMON layout; this gets a warning with
-malign-double due to padding, the same as is normal on SPARC, for
instance.

I'm sorry I don't understand the reasons why it's expected to fail.
If I wasn't out of my depth I'd work on rather than just badger :-(.
(BTW, when we talk about old FORTRAN code we mean _old_ and, often,
_code_!)

 Jeff> Damn I'll be glad when 1.0.2 gets out the door!

We'll be glad when you're glad but are relatively glad anyhow (thanks) :-).