From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 2577F3857828 for ; Wed, 6 Jan 2021 21:42:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2577F3857828 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-301-gu4Z9AOJPsOP1XbdVTqg2Q-1; Wed, 06 Jan 2021 16:42:22 -0500 X-MC-Unique: gu4Z9AOJPsOP1XbdVTqg2Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C040F108E1B6; Wed, 6 Jan 2021 21:42:04 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-11.ams2.redhat.com [10.36.112.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FFC45D9CD; Wed, 6 Jan 2021 21:42:03 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 106Lg0Cn1233270 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 6 Jan 2021 22:42:01 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 106Lfx661233225; Wed, 6 Jan 2021 22:41:59 +0100 Date: Wed, 6 Jan 2021 22:41:59 +0100 From: Jakub Jelinek To: David Edelsohn Cc: Jonathan Wakely , Iain Sandoe , libstdc++ , GCC Patches , "CHIGOT, CLEMENT" Subject: Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T Message-ID: <20210106214159.GF725145@tucnak> Reply-To: Jakub Jelinek References: <20210106193746.GD725145@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Wed, 06 Jan 2021 21:42:26 -0000 On Wed, Jan 06, 2021 at 04:20:22PM -0500, David Edelsohn wrote: > 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. Yes, on glibc it is the case, but it doesn't have to be the case on other OSes, which is why there is a configure check. Other OSes can typedef int64_t to whatever they want (or what somebody choose years ago and is now an ABI issue). So, if you wanted to do this, you'd need to check at configure time both multilibs and determine what to do for both. I don't really understand the problem you are trying to solve, because normally the c++config.h header that defines _GLIBCXX_HAVE_INT64_T_LONG etc. comes from a multilib specific header directory, e.g. on powerpc64-linux, one has: /usr/include/c++/11/powerpc64-unknown-linux-gnu/bits/c++config.h and /usr/include/c++/11/powerpc64-unknown-linux-gnu/32/bits/c++config.h (or instead /64/, depending on which multilib is the default) and g++ driver arranges for the search paths to first look at the multilib specific subdirectory and only later at the generic one. Jakub