From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 929BB3858D20 for ; Wed, 12 Jul 2023 07:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 929BB3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b703d7ed3aso108905331fa.1 for ; Wed, 12 Jul 2023 00:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689147908; x=1691739908; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BbomtTMINZLe/ZxDKi6nEIeGw8jdFw5uUFU64tKPU30=; b=Wf1/4oi2VDGZdmSWt5YxXnVsG3GPxajNbkSB2WPozge2ZW030ZW5EpCpU99l+o/59v 65jwkGuacIdA60kgydERfmvgF2U1FCAAtbrMA43a+lrNlTIUjUSBwAKLN/4FDabavLB+ Y+cCpRvPO4Sdu5bFYeQOX6FfBu++QkFH/3nRfs9kx+ewA/CCHMxMUihkkzfgMFS1Al32 Btpno0yFMruohjZw26VQW1XtBccScbyd88OZVtReeHSo/yPX8XiwqbfjLYTGwc8IZ0ix nxQrs7y578PDmhGz+pRORdGc8LOM8KSdDT7liuGsFoz3fqY9uTyCFlbk4Q7dW75D/xVr y81A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689147908; x=1691739908; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BbomtTMINZLe/ZxDKi6nEIeGw8jdFw5uUFU64tKPU30=; b=bY5rP1p22wJU82WuTxwQkHOAUZQxxW/v1mRpm7pemTzxOui4S8KjvZ49LYqOtyJQ8E nwT78GiIA5RoRI5Ai9QvfPv5t/OheSItWuLPvlI63btheoChLLb0LXBqMu8kRB5ummhX +sfJ5rMj9Q354179GPO4ly3MGhzKHCpB9AavqEoiNjAEWZnbLpRkE7Ucw2VHllAvMI+g QA2oHBKldodl5OTcszficJHJUWYwnODk3/veDv9o8CiIhas5z4kDrRsmQfeoL1qtrDwS rc7clB6z1/6e4O20dR8DMMVd6pLfTzM0ZjQRFcOHGbPRu4Z8gy+jzG7MUbiowO+ew3ze qxrw== X-Gm-Message-State: ABy/qLbgNOd3Jt6r7h7/z7J9RwVZnObwlw87gBg69C90gyk/YnK//vdX RRoWAXnfCBBxRKjpzOPruEn59Y8VRtraOrYwyuL611Qu2MU= X-Google-Smtp-Source: APBJJlGRMFJbSPOD8l80Ju8wvaFQORIWFoSrmMgvv0C8bRleuzA+1ivpazyFXAkIYiiq5W5oz0c+uS0qiQfUMJr9faA= X-Received: by 2002:a2e:9192:0:b0:2b6:cf31:5e81 with SMTP id f18-20020a2e9192000000b002b6cf315e81mr16347984ljg.20.1689147907994; Wed, 12 Jul 2023 00:45:07 -0700 (PDT) MIME-Version: 1.0 References: <20230712031935.3908564-1-yunqiang.su@cipunited.com> In-Reply-To: <20230712031935.3908564-1-yunqiang.su@cipunited.com> From: Richard Biener Date: Wed, 12 Jul 2023 09:44:45 +0200 Message-ID: Subject: Re: [RFC] Store_bit_field_1: Use mode of SUBREG instead of REG To: YunQiang Su Cc: gcc-patches@gcc.gnu.org, pinskia@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jul 12, 2023 at 5:20=E2=80=AFAM YunQiang Su wrote: > > PR #104914 > > When work with > int val; > ((unsigned char*)&val)[0] =3D *buf; > The RTX mode is obtained from REG instead of SUBREG, > which make D is used instead of . > Thus something wrong happens on sign-extend default architectures, > like MIPS64. > > gcc/ChangeLog: > PR: 104914. > * expmed.cc(store_bit_field_1): Get mode from original > str_rtx instead of op0. > --- > gcc/expmed.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/expmed.cc b/gcc/expmed.cc > index fbd4ce2d42f..37f90912122 100644 > --- a/gcc/expmed.cc > +++ b/gcc/expmed.cc > @@ -849,7 +849,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, = poly_uint64 bitnum, > if we aren't. This must come after the entire register case above, > since that case is valid for any mode. The following cases are onl= y > valid for integral modes. */ > - opt_scalar_int_mode op0_mode =3D int_mode_for_mode (GET_MODE (op0)); > + opt_scalar_int_mode op0_mode =3D int_mode_for_mode (GET_MODE (str_rtx)= ); I don't think this is correct - op0_mode is used to store into op0, and we = are just requiring that it is an integer mode and equal to the original mode. I suppose your patch makes us go to the fallback code instead, but it's surely for the wrong reason. I also wonder why we don't just check GET_MODE_CLASS (GET_MODE (op0)) =3D=3D MODE_CLASS_INT ... > scalar_int_mode imode; > if (!op0_mode.exists (&imode) || imode !=3D GET_MODE (op0)) > { > -- > 2.30.2 >