Patch to fix i960 objc runtime build

[John Wehle]

>> + #define REAL_TYPE       _C_DBL
>
> OK, I give up.  How is this supposed to work?  REAL_TYPE as used in
> ROUND_TYPE_ALIGN is unrelated to the ObjC encoding char _C_DBL, at
> least as I understand the code.

I was hoping you (being the objc expert :-) could tell me.

Basically the objc runtime abuses target macros in several places
in order to correctly (most of the time) determine things that only
the compiler knows about.  In order to make the more complicated
target macros happy objc provides dummy definitions.  I.e. sendmsg.c
has:

  /* this is how we hack STRUCT_VALUE to be 1 or 0 */
  #define gen_rtx(args...) 1
  #define gen_rtx_MEM(args...) 1
  #define gen_rtx_REG(args...) 1
  #define rtx int

Defining REAL_TYPE to _C_DBL in encoding.c seemed the most likely
to do to right thing most of the time.  REAL_TYPE is used to indicate
a floating point value.  objc-api.h mentions _C_FLT and _C_DBL (I
didn't see a long double type).  A float is less likely to need special
handling by ROUND_TYPE_ALIGN than a double.  Defining REAL_TYPE to _C_DBL
should allow ROUND_TYPE_ALIGN to still apply special handling to doubles.
Keep in mind that the type field seen by the target macros when they're
used by the objc runtime are different from the type fields that the macros
were originally written for.  Given that encoding.c currently has:

  /* Various hacks for objc_layout_record. These are used by the target
     macros. */

  #define TREE_CODE(TYPE) *TYPE
  #define TREE_TYPE(TREE) TREE

  #define RECORD_TYPE     _C_STRUCT_B
  #define UNION_TYPE      _C_UNION_B
  #define QUAL_UNION_TYPE _C_UNION_B
  #define ARRAY_TYPE      _C_ARY_B

and:

  /* Some ports (eg ARM) allow the structure size boundary to be
     selected at compile-time.  We override the normal definition with
     one that has a constant value for this compilation.  */
  #undef STRUCTURE_SIZE_BOUNDARY
  #define STRUCTURE_SIZE_BOUNDARY (BITS_PER_UNIT * sizeof (struct{char a;}))

it seemed like a reasonable approach.

BTW: I'm not thrilled by the situation and am more than happy to be guided
by the objc wizards to a better solution.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------