This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cross gcc port problem
- To: "Hans-Peter Nilsson" <hans-peter dot nilsson at axis dot com>
- Subject: Re: cross gcc port problem
- From: "Oleg I. Vdovikin" <vdovikin at jscc dot ru>
- Date: Mon, 19 Mar 2001 12:05:57 +0300
- Cc: <gcc at gcc dot gnu dot org>
- References: <200103182136.WAA11584@ignucius.axis.se>
Hello,
> Sorry, can't help you with your first problem. Any of many
> possible errors in the port register class description and
> generally the port register description can cause this. (Let's
> not assume it's a core gcc bug for the moment. ;-)
Yes, but it still not clear to me why gcc tries to place all "pointers"
to the base registers, so making them register variables. Can you imagine
why this happens? My port contains the following simple definitions:
enum reg_class { NO_REGS, ACCUM_REGS, BASE_REGS, ALL_REGS,
LIM_REG_CLASSES };
#define REG_CLASS_CONTENTS {0x00, 0x01, 0x1e, 0x1f}
#define GENERAL_REGS ACCUM_REGS
#define BASE_REG_CLASS BASE_REGS
#define INDEX_REG_CLASS NO_REGS
Plus defined PREFERRED_RELOAD_CLASS, so LABEL_REF, SYMBOL_REF, CONST
needs BASE_REGS and CLASS for others, but defining this macro as just CLASS
does not solve the problem... It's not a problem at this point. I'm also has
SECONDARY_RELOAD_CLASS defined to allow base registers to be stored in the
memory.
> Try having a "define_expand" for this. Alternatively, you might
> want to look into defining the "cbranchsi4" and "cmov" patterns.
> Though I think only the thumb-within-arm target uses it, and it's
> unfortunately not documented. See also
> <URL:http://gcc.gnu.org/ml/gcc/2001-01/msg01806.html> with follow-ups.
Ok, will try.
Thanks,
Oleg.