Michael Eager <[EMAIL PROTECTED]> writes: > I was looking through dwarf2out.c, tracking down the > cause for different assembly code being generated > when gcc was run on 32-bit and 64-bit hosts. > > In dwarf2out.c, there are several places where decisions > about what to generate in the .s file are based on > HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or > similar. For example, when generating a long long value, > on a 32-bit host, the *target* assembly code will contain > two .4byte ops, while on a 64-bit host, a single .8byte > op is generated. There are a number of other differences. > > The assembler for a 32-bit target might not have a .8byte > operator. So, when run on a 32-bit host, everything is OK. > On a 64-bit host, the assembly fails. > > It seems to me that the same assembly code should be generated > independent of whether gcc is run on a 32-bit or 64-bit > host and all of these HOST_* tests should actually be > target domain parameters, like BITS_PER_WORD.
It is sad but true that there are various cases in gcc which differ based on the size of an integer on the host. So far as I know none of them amount to bugs, but as you've seen they do lead to different code generation. The most obvious difference here is that CONST_INTs in RTL are stored as HOST_WIDE_INTs. And it is that difference which are you seeing, propagated into the debug code. I think that in general it would be good to fix these issues, so that we generate the same assembler code for a given target from any host. The cases to really think through in detail are a 32-bit host and a 64-bit target. With the current definition of RTL, I don't think you can fix dwarf2out.c independently of fixing other parts of the compiler. But, if I am wrong in that, go for it. Ian
