Host/Target confusion in Dwarf output

[Ian Lance Taylor]

Michael Eager <eager@eagercon.com> 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