earle@SUN.COM (Greg Earle) (12/24/88)
In Sun's /usr/include/math.h, there is the following code:
---------------------------------------------------------------------------
/* mc68000 returns float results in d0, same as int */
#ifdef mc68000
#define FLOATFUNCTIONTYPE int
#define RETURNFLOAT(x) return (*(int *)(&(x)))
#define ASSIGNFLOAT(x,y) *(int *)(&x) = y
#endif
/* sparc returns float results in %f0, same as top half of double */
#ifdef sparc
#define FLOATFUNCTIONTYPE double
#define RETURNFLOAT(x) { union {double _d ; float _f } _kluge ; _kluge._f = (x) ; return _kluge._d ; }
#define ASSIGNFLOAT(x,y) { union {double _d ; float _f } _kluge ; _kluge._d = (y) ; x = _kluge._f ; }
#endif
/* i386 returns float results on stack as extendeds, same as double */
#ifdef i386
#define FLOATFUNCTIONTYPE float
#define RETURNFLOAT(x) return (x)
#define ASSIGNFLOAT(x,y) x = y
#endif
...
extern FLOATFUNCTIONTYPE r_fabs_(), r_floor_(), r_ceil_(), r_rint_();
extern FLOATFUNCTIONTYPE r_hypot_();
extern FLOATFUNCTIONTYPE ...
...
------------------------------------------------------------------------------
When I compiled a program with gcc 1.32 on my Sun-3 that includes this file,
this is the preprocessor output generated:
poseur:1:255 # gcc -v -E -fstrength-reduce -finline-functions -fcombine-regs -ansi -W -sun3 -c piemenu_track.c -o piemenu_track.i
gcc version 1.32
/usr/local/lib/gcc-cpp -v -undef -D__GNUC__ -T -$ -D__STRICT_ANSI__ -D__mc68000__ -D__sun__ -D__unix__ -D__HAVE_68881__ piemenu_track.c -o piemenu_track.#2.i
GNU CPP version 1.32
poseur:1:256 #
When I look at the .i file, the preprocessor has not matched the
`#ifdef mc68000' line in the include file. This leaves FLOATFUNCTIONTYPE
undefined, and gcc itself promptly gacks on that next batch of declarations
in <math.h>.
I noticed that gcc.c appears to always generate `-undef' for gcc-cpp, but
(in cccp.c, main()) if `cpp' is fed a command line with `-undef', then
it appears to disable the built-in predefined symbols (which are `-Dmc68000'
`-Dsun', and `-Dunix' on a Sun-3):
case 'u':
/* Sun compiler passes undocumented switch "-undef".
Let's assume it means to inhibit the predefined symbols. */
inhibit_predefs = 1;
break;
So now I'm confused - why are the builtins always turned off (if, indeed,
this is the case)? And if they are, then how is it that `#ifdef sun' still
seems to match, without actually manually having to compile with `-Dsun'?
Why does this magic not extend to `#ifdef mc68000' ...
I noticed the gcc info file (gcc.info-6) says,
`CPP_PREDEFINES'
...
For example, on the Sun, one can use the following value:
"-Dmc68000 -Dsun -Dunix"
The result is to define the macros `__Dmc68000__', `__sun__' and
`__unix__' unconditionally, and the macros `mc68000', `sun' and
`unix' provided `-ansi' is not specified.
(Shouldn't that be `__mc68000__'?) OK, so why is it that these predefines
are disabled when `-ansi' is used? Does the dpAns only allow defines such
as these to have prefixed & suffixed underscores? Do I need to go through
all the Sun include files, looking for `#ifdef [arch]' statements and
changing them to `#if defined([arch]) || defined(__[arch]__)'?
---------------------------------------------------------------------------
Somewhat related: the gcc man page says
The macro __STRICT_ANSI__ is predefined when the `-ansi'
option is used. Some header files may notice this
macro and refrain from declaring certain functions or
defining certain macros that the ANSI standard doesn't
call for;
Since it appears that (inside cccp.c) `__STDC__' is defined to the
preprocessor if `-traditional' is not specified, why would header files
use `__STRICT_ANSI__' and not the standard `__STDC__' which is in dpAns C?
[ Please excuse my extreme ignorance of the internal workings; I think this ]
[ is the first program I've tried to `gcc-ize' that included a file with an ]
[ `#ifdef mc68000' in it ... ]
[ ]
[ If I can get through this, I can submit more changes for `fixincludes' to ]
[ `gcc-ize' other Sun include files that need to be fixed, such as ]
[ <pixrect/memvar.h> and <floatingpoint.h>. ]
- Greg Earle
Sun Los Angeles Consulting
earle@Sun.COM
...!sun!earle