public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/19920] avr target build broken by recent 'DC' type update to libgcc2
Date: Sat, 12 Feb 2005 16:37:00 -0000	[thread overview]
Message-ID: <20050212075959.12540.qmail@sourceware.org> (raw)
In-Reply-To: <20050212040652.19920.schlie@comcast.net>


------- 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


  parent reply	other threads:[~2005-02-12  8:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-12 16:29 [Bug c/19920] New: " schlie at comcast dot net
2005-02-12 16:32 ` [Bug target/19920] " pinskia at gcc dot gnu dot org
2005-02-12 16:37 ` schlie at comcast dot net [this message]
2005-02-12 16:46 ` bjoern dot m dot haase at web dot de
2005-02-12 19:28 ` [Bug target/19920] [4.0 Regression] " pinskia at gcc dot gnu dot org
2005-02-12 22:32 ` bjoern dot m dot haase at web dot de
2005-02-12 22:35 ` bjoern dot m dot haase at web dot de
2005-02-13 16:44 ` schlie at comcast dot net
2005-02-14 15:52 ` corsepiu at gcc dot gnu dot org
2005-02-14 15:56 ` steven at gcc dot gnu dot org
2005-02-14 15:59 ` [Bug target/19920] [4.0 Regression] build broken on several targets due to " steven at gcc dot gnu dot org
2005-02-14 17:51 ` corsepiu at gcc dot gnu dot org
2005-02-14 19:53 ` [Bug middle-end/19920] " pinskia at gcc dot gnu dot org
2005-02-15  0:54 ` schlie at comcast dot net
2005-02-15  5:32 ` bjoern dot m dot haase at web dot de
2005-02-15 23:24 ` pinskia at gcc dot gnu dot org
2005-02-16  6:27 ` bjoern dot m dot haase at web dot de
2005-02-16 15:30 ` corsepiu at gcc dot gnu dot org
2005-02-16 16:30 ` schlie at comcast dot net
2005-02-16 19:14 ` corsepiu at gcc dot gnu dot org
2005-02-16 19:45 ` schlie at comcast dot net
2005-02-17  9:42 ` rth at gcc dot gnu dot org
2005-02-17 10:00 ` cvs-commit at gcc dot gnu dot org
2005-02-17 22:47 ` rth at gcc dot gnu dot org
2005-04-20  2:25 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050212075959.12540.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).