From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by sourceware.org (Postfix) with ESMTP id A5748385E027 for ; Mon, 23 Mar 2020 10:35:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A5748385E027 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-69-DKWw5Q4zOWS1ygGu4AmRfQ-1; Mon, 23 Mar 2020 06:35:09 -0400 X-MC-Unique: DKWw5Q4zOWS1ygGu4AmRfQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 90AF5149C3; Mon, 23 Mar 2020 10:35:08 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-22.ams2.redhat.com [10.36.112.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2B3441001F43; Mon, 23 Mar 2020 10:35:08 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 02NAZ67M022564; Mon, 23 Mar 2020 11:35:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 02NAZ5lO022563; Mon, 23 Mar 2020 11:35:05 +0100 Date: Mon, 23 Mar 2020 11:35:05 +0100 From: Jakub Jelinek To: Martin =?utf-8?B?TGnFoWth?= Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Check endianess detection. Message-ID: <20200323103505.GF2156@tucnak> Reply-To: Jakub Jelinek References: <82f5cda2-97f4-039e-5094-c528b220eb78@suse.cz> <20200323094308.GD2156@tucnak> <20200323101025.GE2156@tucnak> <7a5da5ef-1f97-c273-ca22-7621c419f1c3@suse.cz> MIME-Version: 1.0 In-Reply-To: <7a5da5ef-1f97-c273-ca22-7621c419f1c3@suse.cz> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 23 Mar 2020 10:35:12 -0000 On Mon, Mar 23, 2020 at 11:28:00AM +0100, Martin Li=C5=A1ka wrote: > > > > You can use them but should be prepared for some fallback (e.g. end= ian.h, > > > > whatever else). > > > > And there is also PDP endian... > > >=20 > > > Huh, are we talking about something so complex like: > > > https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/i= nt_endianness.h > >=20 > > I'd say even that is very simplified. E.g. on glibc there is > > with its macros, etc. > >=20 > > > Btw. do we force our run-time libraries to be built with GCC? > >=20 > > Some of our run-time libraries rely on being built by GCC, sure. > > But I thought include/ is shared with binutils and there we don't reall= y say > > which compiler must be used to compile it. >=20 > ... and can we then rely on configure detection of the endianess done by = bfd and gold: >=20 > gold/config.h:#define GOLD_DEFAULT_BIG_ENDIAN false >=20 > bfd/PORTING: > TARGET_IS_BIG_ENDIAN_P > =09Should be defined if is big-endian. I don't think so. That is about the target, but you care about the host. Wouldn't it be much easier not to do this and simply use macros for bits from the full 32-bit value (and use shifts)? =09Jakub