From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 927633850419 for ; Tue, 29 Dec 2020 18:44:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 927633850419 Received: by mail-ed1-x529.google.com with SMTP id h16so13388717edt.7 for ; Tue, 29 Dec 2020 10:44:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=Ry88wIZaJ1nOqz9bObyezRIei5y8WRopFRqVXZynWdU=; b=b1SKjMdV+wCqup1JYLuCl8U+ziLCLaT1mAJMH077INtncKlIzqf4LHfHn79pMpCd33 sAWRX7BdHYoYHpqdgpmCwT8pEZl/nu6O+hjQ443N5kDvFlld0najSco8oHcD+ssf/7Mt zjb7nW7aED9FyYwchhUEcaFU4Fz6poNfAqIKqhpeGsAHB793vrWVW3KiS+AggrABYkNm /liOjkk51PKpIiLlQLn3vfnNOa9ulrAPn4QzKQ6kRu8ZtaBR4g6QFDsrWsonp83GAuv2 1SAjD3R8dAlD9XBrtS+tI4KZZMQGMJRcprPouuWovXUpijck04UoNR2INyYqkw5hAhjh fWPg== X-Gm-Message-State: AOAM53059gyEIN8WdupZy2fp/gF1Vs4xEQozcAdpeU/Pbz4rk+zWDDii lTtAwRqkNXQKX4qC4rNmiKJrfVscOPI= X-Google-Smtp-Source: ABdhPJydPR7+1ctbZUbo/x2LgxRwviPwZH7FBtiOIxvr09hma+hJs6w78c1ZTGW45TBR8+TMpjA5Tw== X-Received: by 2002:a05:6402:3553:: with SMTP id f19mr33911687edd.129.1609267469538; Tue, 29 Dec 2020 10:44:29 -0800 (PST) Received: from [192.168.178.32] (dynamic-095-115-068-042.95.115.pool.telefonica.de. [95.115.68.42]) by smtp.gmail.com with ESMTPSA id u26sm37149964edo.37.2020.12.29.10.44.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2020 10:44:29 -0800 (PST) Date: Tue, 29 Dec 2020 19:44:24 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50e9877-9b37-a418-f420-aa4b9b1d59fe@stedding.saclay.inria.fr> References: <50e9877-9b37-a418-f420-aa4b9b1d59fe@stedding.saclay.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: What is the type of vector signed + vector unsigned? To: gcc@gcc.gnu.org, Marc Glisse , Richard Sandiford From: Richard Biener Message-ID: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:44:31 -0000 On December 29, 2020 6:42:30 PM GMT+01:00, Marc Glisse wrote: >On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote: > >> Any thoughts on what f should return in the following testcase, given >the >> usual GNU behaviour of treating signed >> as arithmetic shift right? >> >> typedef int vs4 __attribute__((vector_size(16))); >> typedef unsigned int vu4 __attribute__((vector_size(16))); >> int >> f (void) >> { >> vs4 x =3D { -1, -1, -1, -1 }; >> vu4 y =3D { 0, 0, 0, 0 }; >> return ((x + y) >> 1)[0]; >> } >> >> The C frontend takes the type of x+y from the first operand, so x+y >> is signed and f returns -1=2E > >Symmetry is an important property of addition in C/C++=2E > >> The C++ frontend applies similar rules to x+y as it would to scalars, >> with unsigned T having a higher rank than signed T, so x+y is >unsigned >> and f returns 0x7fffffff=2E > >That looks like the most natural choice=2E > >> FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++=2E > >I think clang follows gcc and uses the type of the first operand=2E The desired behavior is the one that OpenCL specifies=2E If it is implemen= tation defined we should document behavior=2E I agree symmetry is nice but = eventually the current C behavior is what OpenCL specifies=2E=20 Richard=2E=20