From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5595BA0544; Tue, 21 Jun 2022 00:54:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E8B7B4069C; Tue, 21 Jun 2022 00:54:55 +0200 (CEST) Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mails.dpdk.org (Postfix) with ESMTP id 1438240151 for ; Tue, 21 Jun 2022 00:54:53 +0200 (CEST) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25KMjrP1017240; Mon, 20 Jun 2022 22:54:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=kxohux5ZRdnLV8husqx+FGqHKi3yKzp2gOUGq35Ieqw=; b=g5PpHsx3Ba0vJ0ZAxzM3NfrQdchKUKFVTwXoAFcS+MXYT0QlXfv7l+OQg9N8dCG4iM/8 qEgDRO9Qt7D2QOXSesg7585pVY0lAbymvNKfNPUqzey2tFAzTNzy85pP+1a2t1OTe+79 Fpv1pdQxmEneGPE3KT3k+bcRrNUyxDiYyvfOl4aI3MlT6cAAA9Nz0XLw6dCMf2h4QnkN ChMIjuAgC03xaayv/xTMq1e/9V/FxFjAF9xBCDCemw4YNh5iZqxLAv91wx5pKGKcWUQQ Brnidf8j4Z4xQwy9Wv4AyxSts5CvJe11G27Rjjo4BajfHNOlViRuLK785TtVnYmiqh9F 5w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gu1ygr3y3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2022 22:54:51 +0000 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 25KMrIIo010314; Mon, 20 Jun 2022 22:54:50 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gu1ygr3xt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2022 22:54:50 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 25KMpdHn003784; Mon, 20 Jun 2022 22:54:49 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma01wdc.us.ibm.com with ESMTP id 3gs6b984p5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2022 22:54:49 +0000 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 25KMsnCE33161692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Jun 2022 22:54:49 GMT Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EAB2ABE04F; Mon, 20 Jun 2022 22:54:48 +0000 (GMT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C1A2BE051; Mon, 20 Jun 2022 22:54:48 +0000 (GMT) Received: from [9.211.69.77] (unknown [9.211.69.77]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 20 Jun 2022 22:54:48 +0000 (GMT) Message-ID: <63ed6e6c-337d-8f8a-9410-1e43b0561967@linux.vnet.ibm.com> Date: Mon, 20 Jun 2022 15:54:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 0/3] Fix xmm_t to rte_xmm_t scalar conversion Content-Language: en-US To: David Marchand , Stanislaw Kardach Cc: dev , upstream@semihalf.com, Aaron Conole , Bruce Richardson , "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , Jerin Jacob Kollanukkaran References: <20220609121701.716299-1-kda@semihalf.com> From: David Christensen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: rXnvmAM9ac9WGkTDVGwW4Pc6sfcBZGOy X-Proofpoint-GUID: 6hziGOVlovxqzjfBN62P7yKxtl99pjIe X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-20_06,2022-06-17_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 phishscore=0 malwarescore=0 adultscore=0 clxscore=1011 impostorscore=0 spamscore=0 bulkscore=0 mlxlogscore=620 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206200101 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > On Thu, Jun 9, 2022 at 2:17 PM Stanislaw Kardach wrote: >> >> As David noticed in [1] there is an issue with C++ compilation of the >> rte_vect.h header in RISC-V. Upon closer inspection, the problem appears on >> all architectures due to the type conversion rules in C++. >> More precisely a union type rte_xmm_t requires a conversion constructor >> from xmm_t type. >> The most obvious fix is to use a structure initializer for such copies >> (since rte_xmm_t union contains xmm_t anyway). The generated assembly >> at -O2 is exactly the same, so there's no real impact. >> >> The bigger question is whether accessing bits of the architecture specific >> xmm_t type in an array fashion is always correct? All current architectures >> define rte_xmm_t in the same manner implying that. > > Copying other arch maintainers. My read of the Altivec vector layout for LE systems says the existing union operator rte_xmm_t is correct, though my C++ experience is limited. How can I generate an error with C++ to expose this issue? Dave