This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2
- From: "schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Feb 2005 00:10:55 -0000
- Subject: [Bug target/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2
- References: <20050212040652.19920.schlie@comcast.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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