https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Apparently this ICEs for one reason in C and completely different reason in
C++,
the C++ reason is very much broken expand_array_notation_exprs, I think I've
mentioned that already several years ago - while the C FE uses walk_tree and
just handles the trees it wants to handle, the C++ FE just recursively calls
itself and thinks it handles everything it should, but obviously doesn't (and
some cases like OMP_PARALLEL which appears here pretends to handle, but doesn't
actually). So, IMHO the C++ expand_array_notation_exprs needs to be rewritten
to use cp_walk_tree instead. There is another problem that affects also the C
FE, the callback routine calls contains_array_notation_expr, which again walks
all the subtrees (and doesn't use *walk_tree for that, another bug); but that
means with very large expression the compile time complexity is exponential.
Probably it needs to instead do contains_array_notation_expr just once and mark
all the expressions that contain array notations in some hash map, then just
look up that hash map or something similar.
On the other side, the C++ FE has a hack like:
/* If it is a built-in array notation function, then the return type of
the function is the element type of the array passed in as array
notation (i.e. the first parameter of the function). */
if (flag_cilkplus && TREE_CODE (fn) == CALL_EXPR)
{
enum built_in_function bif =
is_cilkplus_reduce_builtin (CALL_EXPR_FN (fn));
if (bif == BUILT_IN_CILKPLUS_SEC_REDUCE_ADD
|| bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MUL
|| bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MAX
|| bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MIN
|| bif == BUILT_IN_CILKPLUS_SEC_REDUCE
|| bif == BUILT_IN_CILKPLUS_SEC_REDUCE_MUTATING)
{
if (call_expr_nargs (fn) == 0)
{
error_at (EXPR_LOCATION (fn), "Invalid builtin arguments");
return error_mark_node;
}
/* for bif == BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_ZERO or
BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_ZERO or
BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_NONZERO or
BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_NONZERO or
BUILT_IN_CILKPLUS_SEC_REDUCE_MIN_IND or
BUILT_IN_CILKPLUS_SEC_REDUCE_MAX_IND
The pre-defined return-type is the correct one. */
tree array_ntn = CALL_EXPR_ARG (fn, 0);
TREE_TYPE (fn) = TREE_TYPE (array_ntn);
return fn;
}
}
in build_cxx_call, which, while very unclean, actually fixes the issue the C FE
is having - that the return type from __sec_reduce_add etc. is initially
thought to be int rather than the type of the first argument. The clean fix is
to remove the above hack and use
IFN_CILKPLUS_SEC_REDUCE{_ADD,_MUL,_MAX,_MIN,,_MUTATING} internal fns and
resolve_overloaded_built create those ifn calls with the right type.
A hackish fix is essentially to move the above hack into
resolve_overloaded_builtin (it is unclean, because the builtin still claims
return type of int and the CALL_EXPR doesn't match it, but as it is lowered
soon afterwards, it might not be as a big deal).
I don't want to write all of the above myself, so the question is, is Intel
still maintaining the Cilk+ support, or is it time to deprecate it and remove
in the next release?
