From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8729F3870849; Thu, 3 Sep 2020 07:33:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8729F3870849 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1599118396; bh=N+XTED9ggeaIGD3avKe7WDKeIiHVnZWAGNov4OSE9+A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YHc4xq1Z9SqoHWFdtSjbjapH6sFOFxMXT9bURLM+nnO+guctCT57WyRGHzE60nj6X LZ7Tbg1Aruoofk9RfBGRHAdgqsANztlunOk6nawyORUS20ULBu/D8dtruwqrb7WrxY YZE5lsxqKJzZvs09rumltUW4m8MNelhxN51nPpPY= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597 Date: Thu, 03 Sep 2020 07:33:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 07:33:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96814 --- Comment #3 from Richard Biener --- It's indeed odd that we have a VEC_COND_EXPR creating a boolean vector. Wi= th GCC 10 veclower saw _1 =3D { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -= 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }; _2 =3D VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -= 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 = }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, = 0, 0, 0, 0, 0, 0, 0 }>; and _2 is vector while _1 is vector now we have _1 =3D { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; _2 =3D VEC_COND_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,= -1, -1, -1, -1, -1, -1 }>; _3 =3D VEC_COND_EXPR <_2, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -= 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 = }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, = 0, 0, 0, 0, 0, 0, 0 }>; where _2 is vector, appearantly inverting _1. This is either new or missed folding I guess (I see this in .original already). Now, veclower better shouldn't touch this - definitely a vector ctor from SSA names isn't something we want... Though in principle we should generate correct code here or give up. So I'd say we hit a latent issue here? I see we're doing a bad job in constant folding as well, mostly because our representation of vector is special: unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff66472a0 precision:1 min max > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff6647348 nunits:32> constant npatterns:1 nelts-per-pattern:1 elt:0: constant 0>> see how we're having a vector type of a QImode boolean with size 8. The folding code assumes it can work with TYPE_SIZE of the component: case BIT_FIELD_REF: if (TREE_CODE (arg0) =3D=3D VECTOR_CST && (type =3D=3D TREE_TYPE (TREE_TYPE (arg0)) || (VECTOR_TYPE_P (type) && TREE_TYPE (type) =3D=3D TREE_TYPE (TREE_TYPE (arg0)))) && tree_fits_uhwi_p (op1) && tree_fits_uhwi_p (op2)) { tree eltype =3D TREE_TYPE (TREE_TYPE (arg0)); unsigned HOST_WIDE_INT width =3D tree_to_uhwi (TYPE_SIZE (eltype)= ); unsigned HOST_WIDE_INT n =3D tree_to_uhwi (arg1); but that's not true for these types. diff --git a/gcc/fold-const.c b/gcc/fold-const.c index 1f861630225..0cc80adf632 100644 --- a/gcc/fold-const.c +++ b/gcc/fold-const.c @@ -12581,7 +12581,9 @@ fold_ternary_loc (location_t loc, enum tree_code co= de, t ree type, && tree_fits_uhwi_p (op2)) { tree eltype =3D TREE_TYPE (TREE_TYPE (arg0)); - unsigned HOST_WIDE_INT width =3D tree_to_uhwi (TYPE_SIZE (eltype)= ); + unsigned HOST_WIDE_INT width + =3D (TREE_CODE (eltype) =3D=3D BOOLEAN_TYPE + ? TYPE_PRECISION (eltype) : tree_to_uhwi (TYPE_SIZE (eltype)= )); unsigned HOST_WIDE_INT n =3D tree_to_uhwi (arg1); unsigned HOST_WIDE_INT idx =3D tree_to_uhwi (op2); diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c index 6d5d65195ae..e9dbe07dccc 100644 --- a/gcc/tree-vect-generic.c +++ b/gcc/tree-vect-generic.c @@ -137,7 +137,7 @@ tree_vec_extract (gimple_stmt_iterator *gsi, tree type, } if (bitpos) { - if (TREE_CODE (type) =3D=3D BOOLEAN_TYPE) + if (0 && TREE_CODE (type) =3D=3D BOOLEAN_TYPE) { tree itype =3D build_nonstandard_integer_type (tree_to_uhwi (bitsize), 0); makes the generated code a bit easier to follow but I guess still ends up miscompiling things? Note if I add -fdisable-tree-veclower ISEL ICEs. So I'd see where this VEC_COND_EXPR comes from.=