This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch][Fortran] OpenMP – libgomp/testsuite – use 'stop' and 'dg-do run'
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Burnus <tobias at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, fortran <fortran at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 25 Oct 2019 09:27:30 -0700
- Subject: Re: [Patch][Fortran] OpenMP – libgomp/testsuite – use 'stop' and 'dg-do run'
- References: <56e2be4c-707c-9b09-e18b-1bf25e912296@codesourcery.com>
- Reply-to: sgk at troutmask dot apl dot washington dot edu
On Fri, Oct 25, 2019 at 06:17:26PM +0200, Tobias Burnus wrote:
> This patch is about: libgomp/testsuite/libgomp.fortran/, only
>
> The two test cases I added recently use 'call abort()', which is
> nowadays frowned on as that's a ventor extension. Hence, I change it to
> 'stop'.
>
> Additionally, the 'fortran.exp' in the directory states: "For Fortran
> we're doing torture testing, as Fortran has far more tests with arrays
> etc. that testing just -O0 or -O2 is insufficient, that is typically not
> the case for C/C++."
>
> The torture testing is only done if there is a "dg-do run"; without
> dg-do, it also does run, but only with a single compile flag setting.
>
> I have only selectively added it; I think 'dg-do run' does not make
> sense for:
> * condinc*.f – only do uses '!$ include'
> * omp_cond*.f* – only tests '!$' code, including comments.
> Hence, I excluded those and only changed the others. (However, one can
> still argue about the remaining ones – such as 'omp_hello.f' or tabs*.f*.)
>
> OK for the trunk? Add/remove for 'dg-do run' from additional test cases?
>
> Tobias
>
I think this patch and the openacc patch are fine.
With openmp and openacc, I usually defer to Jakub, Thomas,
and Cesar for their expertise with these standards. I do,
however, recognize that everyone has limited amounts of time.
If you have openmp/openacc patches I can cast an eye over
them for formatting issues; otherwise, I'll leave it to your
discretion on what a reasonable review timeout is prior to
committing a change.