From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 84A84A0C43
for <public@inbox.dpdk.org>; Mon, 18 Oct 2021 17:58:54 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 7442940141;
Mon, 18 Oct 2021 17:58:54 +0200 (CEST)
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com
[209.85.214.172])
by mails.dpdk.org (Postfix) with ESMTP id 70D1440141
for <stable@dpdk.org>; Mon, 18 Oct 2021 17:58:53 +0200 (CEST)
Received: by mail-pl1-f172.google.com with SMTP id y4so11596049plb.0
for <stable@dpdk.org>; Mon, 18 Oct 2021 08:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=sO45oPzzi96f8RkYx84QmNQBEkpzJ2q1cdK0/bPYWkM=;
b=oad59AGkvc1x5wbjBJQZa1x8ohSabrUOEw79Is0yUu9S17hgGWoqHlZ9YAOXpBFBX6
bNU7oG2BArakQJAwMtU3X9EAGLSTPrQdj5BDM6E1gc76C3ZBUlnUbN0sbeAXAz0NZOKg
fJrbJUuQGFze37NXGoLbCZwGazQRGFH0xS+v/eMcTamZIdczwO4hSAq26svGPa21ln1F
/0rb3yoRDHrSGl+lGXbY+WP8S9Y7sQ1FBw8whJm1rNHNPhe+CcCWQz+WRTGGFplyktJH
bkBTG+R04Cb+NqOPGqvxrz65Ffn9n9x+fc1axS1el176N9DozT0aPBqvqSKjiiFOm3Pl
rrTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=sO45oPzzi96f8RkYx84QmNQBEkpzJ2q1cdK0/bPYWkM=;
b=USgXk3HfLmo6PYfKbKVD73C5vncTdSpSHjeRTi8GWQBuW6UnTtJUuOE7egIMtx+Rdz
EIyZOTlHN3WnOPSaLJhJ+JzdSwJFh50w2qlbZU+/4HYA/9+W4YxGc1nvaS8xOKJaQK7L
oSJR2tW2TrvmHW8rQAsyGu3+lWcvsUSLJGm6fuG3glDRS4naOJsnvlTdbhOajZdUSLCO
K2AT01RH2x8LU6IWP9rqwLJ0Zk+IpwsB0z7H+dS5E76JuaWSlhL7Mqxu5FvRs/jdespX
2nYQ8pumPlyXQm4MO4vTAEnAW0ctudxw8H3vBlPlhE2zn2HY7aBV14p9oJRhKiL+L1Ys
kdOQ==
X-Gm-Message-State: AOAM530PqXJYI0Hqfq8M3PWORRKfgxfhFXqD9gYUu2EfqTtq6uj31orG
A+F35KCcMb2gCiJb9CA8GHcV+A==
X-Google-Smtp-Source: ABdhPJz0KaGqCnhgR96Ctn4wEOSYK65H/jI8Le34it7cgtl9y0kOuEMd16t6DZ088TOW+GvC+y6Lvw==
X-Received: by 2002:a17:90b:1c09:: with SMTP id
oc9mr22653947pjb.33.1634572732656;
Mon, 18 Oct 2021 08:58:52 -0700 (PDT)
Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123])
by smtp.gmail.com with ESMTPSA id q8sm19983067pja.52.2021.10.18.08.58.50
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 18 Oct 2021 08:58:51 -0700 (PDT)
Date: Mon, 18 Oct 2021 08:58:47 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Konstantin Ananyev <konstantin.ananyev@intel.com>
Cc: dev@dpdk.org, stable@dpdk.org
Message-ID: <20211018085847.2cb4ddc6@hermes.local>
In-Reply-To: <20211018134052.10514-1-konstantin.ananyev@intel.com>
References: <20211018134052.10514-1-konstantin.ananyev@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [PATCH] test/bpf: fix auto-test with clang fails
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On Mon, 18 Oct 2021 14:40:52 +0100
Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:
> test_shift1_check() function fails with clang build.
> The reason for that is that clang uses 64-bit shift instruction for
> what expected to be 32-bit operation.
> To be more specific, this C code:
> r2 = (uint32_t)r2 >> r4;
> With clang produces:
> 41a4eb: 48 d3 ef shr %cl,%rdi
> In that particular case it is an allowed choice, as from one side
> left-operand value is known to fit into 32 bits, from other side
> according to 'C' standard:
> "...if the value of the right operand is negative or is greater than
> or equal to the width of the promoted left operand, the behavior is
> undefined."
> The problem is that on x86 behavior for 64-bit and 32-bit shift
> operation might differ.
> The fix avoids undefined behavior by making sure
> that right operand will not exceed width of the promoted left operand.
>
> Bugzilla ID: 811
> Fixes: 9f8f9d91a701 ("test/bpf: introduce functional test")
> Cc: stable@dpdk.org
>
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Thanks
Acked-by: Stephen Hemminger <stephen@networkplumber.org>