Hide Forgot
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) (nil)) radeon_state.c:1032: Internal compiler error in reload_cse_simplify_operands, at reload1.c:8345 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.
Created attachment 43996 [details] Pre-processed C source for -mmx compiler abort
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.
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?
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.