From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04D3CC352AA for ; Wed, 2 Oct 2019 09:12:21 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C80ED21783 for ; Wed, 2 Oct 2019 09:12:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C80ED21783 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFagE-0007Ms-Pb for qemu-devel@archiver.kernel.org; Wed, 02 Oct 2019 05:12:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43531) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFaep-0006Mc-Id for qemu-devel@nongnu.org; Wed, 02 Oct 2019 05:10:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFaeo-0000qB-2h for qemu-devel@nongnu.org; Wed, 02 Oct 2019 05:10:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48742) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iFaek-0000ks-04; Wed, 02 Oct 2019 05:10:46 -0400 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 mx1.redhat.com (Postfix) with ESMTPS id E8A388F4E1; Wed, 2 Oct 2019 09:10:41 +0000 (UTC) Received: from redhat.com (unknown [10.42.17.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD3175D9D3; Wed, 2 Oct 2019 09:10:39 +0000 (UTC) Date: Wed, 2 Oct 2019 10:10:37 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Richard Henderson Subject: Re: [RFC PATCH] configure: deprecate 32 bit build hosts Message-ID: <20191002091037.GB607@redhat.com> References: <20190925233013.6449-1-alex.bennee@linaro.org> <4512b61a-ed82-e628-88e5-f44ef87c2b50@linaro.org> <20190930092519.GB11996@redhat.com> <87impakrky.fsf@linaro.org> <58da7aa4-877b-2c85-71f5-e703a841e6d4@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <58da7aa4-877b-2c85-71f5-e703a841e6d4@linaro.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 02 Oct 2019 09:10:42 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Peter Maydell , "open list:RISC-V" , Mark Cave-Ayland , QEMU Developers , "qemu-discuss@nongnu.org" , qemu-s390x , "qemu-arm@nongnu.org" , qemu-ppc , Alex =?utf-8?Q?Benn=C3=A9e?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Oct 01, 2019 at 11:02:14AM -0700, Richard Henderson wrote: > On 10/1/19 10:56 AM, Mark Cave-Ayland wrote: > > Just out of interest, which host/compiler combinations don't currently implement > > int128_t? > > GCC only implements int128_t for 64-bit targets. QEMU probes for that during configure and sets CONFIG_INT128 If I'm reading correctly include/qemu/int128.h then provides a fallback type based on a struct with two int64s. This has some inconvenience though as you have to use the the (inline) function calls for all the basic operands and will be less efficient when using the fallback. Presumably this is not viable for TCG ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|