On Tue, May 04, 2021 at 12:16:50PM +0200, Tobias Burnus wrote:
> Unless there are further comments, I intent to commit it after the lunch
> break.
Just further nits, sorry (but no need to retest):
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -6389,6 +6389,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq
> *ilist, gimple_seq *dlist,
> if (code == MINUS_EXPR)
> code = PLUS_EXPR;
>
> + /* C/C++ permits FP/complex with || and &&. */
> + bool is_fp_and_or
> + = (((code == TRUTH_ANDIF_EXPR) || (code == TRUTH_ORIF_EXPR))
The ()s around code == TRUTH_*_EXPR are unnecessary.
> + && (FLOAT_TYPE_P (TREE_TYPE (new_var))
> + || (TREE_CODE (TREE_TYPE (new_var)) ==
> COMPLEX_TYPE)));
And if I count well, this is too long, so should have == on the next line
below TREE_CODE. If it would fit, the ()s around the == would be
unnecessary too, the whole point of them is to make emacs happy (not an
emacs user myself though), which would otherwise misalign it.
Only needed if it needs a line split.
Without ()s, I think emacs likes to indent
foo (....)
|| bar (..................)
== ...........
as
foo (....)
|| bar (..................)
== ...........
and the cure is
foo (....)
|| (bar (..................)
== ...........)
> @@ -7397,13 +7429,32 @@ lower_reduction_clauses (tree clauses, gimple_seq
> *stmt_seqp,
> if (code == MINUS_EXPR)
> code = PLUS_EXPR;
>
> + /* C/C++ permits FP/complex with || and &&. */
> + bool is_fp_and_or = (((code == TRUTH_ANDIF_EXPR)
> + || (code == TRUTH_ORIF_EXPR))
See above.
Otherwise ok.
Jakub
