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
next prev 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: linkBe 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).