Richard Biener <rguent...@suse.de> writes:
> On April 27, 2021 5:12:35 PM GMT+02:00, Richard Sandiford
> <richard.sandif...@arm.com> wrote:
>>Now that VEC_COND_EXPR has normal unnested operands,
>>operation_could_trap_p can treat it like any other expression.
>>
>>This fixes many testsuite ICEs for SVE, but it turns out that none
>>of the tests in gcc.target/aarch64/sve were affected. Anyone testing
>>on non-SVE aarch64 therefore wouldn't have seen it.
>>
>>Tested on aarch64-linux-gnu (with and without SVE). OK to install?
>
> Hmm, I now remember why I didn't adjust this. Because on GENERIC the compares
> are still there and tree_could_trap_p uses the same helper in the end, thus
> it cannot handle VEC_COND_EXPR this way I think.
But is it meaningful to ask this question about one node of a GENERIC
expression in isolation? I thought you'd need a recursive test.
E.g. an EQ_EXPR could be comparing two integers that are the result
of a potentially-trapping FP operation.
If a caller does ask about only the VEC_COND_EXPR and not its operands,
then false seems like the right answer.
Thanks,
Richard
> Can you double check?
>
> Richard.
>
>>Richard
>>
>>
>>gcc/
>> PR middle-end/100284
>> * gimple.c (gimple_could_trap_p_1): Remove VEC_COND_EXPR test.
>> * tree-eh.c (operation_could_trap_p): Handle VEC_COND_EXPR rather
>> than asserting on it.
>>
>>gcc/testsuite/
>> PR middle-end/100284
>> * gcc.target/aarch64/sve/pr81003.c: New test.
>>---
>> gcc/gimple.c | 3 ---
>> gcc/testsuite/gcc.target/aarch64/sve/pr81003.c | 10 ++++++++++
>> gcc/tree-eh.c | 6 +++---
>> 3 files changed, 13 insertions(+), 6 deletions(-)
>> create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr81003.c
>>
>>diff --git a/gcc/gimple.c b/gcc/gimple.c
>>index d067656d315..f1044e9c630 100644
>>--- a/gcc/gimple.c
>>+++ b/gcc/gimple.c
>>@@ -2161,9 +2161,6 @@ gimple_could_trap_p_1 (gimple *s, bool
>>include_mem, bool include_stores)
>> /* For COND_EXPR only the condition may trap. */
>> if (op == COND_EXPR)
>> return tree_could_trap_p (gimple_assign_rhs1 (s));
>>- /* A VEC_COND_EXPR cannot trap. */
>>- else if (op == VEC_COND_EXPR)
>>- return false;
>>
>>/* For comparisons we need to check rhs operand types instead of rhs
>>type
>> (which is BOOLEAN_TYPE). */
>>diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
>>index a68778b9809..601285c401c 100644
>>--- a/gcc/tree-eh.c
>>+++ b/gcc/tree-eh.c
>>@@ -2541,9 +2541,9 @@ operation_could_trap_p (enum tree_code op, bool
>>fp_operation, bool honor_trapv,
>> bool honor_snans = fp_operation && flag_signaling_nans != 0;
>> bool handled;
>>
>>- /* This function cannot tell whether or not COND_EXPR and
>>VEC_COND_EXPR could
>>- trap, because that depends on the respective condition op. */
>>- gcc_assert (op != COND_EXPR && op != VEC_COND_EXPR);
>>+ /* This function cannot tell whether or not COND_EXPR could trap,
>>+ because that depends on its condition op. */
>>+ gcc_assert (op != COND_EXPR);
>>
>> if (TREE_CODE_CLASS (op) != tcc_comparison
>> && TREE_CODE_CLASS (op) != tcc_unary
>>diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr81003.c
>>b/gcc/testsuite/gcc.target/aarch64/sve/pr81003.c
>>new file mode 100644
>>index 00000000000..661a6f97d6d
>>--- /dev/null
>>+++ b/gcc/testsuite/gcc.target/aarch64/sve/pr81003.c
>>@@ -0,0 +1,10 @@
>>+/* { dg-options "-O3" } */
>>+
>>+unsigned int a, b;
>>+
>>+void
>>+foo (void)
>>+{
>>+ for (b = 0; b < 13; b += 2)
>>+ a &= !!b;
>>+}
