[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-13 00:10 -------
Subject: Re:  [4.0 Regression] avr target build broken
 by recent 'DC' type update to libgcc2

Or simpler, for each target (as gcc libgcc2 has trouble figuring it out):

  #define CHAR_MODE QI
  #define SHORT_MODE HI
  #define INT_MODE HI
  #define LONG_MODE SI
  #define LLONG_MODE DI
  #define FLOAT_MODE SF
  #define DOUBLE_MODE SF
  #define LDOUBLE_MODE SF

 (where then if desired
  #define INT_TYPE_SIZE ( MODE_SIZE( INT_MODE ) * UNITS_PER_WORD )
  ...)

Then within libgcc2, simply replace all the error prone logic with:

  typedef          int   CHAR_T     __attribute__ ((mode (CHAR_MODE)));
  typedef          int   SHORT_T    __attribute__ ((mode (SHORT_MODE)));
  typedef          int   INT_T      __attribute__ ((mode (INT_MODE)));
  typedef          int   LONG_T     __attribute__ ((mode (LONG_MODE)));
  typedef          int   LLONG_T    __attribute__ ((mode (LLONG_MODE)));
  typedef          float FLOAT_T    __attribute__ ((mode (FLOAT_MODE)));
  typedef          float DOUBLE_T   __attribute__ ((mode (DOUBLE_MODE)));
  typedef          float LDOUBLE_T  __attribute__ ((mode (LDOUBLE_MODE)));
  typedef _Complex float CFLOAT_T   __attribute__ ((mode (FLOAT_MODE)));
  typedef _Complex float CDOUBLE_T  __attribute__ ((mode (DOUBLE_MODE)));
  typedef _Complex float CLDOUBLE_T __attribute__ ((mode (LDOUBLE_MODE)));

 (where then one could define macros to define correctly named built-ins:
  #define SYMBOL2(a,b)    a ## b
  #define SYMBOL3(a,b)    a ## b ## c

  extern CFLOAT_T SYMBOL3(__add,CFLOAT_MODE,3)( CFLOAT_T, CFLOAT_T );

  ... to define built-in functions with correct types and mode names. Which
  seems much preferred and less error prone than attempting to at best guess
  a targets defined supported type sizes and corresponding modes; and then
  use them to define built-in functions named after the wrong modes...)

... hypothetically.







-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920