This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Bad offset to struct member in generated code


I have a problem while porting gcc to a custom processor. Here is a
simplified example:

struct big_struct {
	int a;
	char b;
	char c;
} testme;

char char_tmp;
int int_tmp;

int testit(void)
	char_tmp = testme.c;
	int_tmp = testme.a;

For the first line of code in testit(), gcc will load the address of
'testme.c' into a register, then do an indirect 8-bit load with an
offset of 0 to fetch the value of 'testme.c'. This is fine.

For the second line, gcc will reuse the same address register, and
generate an indirect 32-bit load with an offset of -5 to fetch the
value of 'testme.a'. But on our custom processor, the offsets of
indirect load instructions are scaled by the size of the data item.
So the assembly instruction generated for the second line is something
like "ld32 %r1, %r0, -5/4", which can not be translated by the

So when accessing a data structure, we need gcc to always use a base
address that is a multiple of 4, to prevent this from happening.

So how do I tell gcc about this limitation of our architecture? Do I do
this somehow using the REG_MODE_OK_FOR_BASE_P or
GO_IF_MODE_DEPENDENT_ADDRESS macros in our architecture's .h file? I am
using the gcc 4.0.2 sources if that matters.

paulz at synopsys dot com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]