public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake
@ 2020-08-27 12:24 zsojka at seznam dot cz
2020-08-27 12:46 ` [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597 marxin at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: zsojka at seznam dot cz @ 2020-08-27 12:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Bug ID: 96814
Summary: [11 Regression] wrong code with -march=cascadelake
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 49138
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49138&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -march=cascadelake testcase.c
$ sde64 -- ./a.out
Aborted
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2899-20200827080734-g989bc4ca2f2-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200827 (experimental) (GCC)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
@ 2020-08-27 12:46 ` marxin at gcc dot gnu.org
2020-08-27 12:59 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-08-27 12:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
Summary|[11 Regression] wrong code |[11 Regression] wrong code
|with -march=cascadelake |with -march=cascadelake
| |since
| |r11-1445-g502d63b6d6141597
Last reconfirmed| |2020-08-27
CC| |marxin at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with my r11-1445-g502d63b6d6141597.
Thank you for the report.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
2020-08-27 12:46 ` [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597 marxin at gcc dot gnu.org
@ 2020-08-27 12:59 ` rguenth at gcc dot gnu.org
2020-09-02 14:54 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-08-27 12:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
2020-08-27 12:46 ` [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597 marxin at gcc dot gnu.org
2020-08-27 12:59 ` rguenth at gcc dot gnu.org
@ 2020-09-02 14:54 ` marxin at gcc dot gnu.org
2020-09-03 7:33 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-09-02 14:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
So before the revision we generated:
_1 = { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
_2 = VEC_COND_EXPR <_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 }>;
_3 = VIEW_CONVERT_EXPR<V>(_2);
x = _3;
but now we have:
<bb 2> :
_1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_24 = VIEW_CONVERT_EXPR<unsigned short>(_1);
_25 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_26 = BIT_FIELD_REF <_25, 1, 0>;
_27 = _26;
_28 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
_29 = BIT_FIELD_REF <_28, 1, 0>;
_30 = _29;
_31 = _24 & 1;
_32 = _31 != 0 ? _27 : _30;
...
_151 = _24 & 32768;
_152 = _151 != 0 ? _147 : _150;
_2 = {_32, _40, _48, _56, _64, _72, _80, _88, _96, _104, _112, _120, _128,
_136, _144, _152};
_3 = .VCOND_MASK (_2, { -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 });
_4 = VIEW_CONVERT_EXPR<V>(_3);
x = _4;
i_15 = 0;
goto <bb 4>; [INV]
It's because veclower sees:
_1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_2 = VEC_COND_EXPR <_1, { 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 }>;
_3 = VEC_COND_EXPR <_2, { -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 }>;
_4 = VIEW_CONVERT_EXPR<V>(_3);
and if I see correctly the creation of the mask _2 is broken in RTL (probably
one can't build one from a vector costructor)?
Anyway SSA_NAMEs like _128 don't have any use.
@Richi: Can you please help me with that? I'm looking into it for quite some
time :/
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (2 preceding siblings ...)
2020-09-02 14:54 ` marxin at gcc dot gnu.org
@ 2020-09-03 7:33 ` rguenth at gcc dot gnu.org
2020-09-22 11:58 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-03 7:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's indeed odd that we have a VEC_COND_EXPR creating a boolean vector. With
GCC 10 veclower saw
_1 = { 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 = 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<char> while _1 is vector<bool> now we have
_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 };
_2 = 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 = 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<bool>, 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<bool>
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<boolean:1> is special:
<vector_cst 0x7ffff66572d0
type <vector_type 0x7ffff6647348
type <boolean_type 0x7ffff66472a0 public QI
size <integer_cst 0x7ffff680cdc8 constant 8>
unit-size <integer_cst 0x7ffff680cde0 constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff66472a0 precision:1 min <integer_cst 0x7ffff690d300 -1> max <integer_cst
0x7ffff6657258 0>>
SI
size <integer_cst 0x7ffff680cf18 constant 32>
unit-size <integer_cst 0x7ffff680cf30 constant 4>
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: <integer_cst 0x7ffff6657258 type <boolean_type 0x7ffff66472a0>
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) == VECTOR_CST
&& (type == TREE_TYPE (TREE_TYPE (arg0))
|| (VECTOR_TYPE_P (type)
&& TREE_TYPE (type) == TREE_TYPE (TREE_TYPE (arg0))))
&& tree_fits_uhwi_p (op1)
&& tree_fits_uhwi_p (op2))
{
tree eltype = TREE_TYPE (TREE_TYPE (arg0));
unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
unsigned HOST_WIDE_INT n = 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 code,
t
ree type,
&& tree_fits_uhwi_p (op2))
{
tree eltype = TREE_TYPE (TREE_TYPE (arg0));
- unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
+ unsigned HOST_WIDE_INT width
+ = (TREE_CODE (eltype) == BOOLEAN_TYPE
+ ? TYPE_PRECISION (eltype) : tree_to_uhwi (TYPE_SIZE (eltype)));
unsigned HOST_WIDE_INT n = tree_to_uhwi (arg1);
unsigned HOST_WIDE_INT idx = 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) == BOOLEAN_TYPE)
+ if (0 && TREE_CODE (type) == BOOLEAN_TYPE)
{
tree itype
= 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (3 preceding siblings ...)
2020-09-03 7:33 ` rguenth at gcc dot gnu.org
@ 2020-09-22 11:58 ` marxin at gcc dot gnu.org
2020-09-23 10:03 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-09-22 11:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
>
> 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
> code, t
> ree type,
> && tree_fits_uhwi_p (op2))
> {
> tree eltype = TREE_TYPE (TREE_TYPE (arg0));
> - unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
> + unsigned HOST_WIDE_INT width
> + = (TREE_CODE (eltype) == BOOLEAN_TYPE
> + ? TYPE_PRECISION (eltype) : tree_to_uhwi (TYPE_SIZE
> (eltype)));
> unsigned HOST_WIDE_INT n = tree_to_uhwi (arg1);
> unsigned HOST_WIDE_INT idx = 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) == BOOLEAN_TYPE)
> + if (0 && TREE_CODE (type) == BOOLEAN_TYPE)
> {
> tree itype
> = 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?
Ok, so apparently you installed already the patch. And yes, we still miscompile
it :(
>
> Note if I add -fdisable-tree-veclower ISEL ICEs.
>
> So I'd see where this VEC_COND_EXPR comes from.
The vector<char> is already build in C FE:
#0 build_opaque_vector_type (innertype=<integer_type 0x7ffff75ec2a0 signed
char>, nunits=...) at /home/marxin/Programming/gcc/gcc/tree.c:10964
#1 0x000000000082368e in build_binary_op (location=271264, code=GT_EXPR,
orig_op0=<compound_literal_expr 0x7ffff741d260>, orig_op1=<integer_cst
0x7ffff75f1078>, convert_p=true) at
/home/marxin/Programming/gcc/gcc/c/c-typeck.c:12164
#2 0x00000000008028e3 in parser_build_binary_op (location=271264,
code=GT_EXPR, arg1=..., arg2=...) at
/home/marxin/Programming/gcc/gcc/c/c-typeck.c:3755
#3 0x000000000084dcfd in c_parser_binary_expression (parser=0x7ffff7fc4ab0,
after=<optimized out>, omp_atomic_lhs=<tree 0x0>) at
/home/marxin/Programming/gcc/gcc/c/c-parser.c:8087
#4 0x000000000084e9b6 in c_parser_conditional_expression
(parser=0x7ffff7fc4ab0, after=<optimized out>, omp_atomic_lhs=<optimized out>)
at /home/marxin/Programming/gcc/gcc/c/c-parser.c:7691
#5 0x000000000084efe1 in c_parser_expr_no_commas (parser=0x7ffff7fc4ab0,
after=<optimized out>, omp_atomic_lhs=<optimized out>) at
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7606
for
(gdb) p debug_tree(orig_op0)
<compound_literal_expr 0x7ffff741d260
type <vector_type 0x7ffff740ed20 V
type <integer_type 0x7ffff75ec348 unsigned char public unsigned QI
size <integer_cst 0x7ffff75d3dc8 constant 8>
unit-size <integer_cst 0x7ffff75d3de0 constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff75ec348 precision:8 min <integer_cst 0x7ffff75d3df8 0> max <integer_cst
0x7ffff75d3d98 255>>
unsigned V16QI
size <integer_cst 0x7ffff75d3d20 constant 128>
unit-size <integer_cst 0x7ffff75d3d38 constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff740ec78 nunits:16>
side-effects
arg:0 <decl_expr 0x7ffff741d240
type <void_type 0x7ffff75ecf18 void VOID
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff75ecf18
pointer_to_this <pointer_type 0x7ffff75f4000>>
side-effects
arg:0 <var_decl 0x7ffff7fc4bd0 D.4011 type <vector_type 0x7ffff740ed20
V>
used unsigned ignored read decl_5 V16QI
/home/marxin/Programming/testcases/pr96814.c:8:12 size <integer_cst
0x7ffff75d3d20 128> unit-size <integer_cst 0x7ffff75d3d38 16>
align:128 warn_if_not_align:0 context <function_decl 0x7ffff7410200
main> initial <vector_cst 0x7ffff741d220>>
/home/marxin/Programming/testcases/pr96814.c:8:12 start:
/home/marxin/Programming/testcases/pr96814.c:8:12 finish:
/home/marxin/Programming/testcases/pr96814.c:8:12>>
$10 = void
(gdb) p debug_tree(orig_op1)
<integer_cst 0x7ffff75f1078 type <integer_type 0x7ffff75ec5e8 int> constant 0>
So the '(V){8} > 0' if I see correctly. I tried to manually change 'intt' in
parser_build_binary_op to boolean_type_node, but
it leads to:
/home/marxin/Programming/testcases/pr96814.c:8:21: error: invalid operands to
binary == (have ‘__vector(16) _Bool’ and ‘int’)
8 | x = ((V){8} > 0) == 0;
| ~~~~~~~~~~~~ ^~
| |
| __vector(16) _Bool
:/
Any hint how to resolve it?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (4 preceding siblings ...)
2020-09-22 11:58 ` marxin at gcc dot gnu.org
@ 2020-09-23 10:03 ` rguenth at gcc dot gnu.org
2020-09-25 8:14 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-23 10:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue of the miscompile is that we do not expand the vector<bool:1>
constructor created by vector lowering correctly. Of course we don't actually
_want_ CTORs of those ...
The following fixes the miscompile (but will still mishandle vector<bool:1>
CTORs concatenating multiple other vector<bool:1>)
diff --git a/gcc/expr.c b/gcc/expr.c
index 1a15f24b397..8bb3b4caf1c 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -6922,7 +6922,9 @@ store_constructor (tree exp, rtx target, int cleared,
poly
_int64 size,
insn_code icode = CODE_FOR_nothing;
tree elt;
tree elttype = TREE_TYPE (type);
- int elt_size = tree_to_uhwi (TYPE_SIZE (elttype));
+ int elt_size
+ = (VECTOR_BOOLEAN_TYPE_P (type) ? TYPE_PRECISION (elttype)
+ : tree_to_uhwi (TYPE_SIZE (elttype)));
machine_mode eltmode = TYPE_MODE (elttype);
HOST_WIDE_INT bitsize;
HOST_WIDE_INT bitpos;
@@ -7045,7 +7047,9 @@ store_constructor (tree exp, rtx target, int cleared,
poly_int64 size,
HOST_WIDE_INT eltpos;
tree value = ce->value;
- bitsize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (value)));
+ bitsize = (VECTOR_BOOLEAN_TYPE_P (type)
+ ? elt_size
+ : tree_to_uhwi (TYPE_SIZE (TREE_TYPE (value))));
if (cleared && initializer_zerop (value))
continue;
Another interesting case is IMHO
typedef unsigned char __attribute__ ((__vector_size__ (32))) V;
unsigned char c = 8;
int
main (void)
{
V x = ((V){c} > 0) == 0;
for (unsigned i = 0; i < sizeof (x); i++)
if (x[i] != (i ? 0xff : 0)) __builtin_abort();
return 0;
}
which shows different behavior of veclower:
+ vector(32) <signed-boolean:1> _20;
+ vector(32) <signed-boolean:1> _21;
<bb 2> :
c.0_1 = c;
_11 = {c.0_1};
_2 = _11 != { 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 };
- _3 = VEC_COND_EXPR <_2, { 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 }>;
+ _20 = _11 != { 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 };
+ _21 = ~_20;
+ _3 = _21;
_4 = VEC_COND_EXPR <_3, { -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 }>;
it shows that while the initial FE IL has the nested VEC_COND (maybe avoid
that for boolean vectors?) we fold one case but not the other?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (5 preceding siblings ...)
2020-09-23 10:03 ` rguenth at gcc dot gnu.org
@ 2020-09-25 8:14 ` rguenth at gcc dot gnu.org
2020-09-25 13:40 ` cvs-commit at gcc dot gnu.org
2020-09-25 13:41 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-25 8:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the extra folding for PR97085 also fixed this testcase, now expanding
from
_1 = { 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 = .VCOND_MASK (_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 });
_3 = VIEW_CONVERT_EXPR<V>(_2);
I still have a patch for the CTOR expansion which I'll test and propose.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (6 preceding siblings ...)
2020-09-25 8:14 ` rguenth at gcc dot gnu.org
@ 2020-09-25 13:40 ` cvs-commit at gcc dot gnu.org
2020-09-25 13:41 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-09-25 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:d16b5975ca985cbe97698479fc38b6a636886978
commit r11-3460-gd16b5975ca985cbe97698479fc38b6a636886978
Author: Richard Biener <rguenther@suse.de>
Date: Fri Sep 25 11:13:13 2020 +0200
middle-end/96814 - fix VECTOR_BOOLEAN_TYPE_P CTOR RTL expansion
The RTL expansion code for CTORs doesn't handle VECTOR_BOOLEAN_TYPE_P
with bit-precision elements correctly as the testcase shows before
the PR97085 fix. The following makes it do the correct thing
(not 100% sure for CTOR of sub-vectors due to the lack of a testcase).
The alternative would be to assert such CTORs do not happen (and also
add IL verification for this).
The GIMPLE FE needs a way to declare the VECTOR_BOOLEAN_TYPE_P vectors
(thus the C FE needs that).
2020-09-25 Richard Biener <rguenther@suse.de>
PR middle-end/96814
* expr.c (store_constructor): Handle VECTOR_BOOLEAN_TYPE_P
CTORs correctly.
* gcc.target/i386/pr96814.c: New testcase.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
` (7 preceding siblings ...)
2020-09-25 13:40 ` cvs-commit at gcc dot gnu.org
@ 2020-09-25 13:41 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-25 13:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Latent issue fixed as well.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-09-25 13:41 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-27 12:24 [Bug target/96814] New: [11 Regression] wrong code with -march=cascadelake zsojka at seznam dot cz
2020-08-27 12:46 ` [Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597 marxin at gcc dot gnu.org
2020-08-27 12:59 ` rguenth at gcc dot gnu.org
2020-09-02 14:54 ` marxin at gcc dot gnu.org
2020-09-03 7:33 ` rguenth at gcc dot gnu.org
2020-09-22 11:58 ` marxin at gcc dot gnu.org
2020-09-23 10:03 ` rguenth at gcc dot gnu.org
2020-09-25 8:14 ` rguenth at gcc dot gnu.org
2020-09-25 13:40 ` cvs-commit at gcc dot gnu.org
2020-09-25 13:41 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).