Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jan 06, 2021 at 04:20:22PM -0500, David Edelsohn wrote:
> Your response doesn't correspond to the patch nor to what I described.
> 
> Nowhere did I say that int64_t must correspond to "long".  The patch
> specifically chooses "long" or "long long" based on the
> __SIZEOF_LONG__ *and* __SIZEOF_LONG_LONG__.
> 
> Currently libstdc++ configure tests for the type at configuration
> time.  My patch changes the behavior to retain the test for the type
> at configure time but chooses "long" or "long long" at compile time.
> I don't unilaterally choose "long" or "long long" as the type, but
> rely on the configure test to ensure that __int64_t is a typedef for
> either "long" or "long long".
> 
> The patch does assume that if __int64_t is a typedef for "long" or
> "long long" and this is a 32/64 multilib, then the typedef for the
> other 32/64 mode is an equivalent typedef, which is the case for
> GLIBC, AIX, and other systems that I have checked.

Yes, on glibc it is the case, but it doesn't have to be the case on other
OSes, which is why there is a configure check.  Other OSes can typedef
int64_t to whatever they want (or what somebody choose years ago and is now
an ABI issue).
So, if you wanted to do this, you'd need to check at configure time both
multilibs and determine what to do for both.

I don't really understand the problem you are trying to solve, because
normally the c++config.h header that defines _GLIBCXX_HAVE_INT64_T_LONG etc.
comes from a multilib specific header directory, e.g. on powerpc64-linux,
one has:
/usr/include/c++/11/powerpc64-unknown-linux-gnu/bits/c++config.h
and
/usr/include/c++/11/powerpc64-unknown-linux-gnu/32/bits/c++config.h
(or instead /64/, depending on which multilib is the default) and
g++ driver arranges for the search paths to first look at the multilib
specific subdirectory and only later at the generic one.

	Jakub