On 11/30/22 10:51, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 11:05:33PM +0100, Jakub Jelinek wrote:
On Tue, Nov 29, 2022 at 04:38:50PM -0500, Jason Merrill wrote:
--- gcc/testsuite/g++.dg/gomp/for-21.C.jj 2020-01-12 11:54:37.178401867
+0100
+++ gcc/testsuite/g++.dg/gomp/for-21.C 2022-11-29 13:06:59.038410557 +0100
@@ -54,9 +54,9 @@ void
f6 (S (&a)[10])
{
#pragma omp for collapse (2)
- for (auto [i, j, k] : a) // { dg-error "use of 'i' before deduction of
'auto'" "" { target *-*-* } .-1 }
+ for (auto [i, j, k] : a) // { dg-error "use of 'i' before
deduction of 'auto'" }
for (int l = i; l < j; l += k) // { dg-error "use of 'j'
before deduction of 'auto'" }
- ; // { dg-error "use of 'k' before
deduction of 'auto'" "" { target *-*-* } .-3 }
+ ; // { dg-error "use of 'k' before
deduction of 'auto'" "" { target *-*-* } .-1 }
Hmm, this error is surprising: since the initializer is non-dependent, we
should have deduced immediately. I'd expect the same error as in the
non-structured-binding cases, "* expression refers to iteration variable".
The reason was just to be consistent what is (unfortunately) emitted
in the other cases (!processing_template_decl or type dependent).
I guess I could try how much work would it be to deduce it sooner, but
generally it is pretty corner case, people rarely do this in OpenMP code.
I had a look at that today, but it would be pretty hard. The thing is
we must emit all the associated code for all the range for loops in
OpenMP loops at a different spot. So, the only possibility I see would
be if we during parsing of a range for loop inside of the OpenMP loop nest
we don't do the cp_finish_omp_range_for stuff to avoid e.g. cp_finish_decl,
but instead
build_x_indirect_ref (input_location, begin, RO_UNARY_STAR,
NULL_TREE, tf_none)
and if that gives a non-dependent type, temporarily overwrite TREE_TYPE
of the decl and if it is structured binding, temporarily
++processing_template_decl and cp_finish_decomp, then after parsing all the
associated loop headers we revert that (and ditto for instantiation of
OpenMP loops).
It looks like we're already deducing the type for the underlying S
variable in cp_convert_omp_range_for, we just aren't updating the types
of the individual bindings.
Jason
