This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] handle OpenMP/OpenACC regions inside Fortran character functions (PR85703)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Cesar Philippidis <cesar_philippidis at mentor dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Fortran List <fortran at gcc dot gnu dot org>
- Date: Wed, 13 Jun 2018 16:12:52 +0200
- Subject: Re: [PATCH] handle OpenMP/OpenACC regions inside Fortran character functions (PR85703)
- References: <156e0ebd-08f7-4424-4899-386c571444c2@mentor.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jun 13, 2018 at 07:06:23AM -0700, Cesar Philippidis wrote:
> Character variables in Fortran are slightly different than reals and
> integers because they can represent a single character or a string of
> them. Consequently, due their nature, the Fortran resolver requires more
> information to preform error checking on them.
>
> PR85703 exposed an ICE when an OpenACC or OpenMP region is nested inside
> a Fortran character function. I've isolated the problem down to the
> gfc_matching_function not being reset on entry to decode_oacc_directive
> or decode_omp_directive. Usually decode_statement resets that variable,
> but both OpenACC and OpenMP have their own statement decoders, and
> therein lies the problems. The fix is to reset gfc_matching_function
> early in those functions.
>
> Is this OK for trunk and GCC 8?
Ok, thanks.
> 2018-06-13 Cesar Philippidis <cesar@codesourcery.com>
>
> PR fortran/85703
>
> gcc/fortran/
> * parse.c (decode_oacc_directive): Set gfc_matching_function
> to false.
> (decode_omp_directive): Likewise.
>
> gcc/testsuite/
> * gfortran.dg/goacc/pr85703.f90: New test.
> * gfortran.dg/gomp/pr85703.f90: New test.
Jakub