This is the mail archive of the
mailing list for the GCC project.
Re: RFA: Fix ICE in MN10300's address_cost function
- From: Jeff Law <law at redhat dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 02 Oct 2009 09:45:24 -0600
- Subject: Re: RFA: Fix ICE in MN10300's address_cost function
- References: <email@example.com> <4AC37068.firstname.lastname@example.org> <4AC472ED.email@example.com> <4AC4AAF0.firstname.lastname@example.org> <4AC5FFAF.email@example.com>
On 10/02/09 07:27, Nick Clifton wrote:
Hi Paolo, Hi Jeff,OK. Note however, that several other ports have this same bug (possibly
latent). I can trivially see the cris, fr30, frv, m32c m68hc11, mep,
moxie, pdp11, pico, score, stormy16 and possibly others that will need a
So I guess the question is: why does create_new_invariant think that it
has an address at this point. I do not know. Maybe it is just assuming
that it might have an address, and so it computes the address cost in
case it is needed later on ?
Yes, but this is useless. Just make it
(memory_address_p (word_mode, SET_SRC (set)
&& address_cost (SET_SRC (set), word_mode,
speed) < COSTS_N_INSNS (1));
That did not solve the problem. A little more investigation revealed
the fact that the MN10300 was saying that (CONST_DOUBLE) is a valid
memory address. (Obviously really with hindsight). So I would like
to withdraw my previous patch and instead offer the one below. This
one also fixes the newlib build problem, and does not introduce any
new testsuite failures.
I am not sure if the patch to create_new_invariant() is still needed.
Certainly the MN10300 port builds without it. Paolo - what do you
Ok to apply the mn10300.h patch ?
2009-10-02 Nick Clifton <firstname.lastname@example.org>
* config/mn10300/mn10300.h (CONSTANT_ADDRESS_P):