From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id A2CB03AAA0C2; Thu, 29 Apr 2021 20:06:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2CB03AAA0C2 Received: by mail-lf1-x130.google.com with SMTP id b23so24151975lfv.8; Thu, 29 Apr 2021 13:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nDOSUJLNWtTsHG+ROsDa8pSwojutF6h/HrIrjZd/xX4=; b=o57B0J1/c2o0Op7lT/wiGtWxc+7XKuhzsi5UaJ8G0DUFNjV+ZldFMGl5XkmT8XhKny BkHZTQYELGizso8MZAq+MzNvuHsA08AY53LsZAzfl25v4/IBcnEhFbwfNBwn/nSG59u3 kKUDOVXV+Z0BoEbfBQIoUv4l063kUstIvu2eYCI0PTV/WXsEDRTP7cGNxLD2FO6GDkyV 8Kuf9I1PNd6M/UNWSnukkFPaFoqvm4mUBIRUwDfpBtzzcLzvSvfyOh0kdE6D4a+9slqR dWQ/kl2T+zPBCaqdYEvzmc/gJAl2WnvH/xdnsUc/emoPr6SmbYfxZoKZ3ZssxrRJG5tZ LkgA== X-Gm-Message-State: AOAM530ff7U6NZzw5jTeHf40pe2S9C35LqhJtFVkWDPdNON9IC3+eRdj gVXg41bC++blzqDot28hN2q3SyF8HqhcY1uJZXw= X-Google-Smtp-Source: ABdhPJwWz2C8OPTtLvyHdQgmuI+CtPOdspaeR8o/C27mk9p7YqNDVPPrwoKMi7mtrJcAA3WiGrZkyWAEC2v3GO9iEgg= X-Received: by 2002:a05:6512:10cb:: with SMTP id k11mr883133lfg.84.1619726789270; Thu, 29 Apr 2021 13:06:29 -0700 (PDT) MIME-Version: 1.0 References: <20210106193746.GD725145@tucnak> <20210106214159.GF725145@tucnak> <20210106233937.GH725145@tucnak> <20210106234549.GA3748@tucnak> <20210108183703.GF9471@redhat.com> In-Reply-To: <20210108183703.GF9471@redhat.com> From: David Edelsohn Date: Thu, 29 Apr 2021 16:06:17 -0400 Message-ID: Subject: Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T To: Jonathan Wakely Cc: Jakub Jelinek , Iain Sandoe , "libstdc++" , GCC Patches , "CHIGOT, CLEMENT" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 20:06:32 -0000 On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely 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 , 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__ . Thanks, David