This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
-m32 support on sparc
- To: gcc at gcc dot gnu dot org
- Subject: -m32 support on sparc
- From: Brad Lucier <lucier at math dot purdue dot edu>
- Date: Fri, 10 Dec 1999 17:46:14 -0500 (EST)
- Cc: lucier at math dot purdue dot edu
I would like to use the ultrasparc features of my E3000 that are safe in
Solaris 2.5.1, a 32-bit OS, for performance reasons. (Especially the extra
FP registers and whatever long long support is available.) I have built
the 19991210 version of gcc, and it seems to generate correct code for
some important programs I have. So, I have some questions:
(1) What are the correct options to invoke with this system? I'm trying
gcc -m32 -fPIC -O1 -mcpu=v9 -Wa,-xarch=v8plus -mtune=ultrasparc
(2) /usr/include/limits.h defines
#define ULONG_MAX 4294967295UL /* max value of "unsigned long int" */
However, fixincludes changes this to
#ifndef __LONG_MAX__
#if defined (__alpha__) || defined (__sparc_v9__) || defined (__sparcv9)
#define __LONG_MAX__ 9223372036854775807L
#else
#define __LONG_MAX__ 2147483647L
#endif /* __alpha__ || sparc64 */
#endif
#undef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
#undef LONG_MAX
#define LONG_MAX __LONG_MAX__
#undef ULONG_MAX
#define ULONG_MAX (LONG_MAX * 2UL + 1)
Shouldn't the value of ULONG_MAX depend on whether -m32 is used? Or perhaps
whether the compiler is built on a strictly 32bit OS, like Solaris 2.5.1?
After all, gcc.info-4 says:
`-m32'
`-m64'
Generate code for a 32 bit or 64 bit environment. The 32 bit
environment sets int, long and pointer to 32 bits. The 64 bit
environment sets int to 32 bits and long and pointer to 64 bits.
and this doesn't seem to square with the definition of ULONG_MAX given above.
So, should fixincludes be changed in this respect?
Brad Lucier