This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Anyone got irix5? I have questions about your ctype implementation
Kaveh R. Ghazi writes:
> > I'll probably submit a equivalent patch
> > defining CPP_PREDEFINES to fix this for 3.1.1.
>
> Ok, I was going to do this, but if you want to take over that's fine.
> The holdup on my end was that I was trying to figure out a way to enable
> it for only pre-6.5 irix6. No need to apply the hack on irix6.5 since
> that appears to work fine.
Agreed in principle, but we're not so cautious on other platforms. At
least I've found out why we need -D_SGI_SOURCE -D__EXTENSIONS__ with g++
-ansi on IRIX 6.2, but not on 6.5:
The failures on 6.2 happen because acosl and many other functions are not
declared by math.h. All those definitions are guarded by _SGIAPI, which
has different definitions on 6.2 and 6.5:
* 6.2:
#define _SGIAPI (defined(_SGI_SOURCE) && _NO_POSIX && _NO_XOPEN4)
i.e. _SGI_SOURCE and no specific conflicting standard selected
* 6.5:
#define _SGIAPI ((defined(_SGI_SOURCE) && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || (_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5))
i.e. (_SGI_SOURCE and ...) or (!__EXTENSIONS__ and ...)
The second part gets us the definitions without _SGI_SOURCE and
__EXTENSIONS__.
I noticed a couple of inconsistencies in this area, though:
Two platforms (i.e. aix and irix5.2) define the necessary feature test
macros in libstdc++-v3/config/os/.../os_defines.h, allowing fine grained
control over the O/S versions to which they apply. The others seem to use
CPLUSPLUS_CPP_SPEC to achieve the same effect across all O/S versions,
irrespective if they are needed everywhere. This seems to be the preferred
solution right now, although it creates problems for C++ programmers
desiring fine control over declarations from what standards are visible.
If Mark still thinks the CPLUSPLUS_CPP_SPEC variant is best, I suggest we
ignore the IRIX 6.2 vs. 6.5 difference for now and just treat them the
same. It just isn't worth the trouble of creating a different iris62.h
only for this issue.
I can test a patch for this if desired. Otherwise your patch to
irix5.2/bits/os_defines.h should go into the 3.1 branch after the release
is cut.
Rainer