On Fri, 15 Jan 2021, Jakub Jelinek wrote:
> 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)
> ?
Elsewhere we use
tree decl = TREE_OPERAND (TREE_OPERAND (*t, 0), 0);
tree alias_type = TREE_TYPE (TREE_OPERAND (*t, 1));
...
/* Same TBAA behavior with -fstrict-aliasing. */
&& !TYPE_REF_CAN_ALIAS_ALL (alias_type)
&& (TYPE_MAIN_VARIANT (TREE_TYPE (decl))
== TYPE_MAIN_VARIANT (TREE_TYPE (alias_type)))
to guard eliding of the MEM_REF. So maybe use this form which doesn't
depend on alias sets.
> 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.
I guess so.
As said, I'm not a fan of too much magic here. A MEM_REF is what it is...
Richard.
