From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vJfwA271zmrm3wUAWB0awg (envelope-from ) for ; Tue, 13 Oct 2026 23:22:22 -0400 Received: by simark.ca (Postfix, from userid 112) id ECE711E051; Tue, 13 Oct 2026 23:22:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8F9091E047 for ; Tue, 13 Oct 2026 23:22:20 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6FB2B4BA2E25 for ; Wed, 14 Oct 2026 03:22:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FB2B4BA2E25 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 01EFF4BA2E25 for ; Wed, 14 Oct 2026 03:21:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01EFF4BA2E25 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 01EFF4BA2E25 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791948116; cv=none; b=b+O8bz8KI/hssOWNpwM4Ec6og7UU34sKlan0rPiNxy04zulqVX9XYKxYlje46Vg9YM0nIShh0IkTq68JPjmh6yEnH48DHd67ZgBfMQ/xmTmfS4Ie1ktcJFcgFn/yb69JFXOt969BZKXgLEvvS6ME/aR1lvOwwfmBUL1JBXeZTBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791948116; c=relaxed/simple; bh=atC+iX/9kCtSkth2fr0mUivL4q1qWGMUW0t4OGtDIZA=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=sTHKn7XgQbJkuD/iJMcfAyrsAn1+OBR9l3rbGUKLom/UH/nBEEILnC8MghgrB3vROIzl9WkDWL2LaeG9jCDz6P63aCQ5gGjJshXP9qBuOUHKV2nMNUMczOD5WJUpOPzFplTG/afbX0rK8ndeIbUjrWIy942QkIl53SMPY5GEl9k= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01EFF4BA2E25 Received: by angie.orcam.me.uk (Postfix, from userid 500) id A645692009C; Wed, 14 Oct 2026 05:21:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9EF3F92009B; Wed, 14 Oct 2026 04:21:54 +0100 (BST) Date: Wed, 14 Oct 2026 04:21:54 +0100 (BST) From: "Maciej W. Rozycki" To: Kirill Radkin cc: gdb-patches@sourceware.org, Peter Bergner , Sergey Matyukevich , Jerry Zhang Jian , Heinrich Schuchardt , Andrew Burgess , Palmer Dabbelt Subject: Re: [PATCH v2 1/3] RISC-V Vector Extension Support In-Reply-To: <20260925172947.403655-2-hokeygo@gmail.com> Message-ID: References: <20260925172947.403655-1-hokeygo@gmail.com> <20260925172947.403655-2-hokeygo@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Fri, 25 Sep 2026, Kirill Radkin wrote: > diff --git a/gdb/arch/riscv.h b/gdb/arch/riscv.h > index 1443bc20a7d..0261d4d0f9e 100644 > --- a/gdb/arch/riscv.h > +++ b/gdb/arch/riscv.h > @@ -51,7 +51,7 @@ struct riscv_gdbarch_features > target should be 16 and 4 for an embedded subset compliant target (with > 'Zve32*' extension), but GDB doesn't currently mind, and will accept any > vector size. */ > - int vlen = 0; > + int vlenb = 0; What's the rationale behind the member rename? If this is legitimate, then can you please submit a preparatory change that does only the rename without mixing it with new code, which only causes obfuscation? > @@ -68,9 +68,8 @@ struct riscv_gdbarch_features > /* Equality operator. */ > bool operator== (const struct riscv_gdbarch_features &rhs) const > { > - return (xlen == rhs.xlen && flen == rhs.flen > - && embedded == rhs.embedded && vlen == rhs.vlen > - && has_fflags_reg == rhs.has_fflags_reg > + return (xlen == rhs.xlen && flen == rhs.flen && embedded == rhs.embedded > + && vlenb == rhs.vlenb && has_fflags_reg == rhs.has_fflags_reg > && has_frm_reg == rhs.has_frm_reg > && has_fcsr_reg == rhs.has_fcsr_reg); > } > @@ -84,13 +83,10 @@ struct riscv_gdbarch_features > /* Used by std::unordered_map to hash feature sets. */ > std::size_t hash () const noexcept > { > - std::size_t val = ((embedded ? 1 : 0) << 10 > - | (has_fflags_reg ? 1 : 0) << 11 > - | (has_frm_reg ? 1 : 0) << 12 > - | (has_fcsr_reg ? 1 : 0) << 13 > - | (xlen & 0x1f) << 5 > - | (flen & 0x1f) << 0 > - | (vlen & 0x3fff) << 14); > + std::size_t val > + = ((embedded ? 1 : 0) << 10 | (has_fflags_reg ? 1 : 0) << 11 > + | (has_frm_reg ? 1 : 0) << 12 | (has_fcsr_reg ? 1 : 0) << 13 > + | (xlen & 0x1f) << 5 | (flen & 0x1f) << 0 | (vlenb & 0x3fff) << 14); The only functional change here is AFAICT s/vlen/vlenb/ and the rest is reformatting, which obfuscates the update. Would you then please remove the formatting changes and if you indeed think they're needed, then submit them as a follow-up cleanup? I'll yet see if I can look through the rest of your changes, but this just stood out prominently for me. Maciej