[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for GCC 13.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f13305518558f20ef2d460a74eb29dad5fce1350 commit r13-4461-gf13305518558f20ef2d460a74eb29dad5fce1350 Author: Jakub Jelinek Date: Fri Dec 2 10:30:16 2022 +0100 c++: Incremental fix for g++.dg/gomp/for-21.C [PR84469] The PR84469 patch I've just posted regresses the for-21.C testcase, when in OpenMP loop there are at least 2 associated loops and in a template outer structured binding with non type dependent expression is used in the expressions of some inner loop, we don't diagnose those any longer, as the (weirdly worded) diagnostics was only done during finish_id_expression -> mark_used which for the inner loop expressions happens before the structured bindings are finalized. When in templates, mark_used doesn't diagnose uses of non-deduced variables, and if the range for expression is type dependent, it is similarly diagnosed during instantiation. But newly with the PR84469 fix if the range for expression is not type dependent, there is no place that would diagnose it, as during instantiation the structured bindings are already deduced. This patch ensures that the bug of using structured bindings from one associated loop in other associated loops is diagnosed by the c_omp_check_loop_iv code by ensuring that cp_finish_decomp is called already during cp_convert_omp_range_for if the artificial iterator has been successfully auto-deduced. 2022-12-02 Jakub Jelinek PR c++/84469 gcc/c-family/ * c-omp.cc (c_omp_is_loop_iterator): For range for with structured binding return TREE_VEC_LENGTH (d->declv) even if decl is equal to any of the structured binding decls. gcc/cp/ * parser.cc (cp_convert_omp_range_for): After do_auto_deduction if !processing_template_decl call cp_finish_decomp with processing_template_decl temporarily incremented. gcc/testsuite/ * g++.dg/gomp/for-21.C (f3, f6, f9): Adjust expected diagnostics. * g++.dg/gomp/for-22.C: New test.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ee4f25999f6832a1c5060b9277222c03d852709a commit r13-4460-gee4f25999f6832a1c5060b9277222c03d852709a Author: Jakub Jelinek Date: Fri Dec 2 10:29:11 2022 +0100 c++: Deduce range for structured bindings if expression is not type dependent [PR84469] As shown on the decomp56.C testcase, if the range for expression when using structured bindings is not type dependent, we deduce the finish the structured binding types only when not in template (cp_convert_range_for takes care of that), but if in templates, do_range_for_auto_deduction is called instead and it doesn't handle structured bindings. During instantiation they are handled later, but during the parsing keeping the structured bindings type dependent when they shouldn't be changes behavior. The following patch calls cp_finish_decomp even from do_range_for_auto_deduction. The patch regresses the OpenMP g++.dg/gomp/for-21.C test (3 errors are gone), I'll post an incremental patch for it momentarily. 2022-12-02 Jakub Jelinek PR c++/84469 * parser.cc (do_range_for_auto_deduction): Add DECOMP_FIRST_NAME and DECOMP_CNT arguments. Call cp_finish_decomp if DECL is a structured binding. (cp_parser_range_for): Adjust do_range_for_auto_deduction caller. (cp_convert_omp_range_for): Likewise. * g++.dg/cpp1z/decomp56.C: New test. * g++.dg/gomp/pr84469.C: New test.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
--- Comment #7 from Jakub Jelinek ---
The patch unfortunately regresses the OpenMP g++.dg/gomp/for-21.C test:
template
void
f6 (S ()[10])
{
#pragma omp for collapse (2)
for (auto [i, j, k] : a) // { dg-error "use of 'i'
before deduction of 'auto'" "" { target *-*-* } .-1 }
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 }
}
...
S c[10] {};
f6 <0> (c);
where the bug is no longer diagnosed. When not in a template or when the
range for decl is type dependent, it works because the invalid uses are
diagnosed by finish_id_expression -> mark_used and complain about uses of auto
before it is deduced, but in the above case a is not type dependent, mark_used
doesn't complain about uses of auto when processing_template_decl and the new
code deduces a and i/j/k before finish_id_expression is called on it again
during instantiation.
So, I'll need to add further code to handle this right.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 53964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53964=edit gcc13-pr84469.patch Untested fix.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 Andrew Pinski changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 107858 has been marked as a duplicate of this bug. ***
