This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.3 PRs
- From: Jan Hubicka <jh at suse dot cz>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: jh at suse dot cz, gcc at gcc dot gnu dot org
- Date: Mon, 31 Mar 2003 23:22:22 +0200
- Subject: Re: 3.3 PRs
- References: <200303311835.h2VIZvYF011397@sirius.codesourcery.com>
On Mon, Mar 31, 2003 at 10:35:57AM -0800, Mark Mitchell wrote:
>
> Jan --
>
> There are a bunch of 3.3 PRs with your name on them. Let's get these
> resolved ASAP.
>
> target/9929 ice-on-legal-code:
>
> Janis tracked this problem to one of your changes.
>
> You proposed a patch for this, and the discussion ends here:
>
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02281.html
>
> RTH suggested an alternative way of fixing the problem; please
> prepare a patch and submit it.
Unforutnately I am not sure about the fix.
- disabling all subregs as Richard suggested in first mail
will break 64bit support
- I am not at all sure how to implement enabling it only for 32bit
leas as suggested in the other reply as these must use 'p' constraint that
is special cased by reload and regstack
- I am not quite sure why reload need to load whole register,
I hoped Bernd will comment on the reload behaviour in meantime.
Last weeks were extremly hectic for me by non-GCC stuff. I've finished
it today so I am looking forward to do some GCC bugfixing rest of this week :)
This is top priority, sorry for the delays.
>
> optimization/8634 wrong-code:
>
> Janis tracked this problem to one of your changes.
>
This one is fixed by Zdenek's patch you asked for pointer to last time.
> optimization/10056 ice-on-legal-code:
>
> You checked in a patch for this on March 25:
>
> Tue Mar 25 20:48:05 CET 2003 Jan Hubicka <jh at suse dot cz>
>
> PR opt/10056
>
> but the PR is still open. If you fixed it, would you close the PR?
>
> If not, what's up?
>
> optimization/10024 ice-on-legal-code:
>
> This seems like the same issue as 10056.
Yes, it looks the same, I will check and close both once I build the HP-PA corss.
>
> inline-asm/8808 ice-on-illegal-code:
>
> This is a case where the user puts something into a register that is
> probably not of the right type.
>
> Can you confirm that? Should we allow users to use register ("mm0")
> if the data type does not have the same mode as the register in
> question?
There is definitly patch in the queue for this problem.
I see it is in my outging mail but not in gcc-patches archives so probably something went wrong. i am attaching it.
Hi,
another update of forgotten patch
Fri Mar 21 22:04:25 CET 2003 Jan Hubicka <jh at suse dot cz>
PR inline-asm/8088
* i386.c (ix86_hard_regno_mode_ok): Return 0 for MMX/SSE registers
when MMX/SSE is not available.
Index: i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.446.2.25
diff -c -3 -p -r1.446.2.25 i386.c
*** i386.c 21 Mar 2003 20:36:48 -0000 1.446.2.25
--- i386.c 21 Mar 2003 21:02:36 -0000
*************** ix86_hard_regno_mode_ok (regno, mode)
*** 14810,14818 ****
if (FP_REGNO_P (regno))
return VALID_FP_MODE_P (mode);
if (SSE_REGNO_P (regno))
! return VALID_SSE_REG_MODE (mode);
if (MMX_REGNO_P (regno))
! return VALID_MMX_REG_MODE (mode) || VALID_MMX_REG_MODE_3DNOW (mode);
/* We handle both integer and floats in the general purpose registers.
In future we should be able to handle vector modes as well. */
if (!VALID_INT_MODE_P (mode) && !VALID_FP_MODE_P (mode))
--- 14810,14819 ----
if (FP_REGNO_P (regno))
return VALID_FP_MODE_P (mode);
if (SSE_REGNO_P (regno))
! return (TARGET_SSE ? VALID_SSE_REG_MODE (mode) : 0);
if (MMX_REGNO_P (regno))
! return (TARGET_MMX
! ? VALID_MMX_REG_MODE (mode) || VALID_MMX_REG_MODE_3DNOW (mode) : 0);
/* We handle both integer and floats in the general purpose registers.
In future we should be able to handle vector modes as well. */
if (!VALID_INT_MODE_P (mode) && !VALID_FP_MODE_P (mode))