Bug 23164 - gcc 2.96-69 problems with k6 optimizations
gcc 2.96-69 problems with k6 optimizations
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-02 12:37 EST by Suchandra Thapa
Modified: 2007-04-18 12:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-01 17:25:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This source shows the bug (I hope). If not, it shows SOME bug. (9.21 KB, patch)
2001-04-24 10:05 EDT, Dragan Milenkovic
no flags Details | Diff
Feel the bug, man!!! (992 bytes, patch)
2001-06-17 05:58 EDT, Dragan Milenkovic
no flags Details | Diff

  None (edit)
Description Suchandra Thapa 2001-01-02 12:37:18 EST
gcc 2.96-69 has problems if -mcpu=k6 -march=k6 is passed as 
options.  Rebuilding the gcc-2.96-69 src rpm with the above optimizations
causes gcc to fail while building the stage 2 compiler.
Comment 1 Dragan Milenkovic 2001-04-24 10:05:37 EDT
Created attachment 16225 [details]
This source shows the bug (I hope). If not, it shows SOME bug.
Comment 2 Steve Snyder 2001-06-07 00:42:22 EDT
I was just about to submit this same bug as occurring in gcc-2.96.81 (standard
RHL v7.1) and gcc-2.96.85 (Rawhide).

In fact the bug is even easier to reproduce: just replace the default
"-march=i386 -mcpu=i686 -O2" with "-march=i386 -mcpu=k6 -O2".  That's all it
takes to generate an ICE while compiling file ~/gcc/libgcc2.c (in function
__divdi3).

Why, after 5 months, is this bug still marked as "New"?

Comment 3 Jakub Jelinek 2001-06-07 11:01:17 EDT
Because it is not reproduceable.
I've tried it back in January with both -march=k6 and -mcpu=athlon build
and it worked, today I did the same (patching gcc.spec so that it set
RPM_OPT_FLAGS="-O2 -march=i386 -mcpu=k6") and it built without problems.
Can you reproduce it always on the same file?
Comment 4 Need Real Name 2001-06-13 17:57:50 EDT
I can reproduce the problem with the same source file (though the function
reported in the error msg varies).

These instructions describe the attempt to build the GCC from Rawhide (latest
publicly available) on a newly-installed RedHat v7.1 system.  This system is
based on an AMD K6-2/333MHz with 160MB RAM.  Installation type was Custom (I
opted for "Install Everything").

Do this:

  1. rpm -ivh ~/gcc-2.96-85.src.rpm
  2. In the spec file, replace $RPM_OPT_FLAGS /w "-march=i386 -mcpu=k6 -O2"
  3. rpm -bc /usr/src/redhat/SPECS/gcc.spec

To get this result:

for d in libgcc; do \
  if [ -d $d ]; then true; else mkdir $d; fi \
done
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
./xgcc -B./ -B/usr/i386-redhat-linux/bin/ -isystem
/usr/i386-redhat-linux/include -O2   -DIN_GCC    -W -Wall  -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes  -Wno-long-long -O2 -march=i386
-mcpu=k6 -O2 -isystem ./include  -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I../../gcc -I../../gcc/config
-I../../gcc/../include  -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o
../../gcc/libgcc2.c: In function `__muldi3':
../../gcc/libgcc2.c:199: Internal error: Segmentation fault.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make[3]: *** [libgcc/./_muldi3.o] Error 1
make[3]: Leaving directory
`/usr/src/redhat/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc'ptmdlPioInstance_t
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory
`/usr/src/redhat/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc'
make[1]: *** [bootstrap-lean] Error 2
make[1]: Leaving directory
`/usr/src/redhat/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc'
make: *** [bootstrap-lean] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.33662 (%build)

This problem is all too reproducable.  Please let me know if I can provide any
addional info.
Comment 5 Need Real Name 2001-06-13 18:01:04 EDT
Please disregard that trailing text "ptmdlPioInstance_t".  It somehow snuck into
my cut 'n' paste of the GCC error output.  It is unrelated to the problem being
described.



Comment 6 Need Real Name 2001-06-13 21:34:20 EDT
Yet another clarification.

Above I wrote that while the ICE ocurred in the same file, the function in which
it occurres varies.  The latter part of this statement is not true.

Given the *same* set of source files, the ICE occures in the same place.  I saw
it in 2 different functions because I used 2 different sets of source, first GCC
from RHL v7.1, now in the GCC SRPM gotten from Rawhide.

My experience: given invariant source files, the ICE will also be invariant. 
Now that I'm testing exclusively /w gcc-2.96-85.src.rpm, the ICE is always
reported as being in __muldi3().
Comment 7 Dragan Milenkovic 2001-06-17 05:58:08 EDT
Created attachment 21205 [details]
Feel the bug, man!!!
Comment 8 Need Real Name 2001-06-21 17:04:02 EDT
A patch to GCC v3.0 has been submitted to address this problem (the PR2767
referred to is in GNATS): http://gcc.gnu.org/ml/gcc/2001-06/msg01357.html

I haven't tried it yet so YMMV.
Comment 9 Jakub Jelinek 2001-09-06 13:06:58 EDT
Sorry, forgot to update.
This was fixed in 2.96-93 and above by simply not using loop insns anywhere
(similarly to the 3.0.x solution).
Comment 10 Richard Henderson 2004-10-01 17:25:09 EDT
As noted, worked around for 2.96 and 3.0; fixed for real at least
as of gcc 3.2.  Confirmed works in gcc-3.2.3-20, gcc-3.3.2-1, 
gcc 3.4.2 20040907, and gcc 4.0.0 20040930.

Note You need to log in before you can comment on or make changes to this bug.