Bug 59083 - gcc-3.1-0.18 aborts when using -mmmx flag
Summary: gcc-3.1-0.18 aborts when using -mmmx flag
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-30 18:18 UTC by Valdis Kletnieks
Modified: 2007-04-18 16:39 UTC (History)
0 users

Clone Of:
Last Closed: 2002-02-01 16:33:28 UTC

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

Description Valdis Kletnieks 2002-01-30 18:18:05 UTC
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 18:19:23 UTC
Created attachment 43996 [details]
Pre-processed C source for -mmx compiler abort

Comment 2 Jakub Jelinek 2002-02-01 16:17:08 UTC
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 16:33:22 UTC
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 16:32:15 UTC
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.