This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

-m32 support on sparc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]