public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	"libstdc++" <libstdc++@gcc.gnu.org>,
	Iain Sandoe <iain@sandoe.co.uk>,
	"CHIGOT, CLEMENT" <clement.chigot@atos.net>
Subject: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T
Date: Wed, 6 Jan 2021 13:38:25 -0500	[thread overview]
Message-ID: <CAGWvnyk0q7RSgiwKr-e5R002JRrq+udBCNdaukWHRD-3L=DWgA@mail.gmail.com> (raw)

Use __SIZEOF_LONG__ and __SIZEOF_LONG_LONG__ to determine the type of
streamoff at compile time instead of _GLIBCXX_HAVE_INT64_T_LONG and
_GLIBCXX_HAVE_INT64_T_LONG_LONG.

Currently the type of streamoff is determined at libstdc++ configure
time, chosen by the definitions of _GLIBCXX_HAVE_INT64_T_LONG and
_GLIBCXX_HAVE_INT64_T_LONG_LONG.  For a multilib configuration, the
difference is encoded in the different multilib header file paths.
For "FAT" library targets that package 32 bit and 64 bit libraries
together, G++ also expects a single header file directory hierarchy,
causing an incorrect value for streamoff in some situations.

This patch changes the only use of _GLIBCXX_HAVE_INT64_T_XXX to test
__SIZEOF_LONG__ and __SIZEOF__LONG_LONG__ at compile time.  Because
libstdc++ explicitly probes the type of __int64_t to choose the
declaration of streamoff, this patch only performs the dynamic
determination if either _GLIBCXX_HAVE_INT64_T_LONG or
_GLIBCXX_HAVE_INT64_T_LONG_LONG are defined.  In other words, it does
assume that if either one is defined, the other is defined, i.e., that
__int64_t is a typedef for one of those two types when one or the
other is present.  But it then dynamically chooses the type based on
the size of "long" and "long long" instead of using the configure time
value so that the header dynamically adapts to the 32/64 mode of GCC.
If neither __GLIBCXX_HAVE_INT64_T_XXX macro is defined, the original
logic proceeds, using either __int64_t or "long long".

Based on the configure time definitions, the size should be one or the
other when one of the macros is defined.  I can add an error case if
neither __SIZEOF_LONG__ nor __SIZEOF_LONG_LONG__ are 8 despite
__GLIBCXX_HAVE_INT64_T_XXX defined.

Is this an acceptable solution to determine the value at compile-time?

Thanks, David

diff --git a/libstdc++-v3/include/bits/postypes.h
b/libstdc++-v3/include/bits/postypes.h
index cb44cfe1396..81b9c4c6ae5 100644
--- a/libstdc++-v3/include/bits/postypes.h
+++ b/libstdc++-v3/include/bits/postypes.h
@@ -84,10 +84,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    *  Note: In versions of GCC up to and including GCC 3.3, streamoff
    *  was typedef long.
   */
-#ifdef _GLIBCXX_HAVE_INT64_T_LONG
+#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
+    || defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
+
+#if __SIZEOF_LONG__ == 8
   typedef long          streamoff;
-#elif defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
+#elif __SIZEOF_LONG_LONG__ == 8
   typedef long long     streamoff;
+#endif
+
 #elif defined(_GLIBCXX_HAVE_INT64_T)
   typedef int64_t       streamoff;
 #else

             reply	other threads:[~2021-01-06 18:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 18:38 David Edelsohn [this message]
2021-01-06 18:55 ` Marc Glisse
2021-01-06 19:11   ` David Edelsohn
2021-01-06 19:37 ` Jakub Jelinek
2021-01-06 21:20   ` David Edelsohn
2021-01-06 21:41     ` Jakub Jelinek
2021-01-06 23:01       ` David Edelsohn
2021-01-06 23:39         ` Jakub Jelinek
2021-01-06 23:45           ` Jakub Jelinek
2021-01-07  0:41             ` David Edelsohn
2021-01-08 18:37               ` Jonathan Wakely
2021-01-08 18:52                 ` Jakub Jelinek
2021-01-08 20:35                   ` David Edelsohn
2021-04-29 20:06                 ` David Edelsohn
2021-04-29 20:23                   ` Jonathan Wakely
2021-04-30 19:31                   ` Jonathan Wakely
2021-04-30 20:18                     ` David Edelsohn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGWvnyk0q7RSgiwKr-e5R002JRrq+udBCNdaukWHRD-3L=DWgA@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --cc=clement.chigot@atos.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).