public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: middle-end/8808
@ 2002-12-19  8:06 Wolfgang Bangerth
  0 siblings, 0 replies; only message in thread
From: Wolfgang Bangerth @ 2002-12-19  8:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR middle-end/8808; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/8808
Date: Thu, 19 Dec 2002 09:58:06 -0600 (CST)

 ---------- Forwarded message ----------
 Date: Thu, 19 Dec 2002 10:37:53 +0100
 From: Jan Hubicka <jh@suse.cz>
 To: Janis Johnson <janis187@us.ibm.com>
 Cc: gcc@gcc.gnu.org, jh@suse.cz, rodrigc@attbi.com, bangerth@ticam.utexas.edu,
      rth@cygnus.com
 Subject: Re: patch that caused regression PR middle-end/8808
 
 > 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
 


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2002-12-19 16:06 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-19  8:06 middle-end/8808 Wolfgang Bangerth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).