Fixed by f1047b2e9656ba1cb3b672df22b2178ad0b38738.

Test 313 (AC_OPENMP) can fail with Sun C 5.9 by leaving a file named "penmp" in configure's working directory.

This compiler actually does support OpenMP, but with the right combination of operating system patches applied and not applied, the option that should enable support doesn't work, you get a link failure:

configure:3238: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -xopenmp -I/opt/csw/include -m32 -xarch=pentium_pro -xchip=pentium_pro -L/opt/csw/lib conftest.c  >&5
ld: fatal: file /lib/libc.so: version 'SUNW_1.23' is unavailable:
        required by file /lib/libmtsk.so
ld: fatal: file /lib/libc.so: version 'SUNW_1.22.7' is unavailable:
        required by file /lib/libmtsk.so
ld: fatal: file processing errors. No output written to conftest

This makes AC_OPENMP continue trying to find options that will work, one of which is

configure:3238: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -Popenmp -I/opt/csw/include -m32 -xarch=pentium_pro -xchip=pentium_pro -L/opt/csw/lib conftest.c  >&5
configure:3238: $? = 0

The `-Popenmp` option is interpreted as `-P -o penmp`, i.e. create a file named 'penmp' which contains the result of preprocessing conftest.c.  Note that this invocation succeeds, but the AC_LINK_IFELSE that ran it fails anyway, because it did not create conftest$ac_exeext.

The author of AC_OPENMP anticipated this problem:

          dnl If in this loop a compiler is passed an option that it doesn't
          dnl understand or that it misinterprets, the AC_LINK_IFELSE test
          dnl will fail (since we know that it failed without the option),
          dnl therefore the loop will continue searching for an option, and
          dnl no output file called 'penmp' or 'mp' is created.

but apparently did not consider the possibility of an AC_LINK_IFELSE failing but creating 'penmp' nonetheless.

A fix for this exact situation would be to run a compile test for each option first.  That would detect that `-xopenmp` is the correct option to use for this compiler, and then we would do a link test with that option to verify that it actually works, determine that it doesn't, and proceed to report "unsupported" without ever trying `-Popenmp`.  However, the fundamental problem remains; compile tests could also wind up creating a file named 'penmp' or 'mp'.

Ideally, we would run all tests that can create files in a scratch directory, not in the top level of the source or build tree.  That's much too big of a change for 2.70, though, and may not be possible at all.  The only other thing I can think of is to have AC_OPENMP check before its main loop that no files named 'penmp' or 'mp' exist.  If they do, it aborts, because the problem compiler invocations would clobber those files.  If they don't, though, then it can safely delete them afterward.

Does anyone have a better idea?

(Originally reported by Dagobert as part of sr #110320, logs extracted from file #49872.)