Bug 59083 - gcc-3.1-0.18 aborts when using -mmmx flag
gcc-3.1-0.18 aborts when using -mmmx flag
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-01-30 13:18 EST by Valdis Kletnieks
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-01 11:33:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Pre-processed C source for -mmx compiler abort (78.27 KB, application/octet-stream)
2002-01-30 13:19 EST, Valdis Kletnieks
no flags Details

  None (edit)
Description Valdis Kletnieks 2002-01-30 13:18:05 EST
Description of Problem: ICE when compiling attached program with -mmmx

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

How Reproducible: Compile the attached program with flags listed below.

Steps to Reproduce:
1. gunzip mmx-botch.i.gz
2. gcc -c -O3  -mcpu=i686 -march=i686 -fexpensive-optimizations
-fomit-frame-pointer -mmmx  mmx-botch.i
3. Watch the error message 

Actual Results:
radeon_state.c: In function `radeonDDUpdateHWState':
radeon_state.c:1032: insn does not satisfy its constraints:
(insn 906 903 595 (set (reg:SF 29 emm0 [162])
        (mem:SF (plus:SI (reg/f:SI 7 esp)
                (const_int 76 [0x4c])) [0 S4 A32])) 90 {*movsf_1} (nil)
radeon_state.c:1032: Internal compiler error in reload_cse_simplify_operands, at
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.

Expected Results:
A correct compile.

Additional Information: 
Omitting the -mmmx flag works.  Yes, I know it's bleeding-edge, but if nobody
files bug reports, it will never get fixed.
Comment 1 Valdis Kletnieks 2002-01-30 13:19:23 EST
Created attachment 43996 [details]
Pre-processed C source for -mmx compiler abort
Comment 2 Jakub Jelinek 2002-02-01 11:17:08 EST
Well, primarily this is bug in the source (does invalid type punning),
so even if gcc did not ICE on this (which is a bug), it could do anything
(unless -fno-strict-aliasing is given).
I've created a minimal testcase, no fix yet.
Comment 3 Valdis Kletnieks 2002-02-01 11:33:22 EST
Are you saying "it *could* do anything, unless -fno-strict-aliasing is set" as
meaning "if no-strict-aliasing was set, it would do something specific,
otherwise it's free to generate any code it wants"?

Or did you mean "It can't do anything legal without -fno-strict-aliasing"?  I'm
assuming you meant this, in which case having the compiler issue a reasonable
error message rather than an ICE is perfectly acceptable - I'll take the error
message back to the code authors and get the code fixed. ;)

Interestingly enough, the compiler didn't seem to mind the type punning when
-mmmx wasn't specified - is that the root cause of THIS bug (that it failed to
catch it), or is that a second problem?
Comment 4 Jakub Jelinek 2002-02-06 11:32:15 EST
The ICE is fixed in gcc-3.1-0.21.
With the above I meant to say that the source is triggering undefined behaviour
and that -fno-strict-aliasing disables optimizations taking advantage of that,
so with -fno-strict-aliasing (and 3.1-0.21) the code should work properly,
while without that option it may work now but may read a value before it is
written or whatever in the next gcc rpm release.

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