On 29/04/21 16:06 -0400, David Edelsohn wrote:
On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely <jwak...@redhat.com> wrote:
On 06/01/21 19:41 -0500, David Edelsohn wrote:
>Thanks for clarifying the issue.
>
>As you implicitly point out, GCC knows the type of INT64 and defines
>the macro __INT64_TYPE__ . The revised code can use that directly,
>such as:
>
>#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
> || defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
> typedef __INT64_TYPE__ streamoff;
> #elif defined(_GLIBCXX_HAVE_INT64_T)
> typedef int64_t streamoff;
> #else
> typedef long long streamoff;
> #endif
>
>Are there any additional issues not addressed by that approach, other
>than possible further simplification?
That avoids the ABI break that Jakub pointed out. But I think we can
simplify it further, as in the attached patch.
This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
think that should be equivalent in all practical cases (I can imagine
some strange target where __INT64_TYPE__ is defined by the compiler,
but int64_t isn't defined when the configure checks look for it, and
so the current code would use long long and with my patch would use
__INT64_TYPE__ which could be long ... but I think in practice that's
unlikely. It was probably more likely in older releases where the
configure test would have been done with -std=gnu++98 and so int64_t
might not have been declared by libc's <stdint.h>, but if that was the
case then any ABI break it caused happened years ago.
Hi, Jonathan
Polite ping.
Now that GCC 11.1 has been released, can this patch be applied to
libstdc++? As I replied at the time to Jakub's concerns, both Clang
(since 3.0.0) and ICC (since at least 16.0.0) have defined
__INT64_TYPE__ .
Yes, I'll push that tomorrow.
