On Thu, Jan 14, 2021 at 07:26:36PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Is this ok for trunk if it passes bootstrap/regtest?

So, x86_64-linux bootstrap unfortunately broke due to the -march=i486
changes, but at least i686-linux bootstrap succeeded and shows 2
regressions.

One is on g++.dg/gomp/allocate-2.C, which used to print:
allocate-2.C:9:36: error: user defined reduction not found for ‘s’
but now prints:
allocate-2.C:9:36: error: user defined reduction not found for ‘*&s’
because of -O0 and therefore -fno-strict-aliasing.
The problem is that for !flag_strict_aliasing get_deref_alias_set returns 0
and so the:
&& get_deref_alias_set (TREE_OPERAND (e, 1)) == get_alias_set (op)
check fails.  So, shall the code use
&& (!flag_no_strict_aliasing
    || get_deref_alias_set (TREE_OPERAND (e, 1)) == get_alias_set (op))
instead, or
get_alias_set (TREE_TYPE (TREE_TYPE (TREE_OPERAND (e, 1))))
== get_alias_set (op)
?
The other is on gcc.dg/gomp/_Atomic-3.c test, where we used to print
_Atomic-3.c:22:34: error: ‘_Atomic’ ‘k’ in ‘reduction’ clause
but now print
_Atomic-3.c:22:34: error: ‘_Atomic’ ‘*(_Atomic int (*)[4])(&k[0])’ in 
‘reduction’ clause
Apparently in this case the C FE considers the two _Atomic int [4] types
incompatible, one is created through
c_build_qualified_type (type=<array_type 0x7fffea186a80>, type_quals=8, 
orig_qual_type=<tree 0x0>, orig_qual_indirect=1)
on an int [4] type, i.e. adding _Atomic qualifier to an unqualified array
type, and the other is created through
build_array_type (elt_type=<integer_type 0x7fffea186540 int>, 
index_type=<integer_type 0x7fffea186498>, typeless_storage=false)
i.e. creating an array with _Atomic int elements.
That seems like a C FE bug to me.

Anyway, I can fix or workaround that by:
--- gcc/c/c-typeck.c.jj 2021-01-04 10:25:49.651111329 +0100
+++ gcc/c/c-typeck.c    2021-01-15 09:53:29.590611264 +0100
@@ -13979,7 +13979,9 @@ c_finish_omp_clauses (tree clauses, enum
              size = size_binop (MINUS_EXPR, size, size_one_node);
              size = save_expr (size);
              tree index_type = build_index_type (size);
-             tree atype = build_array_type (type, index_type);
+             tree atype = build_array_type (TYPE_MAIN_VARIANT (type),
+                                            index_type);
+             atype = c_build_qualified_type (atype, TYPE_QUALS (type));
              tree ptype = build_pointer_type (type);
              if (TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
                t = build_fold_addr_expr (t);
and then we're back to the above allocate-2.C issue, i.e. at -O0
we still print *&k rather than k.

And another question is if in case we punted because of the TBAA check
we shouldn't just force printing the access type, so never print
*&k but print instead *(access type)&k.

        Jakub

Reply via email to