Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T

[Jonathan Wakely <jwakely@redhat.com>]

On 29/04/21 16:06 -0400, David Edelsohn wrote:
>On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely <jwakely@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.