Re: [Patch] Fix emit-rtl.c for 64-bit targets

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Eric wrote:

> We can't depend on SFmode or DFmode being equal to UNITS_PER_WORD.
> They are precisely 32 and 64 bits wide. I propagated this further as 
> well.

[ Strictly speaking they're 4, resp. 8 * BITS_PER_UNIT ]

That's not the only thing ... watch this sequence:

f/com.h defines:

/* The C front-end provides __g77_integer and __g77_uinteger types so
that
   the appropriately-sized signed and unsigned integer types are
available
   for libf2c.  If you change this, also the definitions of those types
   in ../c-decl.c. */
#define FFECOM_f2cINTEGER                       \
  (LONG_TYPE_SIZE == FLOAT_TYPE_SIZE            \
   ? FFECOM_f2ccodeLONG                         \
   : (INT_TYPE_SIZE == FLOAT_TYPE_SIZE          \
      ? FFECOM_f2ccodeINT                       \
      : (abort (), -1)))

FLOAT_TYPE_SIZE comes from defaults.h:

#ifndef FLOAT_TYPE_SIZE
#define FLOAT_TYPE_SIZE BITS_PER_WORD
#endif

and - on 64-bit targets like the Alpha - BITS_PER_WORD is (drum-roll
...):
[ quoting config/alpha/alpha.h: ]

/* Width in bits of a "word", which is the contents of a machine
register.
   Note that this is not necessarily the width of data type `int';
   if using 16-bit ints on a 68000, this would still be 32.
   But on a machine with 16-bit registers, this would be 16.  */
#define BITS_PER_WORD 64

Hah !  Now I understand why the very same run of our numerical weather
forecasting system takes twice the amount of memory on my DS10 as on my
(Pentium II) laptop :-) :-)

Seriously - what's the correct way out of this mess ?

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)