This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Use __LONG_LONG_MAX__ if LONG_LONG_MIN etc are not available
- To: rittle at labs dot mot dot com
- Subject: Re: PATCH: Use __LONG_LONG_MAX__ if LONG_LONG_MIN etc are not available
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Tue, 31 Jul 2001 09:46:07 -0700 (PDT)
- cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
> contains unstated assumptions that only targets that define __linux__
> use glibc etc)... Why this change causes no problems for other glibc
> Linux targets is beyond me... Perhaps, no one else has long long
> support enabled at the moment?
hmmm. It looks like this is tripping up the arm build too:
ftp://ftp.netwinder.org/pub/build/gcc/armv4l/20010730/build.log
> Instead of all the shenanigans to get this right in light of various
> glibc versions and command line switches that influence limits.h, how
> about we convert uses of LONG_LONG_MIN, LONG_LONG_MAX and
> ULONG_LONG_MAX to use __LONG_LONG_MAX__ (which is unconditionally
> defined by the gcc-generated limits.h file) when the former macros are
> not available. I will arbitrarily key off LONG_LONG_MIN.
Sounds great.
> To be installed on mainline and 3.0 after others that care about
> related issues have a chance to complain. BTW, armv4l-*-linux-gnu
> bootstraps are broken on both 3.0 branch and mainline at the moment
> due to the latest round of libstdc++ configuration patches so we need
> this technique or a replacement ASAP.
Yep. Looks good to me.
thanks!