Bug 81634

Summary: gcc 3.2.1-2 fail to compile lame 3.93.1 with -march=k6-3
Product: [Retired] Red Hat Raw Hide Reporter: Piergiorgio Sartor <piergiorgio.sartor>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-03 11:50:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Here is the request file. Note this is gcc-3.2.2-2, same bug still present.
none
New file from lame 3.93.1 with problems
none
Assembly file with problems none

Description Piergiorgio Sartor 2003-01-11 20:53:07 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2) Gecko/20021202

Description of problem:
When trying to compile lame 3.93.1 with gcc 3.2.1-2
from Redhat Rawhide, the procedure stops with an error
from the assembler if the "-march=k6-3" option is set.

The file "encoder.c" in the directory "libmp3lame"
of lame-3.93.1 (the latest) has problem if compiled
with "-march=k6-3" and "-fPIC".



Version-Release number of selected component (if applicable):
3.2.1-2

How reproducible:
Always

Steps to Reproduce:
1.
cd to "libmp3lame" in the lame-3.93.1 directory

2.
Type the following compiling command (one line):
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I. -I../mpglib/ -I.. -Wall -s
-march=k6-3 -O3 -fomit-frame-pointer -ffast-math -funroll-loops
-maccumulate-outgoing-args -Wall -c encoder.c -MT encoder.lo -MD -MP -MF
.deps/encoder.TPlo  -fPIC -DPIC -o .libs/encoder.lo

2a.
If "-S" is added (to the above line), the produced
assembler output (encoder.s) cannot be assebled with
"as encoder.s", giving the error as reported below.



Actual Results:
/tmp/ccFUgnFV.s: Assembler messages:
/tmp/ccFUgnFV.s:787: Error: value of -141 too large for field of 1 bytes at 2361

Expected Results:
The file is compiled with no error/warning messages.

Additional info:

If "-march=i586" is choosen everything works fine.
If "-fPIC" is removed, the compilation gives no error, but
it is not sure the overall result will be OK.
Comment 1 Jakub Jelinek 2003-02-18 20:43:03 UTC 
Can you provide encoder.i (e.g. by adding -save-temps to the above gcc cmdline)
which you can reproduce it on?
Comment 2 Piergiorgio Sartor 2003-02-24 18:15:34 UTC 
Created attachment 90312 [details]
Here is the request file. Note this is gcc-3.2.2-2, same bug still present.
Comment 3 Piergiorgio Sartor 2003-04-05 15:44:10 UTC 
Created attachment 90924 [details]
New file from lame 3.93.1 with problems

With new gcc-3.2.2-10, lame 3.93.1 compilation goes further,
"encoder.c" is compiled, but it fails at the following line,
with similar error:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I. -I../mpglib/ -I.. -Wall -s
-march=k6-3 -O3 -fomit-frame-pointer -ffast-math -funroll-loops
-maccumulate-outgoing-args -Wall -c vbrquantize.c -MT vbrquantize.lo -MD -MP
-MF .deps/vbrquantize.TPlo  -fPIC -DPIC -o .libs/vbrquantize.lo
vbrquantize.s: Assembler messages:
vbrquantize.s:5440: Error: value of -138 too large for field of 1 bytes at
15357
Comment 4 Piergiorgio Sartor 2003-04-05 15:47:14 UTC 
Created attachment 90925 [details]
Assembly file with problems
Comment 5 Piergiorgio Sartor 2003-05-11 13:38:59 UTC 
New gcc 3.2.3-4 from RawHide shows the same problem with "vbrquantize.c"
Comment 6 Piergiorgio Sartor 2003-06-21 16:28:58 UTC 
Using gcc 3.3-7 from Rawhide the problem is still there,
with "vbrquantize.c".
Comment 7 Piergiorgio Sartor 2003-08-20 18:26:13 UTC 
Tried gcc 3.3.1-1 from Rawhide.
Problem still there, with vbrquantize.c
Comment 8 Piergiorgio Sartor 2003-08-25 20:07:24 UTC 
Again, gcc 3.3.1-2 from Rahide, same story.
Is this going to be fixed sometime or not?
Comment 9 Richard Henderson 2004-10-03 11:50:51 UTC 
Reproduced second failure with gcc 3.2.3-20, but works with 3.3.2-1,
3.4.3 20041001, 4.0.0 20041001.