On Fri, 6 Aug 2010, Christophe Lyon wrote: > On 06.08.2010 15:53, Joseph S. Myers wrote: > > On Fri, 6 Aug 2010, Christophe LYON wrote: > > > > > From my brief investigation, I think that the problem is due to the fact > > > that > > > struct real_value uses the 'long' type for the 'sig' field, while the > > > computation of REAL_WIDTH relies on HOST_BITS_PER_WIDE_INT. > > > > No, this is not a problem; it's fine to use long in the representation but > > HOST_WIDE_INT when stored in an rtx. The issue appears rather to be with > > > > #define REAL_VALUE_TYPE_SIZE (SIGNIFICAND_BITS + 32) > > > > where with 64-bit long there are going to be 32 bits of padding in this > > structure that are not allowed for. Try changing that 32 to > > HOST_BITS_PER_LONG. > > > > I does not fix my problem: HOST_BITS_PER_LONG is still 32. Remember, my host > is ARM, my target is ARM, but my build machine is x86_64, which makes the > 'sig' field of 'real_value' an array of 5 * 64 bits, while SIGSZ, > SIGNIFICAND_BITS and REAL_VALUE_TYPE_SIZE are all defined wrt to > HOST_BITS_PER_LONG, which is 32.
Then the problem is that this structure is being defined for the build system using macros whose values are set of the host; logically, when compiling this code for the build system, HOST_* should have definitions that are correct for the build system rather than for the host, but it is also possible that certain structures do not need to be defined on the build system at all. You will need to gain a full understanding of how the definitions are used on the build system and whether build/host differences will cause any issues for generated files used in the build in order to work out a proper fix. There are many places in the compiler that hardcode the use of "long" in this structure; you cannot change that type safely with a local patch. -- Joseph S. Myers jos...@codesourcery.com
