* patch that caused regression PR middle-end/8808
@ 2002-12-18 15:22 Janis Johnson
2002-12-19 3:57 ` Jan Hubicka
0 siblings, 1 reply; 4+ messages in thread
From: Janis Johnson @ 2002-12-18 15:22 UTC (permalink / raw)
To: gcc, jh; +Cc: rodrigc, bangerth
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);
}
-------------------
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.
I'll add this information to the PR.
Janis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: patch that caused regression PR middle-end/8808
2002-12-18 15:22 patch that caused regression PR middle-end/8808 Janis Johnson
@ 2002-12-19 3:57 ` Jan Hubicka
2002-12-19 11:19 ` Richard Henderson
0 siblings, 1 reply; 4+ messages in thread
From: Jan Hubicka @ 2002-12-19 3:57 UTC (permalink / raw)
To: Janis Johnson; +Cc: gcc, jh, rodrigc, bangerth, rth
> 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] 4+ messages in thread
* Re: patch that caused regression PR middle-end/8808
2002-12-19 3:57 ` Jan Hubicka
@ 2002-12-19 11:19 ` Richard Henderson
2002-12-19 15:31 ` Jan Hubicka
0 siblings, 1 reply; 4+ messages in thread
From: Richard Henderson @ 2002-12-19 11:19 UTC (permalink / raw)
To: Jan Hubicka; +Cc: Janis Johnson, gcc, rodrigc, bangerth
On Thu, Dec 19, 2002 at 10:37:53AM +0100, Jan Hubicka wrote:
> 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.
We could have another array, along side FIXED and CALL_USED,
that was UNAVAILABLE. Errors would be issued for using asm
registers in this set.
r~
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: patch that caused regression PR middle-end/8808
2002-12-19 11:19 ` Richard Henderson
@ 2002-12-19 15:31 ` Jan Hubicka
0 siblings, 0 replies; 4+ messages in thread
From: Jan Hubicka @ 2002-12-19 15:31 UTC (permalink / raw)
To: Richard Henderson, Jan Hubicka, Janis Johnson, gcc, rodrigc, bangerth
> On Thu, Dec 19, 2002 at 10:37:53AM +0100, Jan Hubicka wrote:
> > 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.
>
> We could have another array, along side FIXED and CALL_USED,
> that was UNAVAILABLE. Errors would be issued for using asm
> registers in this set.
You mean defining new register array based on new target macro and do
testing only when such macro exists? That sounds like a plan, I can
implement it over the christmas.
Honza
>
>
> r~
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-12-19 23:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-18 15:22 patch that caused regression PR middle-end/8808 Janis Johnson
2002-12-19 3:57 ` Jan Hubicka
2002-12-19 11:19 ` Richard Henderson
2002-12-19 15:31 ` Jan Hubicka
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).