[Bug c++/108399] New: wrong locations generated for OMP_FOR

sandra at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Jan 13 18:14:21 GMT 2023


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108399

            Bug ID: 108399
           Summary: wrong locations generated for OMP_FOR
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54268&action=edit
WIP patch

While working on some other changes to the "omp for" directive, I noticed that
the locations for errors generated by the C++ front end are inconsistent with
those from the C front end, and not uniform internally within the C++ front end
either.  Specifically, the C front end tags the OMP_FOR with the location of
the directive while the C++ front end tags it with the location of its
outermost nested "for" loop...  but in some cases errors end up being diagnosed
on the line of the directive anyway (see f5 in g++.dg/gomp/loop-8.C, for
instance).

I came up with the attached patch to address this, and fix an obvious think-o
in pt.cc too.  This caused a bunch of regressions in existing test cases:

c-c++-common/gomp/loop-10.c
c-c++-common/gomp/loop-6.c
c-c++-common/gomp/order-4.c
g++.dg/gomp/for-11.C
g++.dg/gomp/for-16.C
g++.dg/gomp/for-1.C
g++.dg/gomp/linear-2.C
g++.dg/gomp/loop-1.C
g++.dg/gomp/loop-2.C
g++.dg/gomp/loop-3.C
g++.dg/gomp/loop-4.C
g++.dg/gomp/loop-5.C
g++.dg/gomp/loop-6.C
g++.dg/gomp/loop-8.C
g++.dg/gomp/pr25996.C
g++.dg/gomp/pr27415.C
g++.dg/gomp/pr35078.C
g++.dg/gomp/pr37533.C
g++.dg/gomp/pr39495-2.C
g++.dg/gomp/pr58567.C
g++.dg/gomp/pr67511.C
g++.dg/gomp/pr67523.C
g++.dg/gomp/pr84448.C
g++.dg/gomp/simd-2.C

The first 3 just need to have the C/C++ conditionalization removed, but in
looking at g++.dg/gomp/for-11.C I realized there is a further bug with invalid
subexpressions of the nested loops not being tagged with correct location
information either by the C++ front end.  It looks like the C parser seems to
be taking more care about this:

            default:
              /* Can't be cond = error_mark_node, because we want to preserve   
                 the location until c_finish_omp_for.  */
              cond = build1 (NOP_EXPR, boolean_type_node, error_mark_node);

while the C++ front end is just returning bare error_mark_node.

I think it is a reasonable expectation that the C and C++ front ends behave
identically in diagnosing errors for things that have the same semantics in
both languages.  Aside from fixing the bugs, probably most of the C error tests
for "omp for" should be moved to c-c++-common so that we can enforce this.

Anyway, this is looking like a can of worms and lower priority than the thing I
was working on when I ran into this, so I'm dumping state in this issue for
now.  If anybody else wants to pick it up meanwhile, feel free.


More information about the Gcc-bugs mailing list