From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 0C9913857361 for ; Tue, 11 Oct 2022 23:00:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C9913857361 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-wr1-x42c.google.com with SMTP id w18so23750829wro.7 for ; Tue, 11 Oct 2022 16:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=twXgl5Us4CBGdjtFPn6zEjQtVcqw5vl5pgJ2BVYZjAQ=; b=MfMLeEqeE857yKt1fveplQAQJSWSgav/LtfJ63DwzDef1j4WWL26x/XwV+TsjeRwOA Hi9iKSckgtgUMYei0f3nJ2INmLWUzcKc80tn7mE7ze3s1dhDcn+acSo0xK/OsBGBDRd0 7TYD1/6ytn9cQgOEabbp+PdxXFyBLWiH6e0rwLCMm0DtQwM4lEKd9/IwBSsAwj0Yx7Ja xfSKVFSMdnSKGIdbKRAUWxks/2jEBttiJLvY0qwXmRO8G91RApdWWTmkrST1IunhrPhA jTp7XrjT/y9cHekElduhXDX0OanC4IPEhjVNOCrosdZZiTpzfZltCNewPY1Mpz/1l0yg WpMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=twXgl5Us4CBGdjtFPn6zEjQtVcqw5vl5pgJ2BVYZjAQ=; b=4rybzdj7njHSZ8zY/qnjmmjmlcfLx3n8d7Z83ATNDtTbDsHzd3IBprMTrqpOrtu9Qn ikYvOD8TwauGfrGnmfEb3BLRFi9EQMzGBrOqW3HMxhnEwK1SWKMS8Ibvx/2BcjA2C8p7 O09pmdNnNEK9CPLmmMqqOddxY4xRv3jDNxzXOvs5OkuM8vYsz1OlwJbOV49Rjr4L9WN3 mv53ex/7izDq8gjKsjjnWZAU5II5RHB6s/AhaHHbsSjHOH2DSmO8lPqIYN//8a6Oc0QS dng497aTygeCy5e3H+p+nSTQQBIyJfeJXn5SsYHDte5dkNf/c3C/TitaFyScr8HwJoNz NWVw== X-Gm-Message-State: ACrzQf2CfBati3cXbXS1kCuslu5T3ZNO/xC8bPX7BCO8833xr8vpHg0i XZCDND8JgtS4fgBkoB1dcmLPzxShjVtaxg== X-Google-Smtp-Source: AMsMyM7YvTXjxomsID3SbQywoGbhFfUaLv0E6WieiXZNr+RDbVQ4SNGc0RiBblU0J7HXp/jOOXYA1g== X-Received: by 2002:a5d:5d89:0:b0:226:e5ca:4bc2 with SMTP id ci9-20020a5d5d89000000b00226e5ca4bc2mr16441288wrb.310.1665529234589; Tue, 11 Oct 2022 16:00:34 -0700 (PDT) Received: from fomalhaut.localnet ([2a01:e0a:8d5:d990:e654:e8ff:fe8f:2ce6]) by smtp.gmail.com with ESMTPSA id k28-20020a05600c1c9c00b003c6cdbface4sm250740wms.11.2022.10.11.16.00.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Oct 2022 16:00:33 -0700 (PDT) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix emit_group_store regression on big-endian Date: Wed, 12 Oct 2022 00:57:58 +0200 Message-ID: <1908900.PYKUYFuaPT@fomalhaut> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart21633508.EfDdHjke4D" Content-Transfer-Encoding: 7Bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: This is a multi-part message in MIME format. --nextPart21633508.EfDdHjke4D Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, the recent optimization implemented for complex modes in: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595865.html contains an oversight for big-endian platforms in the "interesting corner case" mentioned in the message: it uses a lowpart SUBREG when the integer modes have different sizes, but this does not match the semantics of the PARALLELs which have a bundled byte offset; this offset is always zero in the code path and the lowpart is not at offset zero on big-endian platforms. Calling validate_subreg with this zero offset would fix the regression by disabling the optimization on big-endian platforms, so instead the attached fix adds the appropriate right shift for them. This fixes the following regressions in the C testsuite on SPARC64/Linux: FAIL: gcc.c-torture/execute/20041124-1.c -O0 execution test FAIL: gcc.c-torture/execute/20041124-1.c -O1 execution test FAIL: gcc.c-torture/execute/20041124-1.c -O2 execution test FAIL: gcc.c-torture/execute/20041124-1.c -O2 -flto -fno-use-linker-plugin - flto-partition=none execution test FAIL: gcc.c-torture/execute/20041124-1.c -O2 -flto -fuse-linker-plugin -fno- fat-lto-objects execution test FAIL: gcc.c-torture/execute/20041124-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/20041124-1.c -Os execution test FAIL: gcc.dg/compat/struct-by-value-11 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: gcc.dg/compat/struct-by-value-12 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute Tested on SPARC64/Linux, OK for the mainline? 2022-10-11 Eric Botcazou * expr.cc (emit_group_stote): Fix handling of modes of different sizes for big-endian targets in latest change and add commentary. -- Eric Botcazou --nextPart21633508.EfDdHjke4D Content-Disposition: attachment; filename="p.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="p.diff" diff --git a/gcc/expr.cc b/gcc/expr.cc index ba627f176a7..b897b6dc385 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -2813,50 +2813,69 @@ emit_group_store (rtx orig_dst, rtx src, tree type ATTRIBUTE_UNUSED, else adj_bytelen = bytelen; + /* Deal with destination CONCATs by either storing into one of the parts + or doing a copy after storing into a register or stack temporary. */ if (GET_CODE (dst) == CONCAT) { if (known_le (bytepos + adj_bytelen, GET_MODE_SIZE (GET_MODE (XEXP (dst, 0))))) dest = XEXP (dst, 0); + else if (known_ge (bytepos, GET_MODE_SIZE (GET_MODE (XEXP (dst, 0))))) { bytepos -= GET_MODE_SIZE (GET_MODE (XEXP (dst, 0))); dest = XEXP (dst, 1); } + else { machine_mode dest_mode = GET_MODE (dest); machine_mode tmp_mode = GET_MODE (tmps[i]); - scalar_int_mode imode; + scalar_int_mode dest_imode; gcc_assert (known_eq (bytepos, 0) && XVECLEN (src, 0)); - if (finish == 1 + /* If the source is a single scalar integer register, and the + destination has a complex mode for which a same-sized integer + mode exists, then we can take the left-justified part of the + source in the complex mode. */ + if (finish == start + 1 && REG_P (tmps[i]) - && COMPLEX_MODE_P (dest_mode) && SCALAR_INT_MODE_P (tmp_mode) - && int_mode_for_mode (dest_mode).exists (&imode)) + && COMPLEX_MODE_P (dest_mode) + && int_mode_for_mode (dest_mode).exists (&dest_imode)) { - if (tmp_mode != imode) + const scalar_int_mode tmp_imode + = as_a (tmp_mode); + + if (GET_MODE_BITSIZE (dest_imode) + < GET_MODE_BITSIZE (tmp_imode)) { - rtx tmp = gen_reg_rtx (imode); - emit_move_insn (tmp, gen_lowpart (imode, tmps[i])); - dst = gen_lowpart (dest_mode, tmp); + dest = gen_reg_rtx (dest_imode); + if (BYTES_BIG_ENDIAN) + tmps[i] = expand_shift (RSHIFT_EXPR, tmp_mode, tmps[i], + GET_MODE_BITSIZE (tmp_imode) + - GET_MODE_BITSIZE (dest_imode), + NULL_RTX, 1); + emit_move_insn (dest, gen_lowpart (dest_imode, tmps[i])); + dst = gen_lowpart (dest_mode, dest); } else dst = gen_lowpart (dest_mode, tmps[i]); } + + /* Otherwise spill the source onto the stack using the more + aligned of the two modes. */ else if (GET_MODE_ALIGNMENT (dest_mode) - >= GET_MODE_ALIGNMENT (tmp_mode)) + >= GET_MODE_ALIGNMENT (tmp_mode)) { dest = assign_stack_temp (dest_mode, GET_MODE_SIZE (dest_mode)); - emit_move_insn (adjust_address (dest, - tmp_mode, - bytepos), + emit_move_insn (adjust_address (dest, tmp_mode, bytepos), tmps[i]); dst = dest; } + else { dest = assign_stack_temp (tmp_mode, @@ -2864,6 +2883,7 @@ emit_group_store (rtx orig_dst, rtx src, tree type ATTRIBUTE_UNUSED, emit_move_insn (dest, tmps[i]); dst = adjust_address (dest, dest_mode, bytepos); } + break; } } --nextPart21633508.EfDdHjke4D--