public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/108399] New: wrong locations generated for OMP_FOR
@ 2023-01-13 18:14 sandra at gcc dot gnu.org
  0 siblings, 0 replies; only message in thread
From: sandra at gcc dot gnu.org @ 2023-01-13 18:14 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-01-13 18:14 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-13 18:14 [Bug c++/108399] New: wrong locations generated for OMP_FOR sandra at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).