[v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.
Message ID | 20240129095700.1245-1-jinma@linux.alibaba.com |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp460862dyb; Mon, 29 Jan 2024 01:58:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHWJmO9eVZ6lR0sCjovr/vWEivhvPBzwrw4wOXcz6HXIqoyhvcLDUGGHbECeYX+FuUIjBL8 X-Received: by 2002:a67:f546:0:b0:46b:666:2f26 with SMTP id z6-20020a67f546000000b0046b06662f26mr1485396vsn.57.1706522284079; Mon, 29 Jan 2024 01:58:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706522284; cv=pass; d=google.com; s=arc-20160816; b=R54MC2tVpwtmu02lDNetQyKpoylYbJZsnB2zP61H9tSHLbSC3h4yRx0iySrDMeozSk gcGbVSyjVk26smB4gYfmLld5hlkFqX/sIVu63s2ghYzKqBNA72tuknQiqIUa3rw5R9NJ a9i9WIH2TtZS9NypD+bEhO713UAfVLX0YBEGtXywkYWOuIUS9t3rkPIB61AAsqSAQ0pt 7Ux5+L6pF2y7A11P+8c8Uy32RCvkrMSH2oPiJXc1P3h7GXIP//Y5OYDZtAYDQPbeHNFw O2XCMY13geVV5IawvZoV8EAtlxPHM1egZJnz65zda550/wK9+Fy61hzFJLSC7/HgLzwq CrMg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=fxXqZnVVklxaiQg2KGwOeLgSQOWWauVcuOs7qwvhzho=; fh=NKyge7LX4KSt+KPp8DZphs9pYKHErO4kHCbDx33dH3c=; b=yii77utuAWIC7QpMxYzbznWm+20FIa/bGgQ0vV/lOlaDvJfsUz9IuS8xbZBA1Oy0Xv mMwwvuxOHvBCZug90CH7JtQjt09oyX7LSfw+jbpDqZqu7kIewu0pqlAQLjnt2kSQWihe j9NQE4mvmcx/QB8r5NY4oMUXVIs/7EQ2js135JIlPQdJjJT0sChtdra8wEW1xEuFvrjP D353clbR6mGaKQM7UyQ6BojLspaybPnG5/7PPmffQSQY+qaUbYOUsi8CQNLrBm7Jt1jI LlBY40S/XmDNsOnteK4BJOCQUbXqzcoFWkuJAiNiRYwJRwmb6m8eI+rMGcMrqT4nVjeh vNNA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=E5Nt9whS; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id t13-20020a05620a0b0d00b00783ee6b341esi4251213qkg.45.2024.01.29.01.58.03 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 01:58:04 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=E5Nt9whS; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C0CBF3858402 for <ouuuleilei@gmail.com>; Mon, 29 Jan 2024 09:58:03 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by sourceware.org (Postfix) with ESMTPS id 211A03858D20 for <gcc-patches@gcc.gnu.org>; Mon, 29 Jan 2024 09:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 211A03858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.alibaba.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 211A03858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=115.124.30.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706522243; cv=none; b=FrkfVkYbgYNmqauUlmN6MFaswHgOK7PLq035NW9NRpAtj+oZf94N4+pXANM7787MqVos5ROwg4lxHHYsyJOOd+MRIQyQtc/HYSJs1LQJWWKAoYqmWxx0wrP3/jmdaxhzmhTfyJzoF00UCW/sTKZosxXFbkLqfwTmVx9wllB67RI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706522243; c=relaxed/simple; bh=Hd7HEDN2bGjCEs3BEoMVzzroj9JT0eH7VTWW8HU2gwA=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=Ksav3Xk8LIZOrikjvYOq/n3lAFNjin6NtnPjrjGItO32RZ2byEYW3x86lKM3AGoLsOsSo3aOJGMDa/OKHvu+eRovFDj+U3lv/IAcom3lbnV20wS3iP6LqunWEZV1dEjGhpiwI6mq9RzbNjwU3teoAPxSnD2aWjyFV+WpTA6AxVQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1706522238; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=fxXqZnVVklxaiQg2KGwOeLgSQOWWauVcuOs7qwvhzho=; b=E5Nt9whSG9ysHyixO4c5JVnnZvF6dmLBL8Daw3NqRKMJnhTF7FrkQ0iZ1X+EwTMC7WSmRcpIiz6p9+VPRJP8LqHSUahwEvpN3dWDpGLitGfok8ADXsovole74HvYhgEAEuPLUzF5dBZZj1S8Dbz/Z1r2TTGB4NQzfKJ3rv1noJ0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018046059; MF=jinma@linux.alibaba.com; NM=1; PH=DS; RN=10; SR=0; TI=SMTPD_---0W.Zivew_1706522235; Received: from localhost.localdomain(mailfrom:jinma@linux.alibaba.com fp:SMTPD_---0W.Zivew_1706522235) by smtp.aliyun-inc.com; Mon, 29 Jan 2024 17:57:17 +0800 From: Jin Ma <jinma@linux.alibaba.com> To: gcc-patches@gcc.gnu.org Cc: jeffreyalaw@gmail.com, palmer@dabbelt.com, richard.sandiford@arm.com, kito.cheng@gmail.com, christoph.muellner@vrull.eu, rdapp.gcc@gmail.com, juzhe.zhong@rivai.ai, jinma.contrib@gmail.com, Jin Ma <jinma@linux.alibaba.com> Subject: [PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems. Date: Mon, 29 Jan 2024 17:57:00 +0800 Message-Id: <20240129095700.1245-1-jinma@linux.alibaba.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20240129092016.1176-1-jinma@linux.alibaba.com> References: <20240129092016.1176-1-jinma@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-29.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, ENV_AND_HDR_SPF_MATCH, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789415994944222065 X-GMAIL-MSGID: 1789418310585455878 |
Series |
[v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Jin Ma
Jan. 29, 2024, 9:57 a.m. UTC
When using '%ld' to print 'long long int' variable, 'fprintf' will produce messy output on a 32-bit system, in an incorrect instruction being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the following error occurred during compilation: Assembler messages: Error: improper immediate value (18446744073709551615) gcc/ChangeLog: * config/riscv/thead.cc (th_print_operand_address): Change %ld to %lld. --- gcc/config/riscv/thead.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
LGTM Jin Ma <jinma@linux.alibaba.com> 於 2024年1月29日 週一 17:57 寫道: > When using '%ld' to print 'long long int' variable, 'fprintf' will > produce messy output on a 32-bit system, in an incorrect instruction > being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the > following error occurred during compilation: > > Assembler messages: > Error: improper immediate value (18446744073709551615) > > gcc/ChangeLog: > > * config/riscv/thead.cc (th_print_operand_address): Change %ld > to %lld. > --- > gcc/config/riscv/thead.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc > index 2955bc5f8a9..e4b8c37bc28 100644 > --- a/gcc/config/riscv/thead.cc > +++ b/gcc/config/riscv/thead.cc > @@ -1141,7 +1141,7 @@ th_print_operand_address (FILE *file, machine_mode > mode, rtx x) > return true; > > case ADDRESS_REG_WB: > - fprintf (file, "(%s),%ld,%u", reg_names[REGNO (addr.reg)], > + fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO > (addr.reg)], > INTVAL (addr.offset) >> addr.shift, addr.shift); > return true; > > -- > 2.17.1 > >
On Mon, Jan 29, 2024 at 1:32 PM Kito Cheng <kito.cheng@gmail.com> wrote: > > LGTM I've rebased, retested (rv64+rv32) and merged this patch. Thanks! > > Jin Ma <jinma@linux.alibaba.com> 於 2024年1月29日 週一 17:57 寫道: >> >> When using '%ld' to print 'long long int' variable, 'fprintf' will >> produce messy output on a 32-bit system, in an incorrect instruction >> being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the >> following error occurred during compilation: >> >> Assembler messages: >> Error: improper immediate value (18446744073709551615) >> >> gcc/ChangeLog: >> >> * config/riscv/thead.cc (th_print_operand_address): Change %ld >> to %lld. >> --- >> gcc/config/riscv/thead.cc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc >> index 2955bc5f8a9..e4b8c37bc28 100644 >> --- a/gcc/config/riscv/thead.cc >> +++ b/gcc/config/riscv/thead.cc >> @@ -1141,7 +1141,7 @@ th_print_operand_address (FILE *file, machine_mode mode, rtx x) >> return true; >> >> case ADDRESS_REG_WB: >> - fprintf (file, "(%s),%ld,%u", reg_names[REGNO (addr.reg)], >> + fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)], >> INTVAL (addr.offset) >> addr.shift, addr.shift); >> return true; >> >> -- >> 2.17.1 >>
On Jan 30 2024, Christoph Müllner wrote:
> retested
Nope.
../../gcc/config/riscv/thead.cc:1144:22: error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
1144 | fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)],
| ^
cc1plus: all warnings being treated as errors
make[3]: *** [../../gcc/config/riscv/t-riscv:127: thead.o] Error 1
On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Jan 30 2024, Christoph Müllner wrote: > > > retested > > Nope. Sorry for this. I tested for no regressions in the test suite with a cross-build and QEMU and did not do a Werror bootstrap build. I'll provide a fix for this later today (also breaking the line as it is longer than needed). > > ../../gcc/config/riscv/thead.cc:1144:22: error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix] > 1144 | fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)], > | ^ > cc1plus: all warnings being treated as errors > make[3]: *** [../../gcc/config/riscv/t-riscv:127: thead.o] Error 1 > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On 2/5/24 05:00, Christoph Müllner wrote: > On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> > wrote: >> >> On Jan 30 2024, Christoph Müllner wrote: >> >>> retested >> >> Nope. > > Sorry for this. I tested for no regressions in the test suite with a > cross-build and QEMU and did not do a Werror bootstrap build. I'll > provide a fix for this later today (also breaking the line as it is > longer than needed). Right. And that's pretty standard given the state of the RISC-V platforms. We've got a platform here that can bootstrap in a reasonable amount of time, but I haven't set that up in the CI system yet. Until such systems are common, these niggling issues are bound to show up. It's just whitespace around the HOST_WIDE_INT_PRINT_DEC and wrapping the long line, right? I've got that in my tree that's bootstrapping now. I don't mind committing it later today. But if you get to it before my bootstrap is done, feel free to commit as pre-approved. jeff
On Feb 05 2024, Jeff Law wrote:
> Until such systems are common, these niggling issues are bound to show up.
It won't if you do it properly: build with a cross compiler that was
built from the same source and enable -Werror.
On 2/5/24 08:08, Andreas Schwab wrote: > On Feb 05 2024, Jeff Law wrote: > >> Until such systems are common, these niggling issues are bound to show up. > > It won't if you do it properly: build with a cross compiler that was > built from the same source and enable -Werror. We're all aware you *can* do that. But it's never been a requirement to commit a patch. jeff
On Feb 05 2024, Jeff Law wrote: > We're all aware you *can* do that. But it's never been a requirement to > commit a patch. It has always been a requirement that a patch does not break bootstrap.
On Mon, Feb 5, 2024 at 3:56 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 2/5/24 05:00, Christoph Müllner wrote: > > On Sat, Feb 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> > > wrote: > >> > >> On Jan 30 2024, Christoph Müllner wrote: > >> > >>> retested > >> > >> Nope. > > > > Sorry for this. I tested for no regressions in the test suite with a > > cross-build and QEMU and did not do a Werror bootstrap build. I'll > > provide a fix for this later today (also breaking the line as it is > > longer than needed). > Right. And that's pretty standard given the state of the RISC-V > platforms. We've got a platform here that can bootstrap in a reasonable > amount of time, but I haven't set that up in the CI system yet. > > Until such systems are common, these niggling issues are bound to show up. > > It's just whitespace around the HOST_WIDE_INT_PRINT_DEC and wrapping the > long line, right? I've got that in my tree that's bootstrapping now. I > don't mind committing it later today. But if you get to it before my > bootstrap is done, feel free to commit as pre-approved. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=184978cd74f962712e813030d58edc109ad9a92d > > jeff
diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc index 2955bc5f8a9..e4b8c37bc28 100644 --- a/gcc/config/riscv/thead.cc +++ b/gcc/config/riscv/thead.cc @@ -1141,7 +1141,7 @@ th_print_operand_address (FILE *file, machine_mode mode, rtx x) return true; case ADDRESS_REG_WB: - fprintf (file, "(%s),%ld,%u", reg_names[REGNO (addr.reg)], + fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)], INTVAL (addr.offset) >> addr.shift, addr.shift); return true;