patch that caused regression PR middle-end/8808

[Jan Hubicka]

> The regression reported in PR middle-end/8808 showed up starting
> with this patch:
> 
> Tue Feb 13 13:31:33 CET 2001  Jan Hubicka  <jh@suse.cz>
> 
> 	* i386.c (print_reg): Use ANY_FP_REG instead of FP_REG
> 	* i386.h (MASK_128BIT_LONG_DOUBLE): Renumber
> 	(MASK_SSE2): New.
> 	(MASK_MIX_SSE_I387): New.
> 	(TARGET_SSE): SSE2 imply SSE.
> 	(TARGET_SSE2, TARGET_MIX_SSE_I387): New.
> 	(TARGET_SWITCHES): Add "sse2", "mix-sse-i387".
> 	(enum reg_class): Add new classes.
> 	(REG_CLASS_NAMES): Likewise.
> 	(REG_CLASS_CONTENTS): Likewise.
> 	(ANY_FP_REG_P, ANY_FP_REGNO_P, SSE_REG_P, SSE_FLOAT_MODE): New macros.
> 	(REG_CLASS_FROM_LETTER): 'x' and 'y' is SSE_REGS only when SSE is
> 	supported. Add 'Y' to be SSE_REGS when SSE2 is supported.
> 	(CLASS_MAX_NREGS): Use new macros.
> 	(REGISTER_MOVE_COST): Rewrite using SECONDARY_MEMORY_MAYBE_NEEDED.
> 	* i386.md (pushsf, movsf): Support SSE.
> 	(pushdf_nointeger, pushdf_integer, pushdf): Support SSE, update
> 	splitters to use ANY_FP_REGNO_P.
> 	(movdf_nointeger, movdf_integer): Likewise.
> 
> Here's a small test case that causes the compiler to ICE when compiled
> on i686-linux:
> 
> -------------------
> void f(unsigned long long int);
> 
> void g () {
>   register unsigned long long int i asm ("mm0");
>   f(i);
> }
> -------------------

Is this expected to work at all?

> 
> Output from the compiler (current mainline):
> 
> 8808.c: In function `g':
> 8808.c:6: error: insn does not satisfy its constraints:
> (insn 18 23 28 (nil) (set (mem:DI (plus:SI (reg/f:SI 6 ebp)
>                 (const_int -8 [0xfffffff8])) [0 S8 A8])
>         (reg/v:DI 29 rmm0)) 59 {*movdi_2} (nil)
>     (nil))
> 8808.c:6: internal compiler error: in extract_constrain_insn_cached, at recog.c:2092
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> 
> The test compiles with -march=pentium4; perhaps the compiler should
> validate asm instructions against the target architecture and give
> a meaningful error message in this case.

Yes, however I am not at all sure how this can be done.  Fixed register,
for instance can be used in the asm("xxx") in rare situations, so I
really don't see how one can validate such things.

Honza
> 
> I'll add this information to the PR.
> 
> Janis