[Bug libgomp/70805] New: libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL

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

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

            Bug ID: 70805
           Summary: libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
              Host: sparc*-sun-solaris2.*
            Target: sparc*-sun-solaris2.*
             Build: sparc*-sun-solaris2.*

The libgomp.c/for-5.c and libgomp.c++/for-13.C tests FAIL on 1.2 GHz UltraSPARC
T2
systems running Solaris 1[0-2]:

WARNING: program timed out.
FAIL: libgomp.c/for-5.c (test for excess errors)
WARNING: libgomp.c/for-5.c compilation failed to produce executable
WARNING: program timed out.
FAIL: libgomp.c++/for-13.C (test for excess errors)
WARNING: libgomp.c++/for-13.C compilation failed to produce executable

It turns out that even on an otherwise idle system, compilation times are
dangerously close to the default testcase timeout of 300s:

real        3:28.01
user        3:25.67
sys            0.71

real        3:30.60
user        3:27.88
sys            0.71

On a 2.27 GHz Xeon X5520, I get instead:

real          30.12
user          28.59
sys            0.38

real          30.65
user          28.93
sys            0.39

I long didn't noticed this because I had doubled the default timeout to 600 s,
but those two tests are almost the only ones where this makes a difference.
I wonder if one should either use dg-timeout-factor 2 or something else.

  Rainer