From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id fdd7c4cb for ; Wed, 22 Jan 2020 19:55:46 +0000 (UTC) Received: (qmail 28536 invoked by uid 550); 22 Jan 2020 19:55:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28518 invoked from network); 22 Jan 2020 19:55:44 -0000 Resent-From: Rich Felker Resent-Date: Wed, 22 Jan 2020 14:55:32 -0500 Resent-Message-ID: <20200122195532.GE30412@brightrain.aerifal.cx> Resent-To: musl@lists.openwall.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowrisc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NOtqa7K7/IQCZIBbqSmC2oTTgTO3FA8JvuBI8O4e7yk=; b=RqUuz4+A2OO4HdKKe09W3kYnsERY9yJ4DdYSrUIS/QvMiyQaL+whaDQduOk4aZ8sW7 rpprpvMJlVDCPmZVk6Ce5XfoMFBKFRCQ2KLT/AaKzolW0XUwc4t8YZepxIACSsTvxQfj PlFXrOhF25+8OLNpECjesblDt0oGWgvzywTxnnDuIZLNZKYoA5dzNJj77bFR6MATPvfw MJgi20B9c/7CXcRKW27J0M+RHgJPcbnORl70z/Tr2gPJhqjQGjL78OHDU18YA52s7xWa YGmcj3GAfSJ79Nw9bccYC+hpMUtVS9rexwgKuVdsuz2+i6o7eDrotYTCtuimR/kTX3qQ 7sLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NOtqa7K7/IQCZIBbqSmC2oTTgTO3FA8JvuBI8O4e7yk=; b=tIv7vK9XSjTlo8QcFjyIW6W4q2PK3vu8aezoYS7zA5+VvdvORmvg+NkakGkw8J/ztC gs8RAlBMr1OVP357r3cLjEsi6wHA2ZMW55ZGvMe6/XuasdpaTF38tI9QCeiKv8yl3ZE4 ZRSVFwW5XsXKj+qoijIEhNLVXlO/LBQ7/MFdmYD8r5GCwJ2nf0AhmX3oFo35R2Kp0jdN Aty/nKsn3dM0RqjDgqrW1d3vhSWCALWLxWxYSPgQ4rTpz9vgMjjjortPgXH/zJwAbUdZ jfrOKclHTNbMiVUiCeo3e6h0V0UwLs7zgknf9umOY9go8Ry1kZ1rbUGH9YZAq20sY1dn cnOA== X-Gm-Message-State: APjAAAVNgfbVZTIRRj6Z8T0LbbYWOy1minRiPRWaEjfdqlOkejtpkkRm y9pHEcVgXZ7D1R7+sCjRWUunOwz3rsYsCegCCBDqDMIsdFGjsA== X-Google-Smtp-Source: APXvYqy2apQfjvfLAW75IPpTcjAjyJO6dNxiplHwWG+ZpZzvOJBe4iuyjZmpMZT/J8TYa4uvZkX7YyXv0qfi0qT5Rqo= X-Received: by 2002:a1f:4d85:: with SMTP id a127mr6868267vkb.67.1579712248613; Wed, 22 Jan 2020 08:57:28 -0800 (PST) MIME-Version: 1.0 References: <20200115132438.5809-1-luismarques@lowrisc.org> <20200122144620.GA30412@brightrain.aerifal.cx> In-Reply-To: <20200122144620.GA30412@brightrain.aerifal.cx> From: =?UTF-8?Q?Lu=C3=ADs_Marques?= Date: Wed, 22 Jan 2020 16:57:17 +0000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Resent-Sender: Rich Felker Subject: Re: [musl] Re: [PATCH] Fix RISC-V a_cas inline asm operand sign extension On Wed, Jan 22, 2020 at 2:46 PM Rich Felker wrote: > Can you clarify why it's needed and why sign-extending is the right > thing to do, though? Does lr.w sign-extend the loaded value (vs > zero-extend or something else)? LR.W does indeed sign-extend the value read from memory, before storing it in the destination register (the ISA is quite consistent about sign-extending). The branch operates on the whole 64-bits, so the value to compare with must also be sign-extended. That's generally not a problem because the ABI mandates the sign-extension of the 32-bit int to XLEN (64 bits on rv64), and that's something that the compiler normally does automatically. The exception is the inline assembler, which in this case becomes a problem when the function is inlined. > Thanks for pinging this again. It's unfortunate that clang doesn't do > this right to begin with, but the patch is not terribly ugly and > probably okay. Yeah, this is a tricky issue. Unfortunately, it's a bit more complicated than just "clang doesn't do the right thing". A patch was proposed before to try to solve this issue [1], but this is an issue that already existed for other architectures, and where Clang and GCC were already inconsistent, both internally and compared to each other. The difference is that this issue generally only manifested itself with other C types (e.g. short). We (LLVM) could take a principled stance where we guaranteed that the values would be properly sign/zero-extended and truncated back (although my vague recollection is that that would be tricky, if at all possible), but that wouldn't guarantee compatibility with GCC, so you couldn't really rely on that behavior anyway. My understanding is that GCC's sign-extension of the value is an implementation quirk and not something guaranteed to happen, and will in fact not happen in other not too dissimilar cases. And the official stance of the GCC developers is that you can't rely on it, and a lot of other stuff related to inline assembly. Still, this is something that we want to improve in the future, because it's indeed tricky. But the fix might just be to warn of the issue and request that the value be explicitly casted. [1] https://reviews.llvm.org/D69212