This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Fw: [Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload ofa psuedo reg into f0 for a DImode expr
- From: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- To: rth at redhat dot com
- Cc: dje at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 25 Nov 2004 14:35:11 +0100
- Subject: Fw: [Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload ofa psuedo reg into f0 for a DImode expr
Hello Richard,
related to PR 18641, the question came up how to allow the middle-end to
deduce whether or not the result of LEGITIMIZE_RELOAD_ADDRESS is an
offsettable address or not. You may look at the PR log for more info.
Do you have some suggestions how (or whether) to implement such an
interface?
Possibilities would appear to include:
- L_R_A must always return offsettable addresses
- A global target macro (as suggested by David below)
- A fine-grained flag set by L_R_A for each case
Thanks,
Ulrich
"dje at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote on 11/24/2004
07:19:03 PM:
> ------- Additional Comments From dje at gcc dot gnu dot org
> 2004-11-24 18:18 -------
> Allowing the middle-end to know that the L_R_A address is offsettable
looks
> like a better solution to me. The design is an issue for RTH. One
> possibility is a target macro to decide if L_R_A addresses should be
assumed
> offsettable:
>
> #if LRA_OFFSETTABLE
> || address_reloaded[i] > 0
> #else
> || address_reloaded[i] == 1
> #endif
> )
>
> Finer granlarity information from LRA is more complicated.
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.