This is the mail archive of the
mailing list for the GCC project.
Re: Host/Target confusion in Dwarf output
- From: Ian Lance Taylor <iant at google dot com>
- To: Michael Eager <eager at eagercon dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: 12 Jul 2007 11:44:13 -0700
- Subject: Re: Host/Target confusion in Dwarf output
- References: <4696557A.firstname.lastname@example.org>
Michael Eager <email@example.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
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.