Subject: bin/6795: egcs 1.1.1 doesn't compile freelip with optimisation
To: None <gnats-bugs@gnats.netbsd.org>
From: Simon Burge <simonb@telstra.com.au>
List: netbsd-bugs
Date: 01/13/1999 08:55:36
>Number: 6795
>Category: bin
>Synopsis: egcs 1.1.1 doesn't compile freelip with optimisation
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 12 14:05:00 1999
>Last-Modified:
>Originator: Simon Burge
>Organization:
IBM Global Services Australia
>Release: NetBSD-current January 8, 1999.
>Environment:
System: NetBSD simonpc 1.3I NetBSD 1.3I (SIMONPC) #0: Thu Jan 7 16:09:49 EST 1999 root@simonpc:/tmp/SIMONPC i386
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
>Description:
Trying to compile freelip (a large integer package) with egcs
results in a program that seems to contain extremely inefficent
code in some sections. This occurs on both an i386 and a pmax
both running -current and using "gcc version egcs-2.91.60
19981201 (egcs-1.1.1 release)"
Compiling on both a pmax and an i386 running 1.3.3 with "gcc
version 2.7.2.2+myc2" result in a working program.
>How-To-Repeat:
Try to compile freelip (available at
ftp://ftp.ox.ac.uk/pub/math/freelip/freelip_1.1.tar.gz) with
ecgs with either -O or -O2. Here's some results:
gcc 2.7.2.2+myc2 on -current i386:
...
timing SINGLE_MUL = 1, PLAIN = 0, KARAT = 0
59bit 179bit 299bit 419bit 539bit
------- ------- ------- ------- -------
59bit: 0.020 0.040 0.080 0.110 0.130
179bit: 0.030 0.070 0.110 0.160
299bit: 0.030 0.100 0.150
419bit: 0.040 0.100
539bit: 0.050
...
23.121u 0.049s 0:23.23 99.6% 0+0k 0+1io 0pf+0w
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) on -current i386:
...
timing SINGLE_MUL = 1, PLAIN = 0, KARAT = 0
59bit 179bit 299bit 419bit 539bit
------- ------- ------- ------- -------
59bit: 62.780 210.670 374.800 443.660 853.460
179bit: 0.030 0.080 0.130 0.170
299bit: 0.360 0.790 2.290
419bit: 16315.920^C
50459.436u 5.499s 14:01:16.02 14.8% 0+0k 0+0io 30pf+0w
The timing for each element is the time taken in seconds. This
is the seventh test out of nine - the previous six tests seem to
complete ok. Similar results (but with larger numbers :-) occur
for the pmax too.
>Fix:
None given - "Don't use -O or -O2" doesn't quite cut it,
especially for numberical programs. I will try to narrow down
to a chunck of code that shows the problem, but freelip is a
large package (the library is one 11829 line .c file and the
driver program whose results are shown above is 5290 lines).
>Audit-Trail:
>Unformatted: