From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id B31F53858C50 for ; Tue, 27 Sep 2022 13:49:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B31F53858C50 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-ed1-x536.google.com with SMTP id y8so13279559edc.10 for ; Tue, 27 Sep 2022 06:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=fhZRPWcGE5PmYGPd6Mo2FPdSphKBU21nYnvv0z0YHFE=; b=gmnQMkhLjQdLkxK8skGkPVq7zQa+YrYEjoqrY1NH41KUdkZf7vVRjBKfnrIy36osY/ rpyjpViMhG2HE/6/TyZEq5NlOp6FzDRxwFsSlxJUTizpRIF8ytoUuN6fGbnP+J8LwJ2S SjQVhIk5bw+o1xixltJBWLq8cCB2ttuKS72OFW56vRTD8otJYJnMzr7REBUNq2/tXKFE bL+UeogBF2jiK6IKdK6igQDGuv7/G8Fvq6FRU0nweg/ypDXf66V81pV/DjbVoItAyOV0 xs7mGLoieQJ6+rH9R31r/4rDepFLuTacbHoC8wFNv0d7qmn+p4dJhqa3X1JSHpBMJj99 FMDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=fhZRPWcGE5PmYGPd6Mo2FPdSphKBU21nYnvv0z0YHFE=; b=FCXl1W/6duSFfG8KKFNBI/jlokfXvEGX1DIixf65L627WZzISkrPAit5/bOHQ/GcDL J2N7yy9qVIXr+3pnWfSK1obvQhJ0eICXJDki6umuhiWJImNQ9BEUSiUCBR5v3mlF8wqn z+vjgOYBY3QkH+AaxFun5Cb4AEzZQhCKsno9wqt2rf+TqpbSChPIoXiiektL9wq0Vowq QdohMJqdVCH/wurZQhsqxC+wdzClEAYbXgGLf4BeOyI3TDiotlPvD5wX/U7iVyfcWkRy kJYZaO0KyQttOb6OKuF8APl+FtuqyBRbrJHwEn6CxjADNNhCB+hzmEhzTLYAZkSVW6aA z4hw== X-Gm-Message-State: ACrzQf05CRTaBMb8AX56SheEVoV+GD8hC6rCzLtJu2PKkYrGWJbITVes yipayEKJ0Cw+EcL+ZMga71ulZkG3Eza08zTStvI= X-Google-Smtp-Source: AMsMyM6+qJoX3gsXuZGcYplIWoU7S8VClaLtFZcqb2ZYDyjGFYaVyYiBE7NJLlCyP3HInKYuY5BsxIT1BaAhpPWeCp8= X-Received: by 2002:a05:6402:1053:b0:455:27b7:f1 with SMTP id e19-20020a056402105300b0045527b700f1mr26014457edu.370.1664286554356; Tue, 27 Sep 2022 06:49:14 -0700 (PDT) MIME-Version: 1.0 References: <0a9b9375-6587-5a7d-2ec9-18e7501fe179@linux.ibm.com> In-Reply-To: From: Richard Biener Date: Tue, 27 Sep 2022 15:49:02 +0200 Message-ID: Subject: Re: VN, len_store and endianness To: Robin Dapp Cc: GCC Patches , jakub@redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Tue, Sep 27, 2022 at 3:19 PM Robin Dapp wrote: > > > The error is probably in vn_reference_lookup_3 which assumes that > > 'len' applies to the vector elements in element order. See the part > > of the code where it checks for internal_store_fn_p. If 'len' is with > > respect to the memory and thus endianess has to be taken into > > account then for the IFN_LEN_STORE > > > > else if (fn == IFN_LEN_STORE) > > { > > pd.rhs_off = 0; > > pd.offset = offset2i; > > pd.size = (tree_to_uhwi (len) > > + -tree_to_shwi (bias)) * BITS_PER_UNIT; > > if (ranges_known_overlap_p (offset, maxsize, > > pd.offset, pd.size)) > > return data->push_partial_def (pd, set, set, > > offseti, maxsizei); > > > > likely needs to adjust rhs_off from zero for big endian? > > Not sure I follow entirely. rhs_off only seems to be used for > native_encode_expr which properly encodes already ({-1, 1, -1, 1} in > that order in memory). A 'len' of 12 is the first three elements (in > the same order or element order as well). Yes, because the native_interpret always starts at offset zero (we can't easily feed in a "shifted" RHS). So what I assumed is that IFN_LEN_STORE always stores elements [0, len + adj]. > If the constant were encoded in little endian ({1, -1, 1, -1}) 'q' would > kind of address the right elements (using always the second, or > "reversed third" element while shifting the buffer by 4 bytes each time).