From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id B5A4B3857B80; Mon, 17 Oct 2022 13:19:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5A4B3857B80
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666012753;
	bh=UX7IkrbZ+NhQUm8F53vGNEtRK0TvuTxapr8516+ejXQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=sNyq68PDZzIyzcNNb3lsz6e30ORQEZzQM5wqa5GJaQuE8cRrAawEJvOs9oy1DKn5Z
	 OtXoCEhfvpL2Xt+BYypAcaU0n60u0IELIJZMmNEAXPU7VZV6O/55O2W3tJFR69nS4O
	 UvE7s43vaMdzZZavxVmCmofcnpJ6gN2PUZlWs4nk=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/107295] [13 Regression] Rejected code in libreoffice with
 -m32 since r13-3290-g98e341130f87984a
Date: Mon, 17 Oct 2022 13:19:13 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107295-4-qSq7BkkZvY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107295-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107295-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107295

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is likely the
"There is one exception, pr68180.C looks like a bug in the patch which is
also present in the C FE (so I'd like to get it resolved incrementally
in both).  Reduced testcase:
typedef float __attribute__((vector_size (16))) float32x4_t;
float32x4_t foo(float32x4_t x, float y) { return x + y; }
with -m32 -std=3Dc11 -Wno-psabi or -m32 -std=3Dc++17 -Wno-psabi
it is rejected with:
pr68180.c:2:52: error: conversion of scalar =E2=80=98long double=E2=80=99 t=
o vector
=E2=80=98float32x4_t=E2=80=99 {aka =E2=80=98__vector(4) float=E2=80=99} inv=
olves truncation
but without excess precision (say just -std=3Dc11 -Wno-psabi or -std=3Dc++17
-Wno-psabi)
it is accepted.  Perhaps we should pass down the semantic type to
scalar_to_vector and use the semantic type rather than excess precision type
in the diagnostics."
issue mentioned in the mail/commit log, though I'd have to verify that.=