Message ID | patch-16178-tamar@arm.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:ecc5:0:0:0:0:0 with SMTP id s5csp1729287wro; Mon, 29 Aug 2022 23:36:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR61q677LlDcXHjaptmK+DhxnlsBhMTsRpIDIyBbdHSyTiQcKSRtScATMtzif89V7an24dt/ X-Received: by 2002:a05:6402:1290:b0:448:181c:37ec with SMTP id w16-20020a056402129000b00448181c37ecmr11913100edv.191.1661841369579; Mon, 29 Aug 2022 23:36:09 -0700 (PDT) Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id g8-20020a056402320800b004482c139a6esi5672136eda.56.2022.08.29.23.36.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Aug 2022 23:36:09 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=l0HnU1sH; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 37AB239960F0 for <ouuuleilei@gmail.com>; Tue, 30 Aug 2022 06:35:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 37AB239960F0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661841347; bh=jyUj+A9lchTCd7xda5Yx9veNpEp/w5PA7piDVlU4iJU=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=l0HnU1sHPKPRVtGC4q0wXveK4OFW6vmZu+8Gt9fiEpzGuINPaPFXr3P7/O7sfOfyw UIt5Vhs3hBd8UtIRhCq8tu4gMxIvUTU90ua6FjqXev7ByW7CxKf0aTfPY1SiXlYQyz nYbtn6odHAq0THProO8AU3MovnNYVVyRcHHcyDlg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072.outbound.protection.outlook.com [40.107.21.72]) by sourceware.org (Postfix) with ESMTPS id 469FB385E00A for <gcc-patches@gcc.gnu.org>; Tue, 30 Aug 2022 06:34:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 469FB385E00A ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=an1ZCGiN1nauFSmQbNUBqK8GMvarqct4mEt2hKe84rQfDyMf3+Cm2OYq07zt2HUOMdLvEiyT7PHOYwXqjbh7pq87VNJaved5tS1gPBWi6393j164SnclUQ227F2raWZ/7rw+bHioMNwzjp2DvcKVvA94EsRk193XQ9YQhWZjqIRWD3JHYc4N3nEZ7kJx6h4LAsCOihfDv+Wey+SkMZaSS/Sni+gsY+CfQ6HdKbaJtIowXwPf/m5GkPtxbqfh8FcE1wY1Bu44Wp3gW3dQ2NAOJj2s/wTER06w4Jx6FSi4C1IpLnb5C/cKgkfwhS913Wqn2XBMn+qoPR3BJq887hiX7w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jyUj+A9lchTCd7xda5Yx9veNpEp/w5PA7piDVlU4iJU=; b=RShtZFVB7YPuyA1fq/P6qCJzZW+3zMwspzWVktFjl/faNZtsu1b7ZJ3tZoJyKSkr2pAPSPPqROXCuEOKCI3y8s+MEXwW1Ysa9KihWHc9wNenLqLJc8dzZq73ncvH9lxoH3vjshRXKKe+augPiL/w9a4eH6qriZK2X/bIufZtKhJ7HaljQr0YnQEwHnAm2gc/8KbAYr70bFZPIzLymizxyO5nbbnOeJE40k4I1D+bArJZ4fBKRKchk6Abv2gi7krvEd+DBjAngvZYMjAB0/Ln++MsTN2agS7Gk22ODwldRNgbxdHZXltVS/wPuB3TvP0m/VxbT1QwnR5wKkso6HXVZA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AS8PR04CA0069.eurprd04.prod.outlook.com (2603:10a6:20b:313::14) by GV2PR08MB8725.eurprd08.prod.outlook.com (2603:10a6:150:b6::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15; Tue, 30 Aug 2022 06:34:40 +0000 Received: from AM7EUR03FT039.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:313:cafe::43) by AS8PR04CA0069.outlook.office365.com (2603:10a6:20b:313::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.21 via Frontend Transport; Tue, 30 Aug 2022 06:34:40 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT039.mail.protection.outlook.com (100.127.140.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15 via Frontend Transport; Tue, 30 Aug 2022 06:34:38 +0000 Received: ("Tessian outbound fccf984e7173:v123"); Tue, 30 Aug 2022 06:34:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 734da9330bca25ce X-CR-MTA-TID: 64aa7808 Received: from 4ede8af0ddcb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 43933A57-B590-420E-98A4-08E38019C634.1; Tue, 30 Aug 2022 06:34:33 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4ede8af0ddcb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 30 Aug 2022 06:34:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HZ8ToC4hkwq/Eq34XsTVVJII23i7RE7S3PoL1Ssu/L3GojySEkU6PLczi00mQ7Njfzx13/oeRqImt52ngYQURcbpamO9Z7lWOx3ekVprmYp9h4f303DR7X63mBfFB/Of6PuFxI0uhZ7vhGUjc7C+aPFp6dT9wuNHsQEaCjCarBTlnt+c+F54FiLQUTPJBDEJUqUnNfgZKIQ0KN6yr2UGMM1TBK9VYLTnqK2wLXlS7cSGGLT254SJ6+CNfoEfhGEq//0v4AB0VmoZpLsAclrc5eCJdTI+AwdZUeZKcfM1eByRyv3G8yR6rzFFqCYADo2y1A4w8dZPUEsxNw4tSP+wYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jyUj+A9lchTCd7xda5Yx9veNpEp/w5PA7piDVlU4iJU=; b=oDBfeMgKCYDuwid0fijSpaG+ElADi92GBKy771dA6/8xmDU6XuOsjuBHDiXO1GzmhkFBjawXf26BrgnEf9p3bPsZ52CYmSpBcnfYHmO61YmTS+c05ssvPblRd4LTDp/rs2/RDYR0++NVabAngTMAbQkczo1V+8S21C9EVu+3WSuCNPRiYZjMaDudV0Hr1GbiQYflkJIIEfu6DLpNLmKrWyGVnBQ7e0o3eXC21Nd6DFN3Jg+VUMnaKiDtzqLjz2J1FKiJEp7LZutCcU1pFz2gpo6L4ESrV9xqY+hvXHjUXi2uD9o6h1nbWz/5DnfrK3qqG58hlm3nJWjAX60RlqHhcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by VI1PR08MB3312.eurprd08.prod.outlook.com (2603:10a6:803:46::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15; Tue, 30 Aug 2022 06:34:30 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40%4]) with mapi id 15.20.5566.021; Tue, 30 Aug 2022 06:34:29 +0000 Date: Tue, 30 Aug 2022 07:34:22 +0100 To: gcc-patches@gcc.gnu.org Subject: [PATCH][committed]middle-end intialize regnum in store_bit_field_1 Message-ID: <patch-16178-tamar@arm.com> Content-Type: multipart/mixed; boundary="TeUiZkP9xOQsiglY" Content-Disposition: inline X-ClientProxiedBy: SA9PR13CA0053.namprd13.prod.outlook.com (2603:10b6:806:22::28) To VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ff16638c-8bf0-41b7-7389-08da8a51b6cf X-MS-TrafficTypeDiagnostic: VI1PR08MB3312:EE_|AM7EUR03FT039:EE_|GV2PR08MB8725:EE_ x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: +SnYLfQrgInz4g1AQKM+X3jBX9xCLKuAdWHj4WDaIcVMeZaybXCu7bNe8ZlU5ubzg5V/HrCx76zppGqWl/MnJwBtf0mCIbqMI1DG5fWWvIjS8nQEnNZY0wrfqgnr0TCJz81UGShFttwZzPimSaKEDa/pEQTEpH/GU6xE4TYpEsw8Q6kH3TD0KRTcdFIIHuE2zSVlZvR50MGO7E7IISXW2VsXioDJtI4I5iOT6TgpoNPElAzFboTZxy+lD0ZF/OF8nGsCx4eCirs5h9jdyRb4kvvJfeGW3esTS/4/TyhxxBMh2pzbmmUf8FXlujfPrRnRvDAhjTbPPVhisjJU+DHcKuZnRVA0WSqqMS9R0NnBbNYzrkBoP1VXWp4gCeS4+baAsiJ/p1mOBbdeANnUx3ErRpJikzTme8mxs2gfrjxyzfa2dkzanNWhrInuo/cofgV+NEFYlHHes+CzeTEKVWio7ymeUdZcSPktK0HjtG42ravgJc5XVZj8/IYyyZEeqiOPvgjFnOmAQgigf0fd1Td8iyvOmVpt6dn8SULXFfJrX58BomHSR2pxj8NZaIxeLk8LEHbAjnek0EiVLRNjub8+SYhV0bvFJU4Ku9IBcNbQtm5QAHbf9m/wVhKgtVBsJ0SYBLOcT1yXIsOL3qJQMSdCi+UN0mfqBZ/yHa9scpQTWd2a5tXgt7OychPeKjEARuTZp2W8/trY0DKcniFsAmK17HEcBEsW2xb7R1zHdccIlzeaDC0jjomvLlJk5usto3VKJg89BI4RV2B5693aGwOQgiHLbpc/U8BrIoQHFtfayAM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB5325.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(235185007)(6916009)(8676002)(66476007)(86362001)(66556008)(6486002)(4326008)(66946007)(36756003)(5660300002)(41300700001)(316002)(478600001)(8936002)(6666004)(44832011)(2616005)(44144004)(38100700002)(6506007)(33964004)(2906002)(26005)(186003)(6512007)(4216001)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3312 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: b20cc631-3d6d-4a12-a490-08da8a51b11d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4HlbXYQKLTLZql/W0EtgGbEOcWTWnqaf4od2JdbChM7gINt5C0n3JlOxy2kw/u1jSO6CWMLaaaXXi60qod7gfYSg0RUl5xIocg6cgFNKde9U3LIAhFJlWwur7vp3kSfJ750Qk8uwsJkZ7g2LriLUurnhq2Bseg1h6S09osebkFR0sXrWMyUa2GC3IS9YT/ZcTbeVnKUtOilpSN2+j3LPDvKFc5LjivIoyfnyAwynAP7Fh5SyqrDrhGXQ3ydTy7S+9RuLJj4KGUVEqBZ1L4DD75aybYxYmFVZTPeyHLiEATtjjS9vtg3rUahn+7vfobu7zNSCyjMPxwHqJCikDkMeo0V0ZcO/XG7mzwG3DyjZ6gqHslrkkhUhzF3PN+6JOTIzwpRri0BM22SoHtw2xESu88XwxlnbwPXd4wOsf4W/yrvQcpih9WihrU1ivIl6T4ELhrUTaclgFnyVvRAnYsmRkkKLjadXOlyK7h3XqaOTRr90u11DAS6c6fAhupl7qmSn41UBz+KmA8TGTrsIosOpm/oePxayW4+K7IjmOQRUC2E9NwkNr4afjfW7sqznPfhvqukTgD9Ng7gk0s5P34ipeMn22vTB9oMozIbu3veAhQ5Uw68ZUDZ9fzXK4MpjwFRG2PHaWwqji+opxI9MDf6TZH6QsgZB0mPf0Zwuk9Vm8frN+qggO7dJYV5ELadyyFIUTYAbowVzsN2Alc3T0AZGrflSeozD8an1i4Ztsydh/mSceDZkgqMXjc+QBj1pVOYqTp3I4BlvtRUwiiXEld9Y1VosXFjfub3mGJR+8uQkg/wV1AAbrzd2FVS/eL6hwgh8 X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230016)(4636009)(396003)(346002)(39860400002)(376002)(136003)(46966006)(40470700004)(36840700001)(40480700001)(82310400005)(36860700001)(356005)(40460700003)(86362001)(82740400003)(70586007)(70206006)(81166007)(8676002)(4326008)(41300700001)(5660300002)(6486002)(478600001)(235185007)(8936002)(6916009)(316002)(2616005)(47076005)(186003)(44144004)(6506007)(107886003)(2906002)(6512007)(26005)(6666004)(33964004)(44832011)(336012)(36756003)(4216001)(2700100001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2022 06:34:38.9754 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff16638c-8bf0-41b7-7389-08da8a51b6cf X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT039.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB8725 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY 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.29 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> From: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Tamar Christina <tamar.christina@arm.com> Cc: nd@arm.com, rguenther@suse.de Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1742566975932092746?= X-GMAIL-MSGID: =?utf-8?q?1742566975932092746?= |
Series |
[committed] middle-end intialize regnum in store_bit_field_1
|
|
Commit Message
Tamar Christina
Aug. 30, 2022, 6:34 a.m. UTC
Hi All, This initializes regnum to 0 for when undefined_p. 0 is the right default as it's supposed to get the lowpart when undefined. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/ChangeLog: * expmed.cc (store_bit_field_1): Initialize regnum to 0. --- inline copy of patch -- diff --git a/gcc/expmed.cc b/gcc/expmed.cc index 8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb 100644 -- diff --git a/gcc/expmed.cc b/gcc/expmed.cc index 8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb 100644 --- a/gcc/expmed.cc +++ b/gcc/expmed.cc @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, words or to cope with mode punning between equal-sized modes. In the latter case, use subreg on the rhs side, not lhs. */ rtx sub; - HOST_WIDE_INT regnum; + HOST_WIDE_INT regnum = 0; poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); if (known_eq (bitnum, 0U) && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0))))
Comments
On Tue, 30 Aug 2022, Tamar Christina wrote: > Hi All, > > This initializes regnum to 0 for when undefined_p. > 0 is the right default as it's supposed to get the lowpart > when undefined. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? OK. > Thanks, > Tamar > > gcc/ChangeLog: > > * expmed.cc (store_bit_field_1): Initialize regnum to 0. > > --- inline copy of patch -- > diff --git a/gcc/expmed.cc b/gcc/expmed.cc > index 8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb 100644 > --- a/gcc/expmed.cc > +++ b/gcc/expmed.cc > @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, > words or to cope with mode punning between equal-sized modes. > In the latter case, use subreg on the rhs side, not lhs. */ > rtx sub; > - HOST_WIDE_INT regnum; > + HOST_WIDE_INT regnum = 0; > poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); > if (known_eq (bitnum, 0U) > && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0))))
Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Tue, 30 Aug 2022, Tamar Christina wrote: > >> Hi All, >> >> This initializes regnum to 0 for when undefined_p. >> 0 is the right default as it's supposed to get the lowpart >> when undefined. >> >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> >> Ok for master? > > OK. I'm not sure this is the right fix. We were still supposed to use the correct byte offset in the undefined case. Is the attached OK? Tested on aarch64-linux-gnu. Thanks, Richard ---------------------- store_bit_field_1 tries to convert a field assignment into a subreg assignment. Normally it must check that the field occupies a full word (or more specifically, a full REGMODE_NATURAL_SIZE chunk), so that writing to the subreg doesn't clobber any other fields. But it can skip that check if the structure is known to be in an undefined state. The idea was that, in the undefined case, we could rely on simplify_gen_subreg to do the check for a valid subreg, rather than having to repeat the required endianness logic in the caller. Before the addition of the undefined case, the code could use regnum * regsize to get the byte offset, where regnum came from checking that the start was word-aligned. In the undefined case we need to calculate the byte offset explicitly. gcc/ * expmed.cc (store_bit_field_1): Fix byte offset calculation for undefined structures. --- gcc/expmed.cc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/expmed.cc b/gcc/expmed.cc index 8d7418be418..6c02c3bb850 100644 --- a/gcc/expmed.cc +++ b/gcc/expmed.cc @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, words or to cope with mode punning between equal-sized modes. In the latter case, use subreg on the rhs side, not lhs. */ rtx sub; - HOST_WIDE_INT regnum; + poly_uint64 bytenum; poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); if (known_eq (bitnum, 0U) && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0)))) @@ -808,13 +808,13 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, return true; } } - else if (((constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, ®num) - && multiple_p (bitsize, regsize * BITS_PER_UNIT)) - || undefined_p) + else if (multiple_p (bitnum, BITS_PER_UNIT, &bytenum) + && (undefined_p + || (multiple_p (bitnum, regsize * BITS_PER_UNIT) + && multiple_p (bitsize, regsize * BITS_PER_UNIT))) && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize)) { - sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), - regnum * regsize); + sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), bytenum); if (sub) { if (reverse)
On Tue, 30 Aug 2022, Richard Sandiford wrote: > Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > On Tue, 30 Aug 2022, Tamar Christina wrote: > > > >> Hi All, > >> > >> This initializes regnum to 0 for when undefined_p. > >> 0 is the right default as it's supposed to get the lowpart > >> when undefined. > >> > >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > >> > >> Ok for master? > > > > OK. > > I'm not sure this is the right fix. We were still supposed to use the > correct byte offset in the undefined case. > > Is the attached OK? Tested on aarch64-linux-gnu. OK. Thanks, Richard. > Thanks, > Richard > > ---------------------- > > store_bit_field_1 tries to convert a field assignment into a subreg > assignment. Normally it must check that the field occupies a full > word (or more specifically, a full REGMODE_NATURAL_SIZE chunk), > so that writing to the subreg doesn't clobber any other fields. > But it can skip that check if the structure is known to be in > an undefined state. > > The idea was that, in the undefined case, we could rely on > simplify_gen_subreg to do the check for a valid subreg, rather > than having to repeat the required endianness logic in the caller. > > Before the addition of the undefined case, the code could use > regnum * regsize to get the byte offset, where regnum came from > checking that the start was word-aligned. In the undefined case > we need to calculate the byte offset explicitly. > > gcc/ > * expmed.cc (store_bit_field_1): Fix byte offset calculation > for undefined structures. > --- > gcc/expmed.cc | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/gcc/expmed.cc b/gcc/expmed.cc > index 8d7418be418..6c02c3bb850 100644 > --- a/gcc/expmed.cc > +++ b/gcc/expmed.cc > @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, > words or to cope with mode punning between equal-sized modes. > In the latter case, use subreg on the rhs side, not lhs. */ > rtx sub; > - HOST_WIDE_INT regnum; > + poly_uint64 bytenum; > poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); > if (known_eq (bitnum, 0U) > && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0)))) > @@ -808,13 +808,13 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, > return true; > } > } > - else if (((constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, ®num) > - && multiple_p (bitsize, regsize * BITS_PER_UNIT)) > - || undefined_p) > + else if (multiple_p (bitnum, BITS_PER_UNIT, &bytenum) > + && (undefined_p > + || (multiple_p (bitnum, regsize * BITS_PER_UNIT) > + && multiple_p (bitsize, regsize * BITS_PER_UNIT))) > && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize)) > { > - sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), > - regnum * regsize); > + sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), bytenum); > if (sub) > { > if (reverse) >
--- a/gcc/expmed.cc +++ b/gcc/expmed.cc @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, words or to cope with mode punning between equal-sized modes. In the latter case, use subreg on the rhs side, not lhs. */ rtx sub; - HOST_WIDE_INT regnum; + HOST_WIDE_INT regnum = 0; poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); if (known_eq (bitnum, 0U) && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0))))