[Bug testsuite/81920] New: Improve timing-sensitive libgomp.oacc testcases

["vries at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 81920
           Summary: Improve timing-sensitive libgomp.oacc testcases
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There is a number of libgomp.oacc testcases that tests timing behaviour, and
fails on and off. In the .sum file they show up as execution failure, which
normally is associated with a wrong-code bug:
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0 
execution test
...

In the .log file we find evidence that in fact it's a timing issue, but the
message doesn't tell us what is the actual and expected time:
...
'./lib-81.exe'; echo XYZ$?ZYX^M
actual time too long^M
Aborted (core dumped)^M
XYZ134ZYX^M
OK>
Elapsed time: 1031 ms
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/lib-81.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -fofflo\
ad=nvptx-none  -O0  execution test
...

1. These should fail in output testing, not in execution, making clear in the
.sum file we're dealing with a timing issue.
2. The error message in the .log file should give details about actual and
expected time.
3. Having more detailed reporting may give us a better idea whether we need to
recalibrate, or whether there's an underlying issue that really needs fixing.