public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jonathan Wakely <jwakely@redhat.com>,
	Iain Sandoe <iain@sandoe.co.uk>,
	 "libstdc++" <libstdc++@gcc.gnu.org>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	 "CHIGOT, CLEMENT" <clement.chigot@atos.net>
Subject: Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T
Date: Wed, 6 Jan 2021 16:20:22 -0500	[thread overview]
Message-ID: <CAGWvnymYdx02m25y=UjkE-AOyVgNm3384VgYRseC2wj130xvJA@mail.gmail.com> (raw)
In-Reply-To: <20210106193746.GD725145@tucnak>

On Wed, Jan 6, 2021 at 2:37 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Jan 06, 2021 at 01:38:25PM -0500, David Edelsohn via Gcc-patches wrote:
> > Is this an acceptable solution to determine the value at compile-time?
>
> This looks wrong to me.  The fact that long is 64-bit doesn't imply that
> int64_t as defined by stdint.h must be long, it could be long long too.
> And while e.g. for C it doesn't really matter much whether streamoff
> will be long or long long if those two have the same precision,
> for C++ it matters a lot (affects mangling etc.).

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.

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
>
>         Jakub
>

  reply	other threads:[~2021-01-06 21:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 18:38 David Edelsohn
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 [this message]
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='CAGWvnymYdx02m25y=UjkE-AOyVgNm3384VgYRseC2wj130xvJA@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=jakub@redhat.com \
    --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).