This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-2.95pre: Internal compiler error in `gen_add2_insn'
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: gcc-2.95pre: Internal compiler error in `gen_add2_insn'
- From: Jeffrey A Law <law at upchuck dot cygnus dot com>
- Date: Thu, 27 May 1999 02:14:44 -0600
- cc: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, egcs-bugs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <9905261734.AA27034@marc.watson.ibm.com>you write:
> gen_reload() is designed to handle a failure from
> emit_insn(gen_add2_insn()), but it is designed to handle a different type
> of failure. The call to gen_add2_insn() is not protected from predicate
> mismatches by that stage.
>
> Maybe gen_add2_insn() and gen_sub2_insn() should return
> CODE_FOR_nothing instead of aborting. I am not sure of the consequences
> elsewhere in the compiler and their ability to handle that type of return
> value. On the other hand, that is what they should get for another type
> of failure mode that they seem to be able to handle.
Actually, I think we need to make the generic addsi/addi3 expander handle
the counter register.
I'm not sure if it's doc'd anywhere, but the add patterns are considered
special much like the movxx patterns and need to handle some of these
oddball cases.
jeff