Bug 90843 - Produces illegal assembly (Loop instruction with offset > 128 bytes)
Summary: Produces illegal assembly (Loop instruction with offset > 128 bytes)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 9
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-14 16:31 UTC by Enrique Perez-Terron
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version: 3.2.3-13, 3.3-17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-06 10:45:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The preprocessed version of the file that fails to compile (861.90 KB, application/octet-stream)
2003-05-14 16:40 UTC, Enrique Perez-Terron
no flags Details
A short script that I use to reproduce the error on my system. (3.83 KB, application/octet-stream)
2003-05-14 17:02 UTC, Enrique Perez-Terron
no flags Details

Description Enrique Perez-Terron 2003-05-14 16:31:27 UTC
Description of problem:

Compiling the kernel source rpm (kernel-source-2.4.20-8.i386.rpm)
using gcc-3.2.2-5, I get error message when compiling the file

  {standard input}: Assembler messages:
  {standard input}:10554: Error: value of -141 too large for field 
  of 1 bytes at 27023

Producing an assembly file, i.e. repeating the compile with -S for -c, 
and inspecting line 10554, it contains the instruction "loop .L1876".
The label .L1876 appears in line 10520.  I have no means to check if 
the intervening code fills 141 bytes as the error message says, but it 
appears reasonable.

I attach below the preprocesed file skgepnmi.i, produced with
gcc <flags> -E. I also attach the script that I use to reproduce 
the error, it shows the original compile flags used. 

When reproducing, notice that compiling the .c file without -O fails
because of a preprocessor test:
  #if !defined(__OPTIMIZE__)  ||  !defined(__KERNEL__)
  #warning  You must compile this file with the correct options!
  #warning  See the last lines of the source file.
  #error You must compile this driver with "-O".
If the file is first preprocessed with -O2, and then compiled without it,
it compiles OK. I can also compile directly with -O (no number).

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

How reproducible:

Steps to Reproduce:
1. Install gcc-3.2.2-5
2. Place the attached file skgepnmi.i in a suitable working directory
3. gcc -O2 -fomit-frame-pointer -march=k6 -c skgepnmi.i
Actual results:
/tmp/ccn9jkBk.s: Assembler messages:
/tmp/ccn9jkBk.s:10707: Error: value of -141 too large for field of 1 bytes at 27385

(The line number 10707 here is different from 10554 in the original failure
because I have reduced the number of options to gcc to a minimum.)

Expected results:
No messages. File skgepnmi.o produced.

Additional info:
The error disappears if any one of the three options "-O2",
"-fomit-frame-pointer", or "-march=k6" is deleted.
The error does not happen if the compiler is gcc-3.2.3 built from
unmodified sources.

Comment 1 Enrique Perez-Terron 2003-05-14 16:40:09 UTC
Created attachment 91674 [details]
The preprocessed version of the file that fails to compile

Comment 2 Enrique Perez-Terron 2003-05-14 17:02:01 UTC
Created attachment 91678 [details]
A short script that I use to reproduce the error on my system.

The bug report and the previous atachment is all that is needed
to reproduce the bug.  This script is attached in order to show
the compiler options used when the bug first appeared.

To use the script you must have kernel-source-2.4.20-8 installed.
You probably must run make config and make dep too.  However, you
probably do not need to configure exactly the same, as the script
contains the relevant compiler options. Just in case, I used
make xconfig, loaded configs/kernel-2.4.20-i586.config, but then 
set the architecture to K6.

Comment 3 Enrique Perez-Terron 2003-05-15 20:45:47 UTC
I had reported the error to gnatsweb/gcc (gnu.org's bug reporting system)
before I knew that the bug does not happen in gcc 3.2.3. Now they say
my report duplicates another report that was fixed in 3.2.3. It might be 
usefull for you to know their resolution.



Comment 4 Jakub Jelinek 2003-08-06 10:45:39 UTC
Works for me in gcc-3.2.3-13.

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