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

schlie at comcast dot net gcc-bugzilla@gcc.gnu.org
Sat Feb 12 16:37:00 GMT 2005


------- Additional Comments From schlie at comcast dot net  2005-02-12 07:59 -------
Subject: Re:  avr target build broken by recent 'DC'
 type update to libgcc2

> This is a complex mode of DFmode. Is DFmode supported at all on avr?

- no, but doubles are defined as being the same size as floats so that
  shouldn't represent a problem.

  libgcc2 should be basing it's built-in function definitions on the
  type sizes the target defines, not assume them to be of certain modes.

  More specifically, libgcc2 should be defining built-in's based on the
  target's type sizes which may be larger than it's MAX_FIXED_MODE_SIZE,
  (and presumably MAX_FLOAT_MODE_SIZE if it were defined), and properly
  specify their modes based on these specified type sizes, not some
  presumptions based on the size of the target's machine word size, as
  it's largely irrelevant. For example if a target defines:

  #define CHAR_TYPE_SIZE 8
  #define SHORT_TYPE_SIZE 8
  #define INT_TYPE_SIZE 16
  #define LONG_TYPE_SIZE 32
  #define LONG_LONG_TYPE_SIZE 64

  #define MAX_FIXED_MODE_SIZE 32

  #define FLOAT_TYPE_SIZE 32
  #define DOUBLE_TYPE_SIZE 32
  #define LONG_DOUBLE_TYPE_SIZE 32

  #define MAX_FLOAT_MODE_SIZE 0

  It should be presumed that the target will have defined implementations
  for standard integer modes char/short(QI),int(HI),long(HI) instructions,
  but any built-in's required for types larger than the maximum-mode-size
  would need to be defined (with their corresponding correct type modes).

  Implying libgcc2 would need to either use the above defined type-modes,
  and/or define long-long(DI), float(SF), double(SF), complex-float(CF),
  and complex-double(CF); as required to satisfy any built-in requirements.

> If not, why not?

- most simply because DF mode register demands exceed avr's available
  resources; and secondarily it exceeds the demands for typical avr
  class applications in terms of the value of it's precision vs demand
  for machine resources, vs. performance, (as C typically implies double
  precision for transcendental operations by default, for example), etc.

  [actually even long-long(DI) support is likely overkill, but gcc can't
   build without DI mode support as exception headers are defined as
   requiring 64 bits, which it likely shouldn't as it's an unnecessary
   requirement apparently derived from ia64 code; likely benefiting all
   32 bit or less machines, and should likely be relaxed.]

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.




-- 


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



More information about the Gcc-bugs mailing list