From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DjnCEtI8TWOhtQ0AWB0awg (envelope-from ) for ; Mon, 17 Oct 2022 07:30:26 -0400 Received: by simark.ca (Postfix, from userid 112) id 3AFEA1E112; Mon, 17 Oct 2022 07:30:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 933331E0D5 for ; Mon, 17 Oct 2022 07:30:25 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0122B3858293 for ; Mon, 17 Oct 2022 11:30:25 +0000 (GMT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by sourceware.org (Postfix) with ESMTPS id 9A4F73858281 for ; Mon, 17 Oct 2022 11:29:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A4F73858281 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f45.google.com with SMTP id az22-20020a05600c601600b003c6b72797fdso9752728wmb.5 for ; Mon, 17 Oct 2022 04:29:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cMFfeZn76+X6CIL6JcEZLKGdS2EcbIIj4ziNVoCGSxs=; b=vqXyzUsGujBmNGIhG2NgLKgsAPmcKiKE4phQRz5KSyfUr44WaxirttC5p3ziPA/nl+ F96pDzShk9/ZHO6+CHfd4qJcAmYbZlERw0rqEynwhzIku71lYbdzONjqlz5o+bskY6uo ugEj7PFt75htMYM9IyeWxO31nUm7F+IFkiFQdzeDcmPVyg6H9Fc0GuUzydH9CgaNGkl3 t4RdvEKPP0OB4bwWg0FI/4CeFMSc/PQrUyG0Z0H5Ns3Qam9adUHnRyDMU1zPGwjN1XDx R2C4dwS7QOMlsdTRdmy0gC7nTAwT7kHX3vhHNB070eENv2OwwvzLJ7jJ4g1lsYna1Cl+ KH5Q== X-Gm-Message-State: ACrzQf2WhlmS6tW202Oa5YijHTsTGkLj5J00pZ9OEmdDoMMXTd6jH+Yc wIbUy+YwiatrnrlQzvjmyNocVpaJwuNKsA== X-Google-Smtp-Source: AMsMyM6IB3LqaVnBlLSZIEwBPP5ni283QuJDtFn7z66TVTNBzfM2RW8xdj7VDFfn+XnJ3rQaDX6ORg== X-Received: by 2002:a05:600c:4f8d:b0:3b4:9f2f:4311 with SMTP id n13-20020a05600c4f8d00b003b49f2f4311mr6831721wmq.17.1666006193285; Mon, 17 Oct 2022 04:29:53 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id g24-20020a7bc4d8000000b003b4935f04a4sm12011049wmk.5.2022.10.17.04.29.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Oct 2022 04:29:52 -0700 (PDT) Subject: Re: gmp's c++ interface / mpz_class To: Luis Machado , gdb@sourceware.org References: <1bf89db8-a04c-4297-3a5f-ae8532f6d0a4@arm.com> From: Pedro Alves Message-ID: <11c78d03-0823-32c6-1d66-6f814bef7057@palves.net> Date: Mon, 17 Oct 2022 12:29:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <1bf89db8-a04c-4297-3a5f-ae8532f6d0a4@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Zaric, Zoran \(Zare\)" Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-10-17 11:44 a.m., Luis Machado wrote: > On 10/14/22 19:11, Pedro Alves wrote: >> Hi! >> >> Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to >> store bit offsets that can span a whole 64-bits address space.  Instead of rolling our own, >> I guess it makes sense to use libgmp, since, well, we already depend on it.  I see that we have: > > Is uint128_t an option (at least temporarily)? That is not portable, unfortunately. It doesn't exist in all compilers, and/or all architectures. So it's useful to prototype things, but it's not something we can use, because we need this in core code (DWARF expression evaluation). We may end up with something like a typedef that maps to int128_t when available, and to a C++ class emulation when not available, though.