forked from Imagelibrary/binutils-gdb
2e3aff2762
Currently the Fortran test suite does not run with armflang because the
compiler detection fails. This in turn means fortran_runto_main does not
know which main method to use to start a test case.
Fortran compiler detection was added in 44d469c5f85; however, the commit
message notes that it was not tested with armflang.
This commit tests and fixes up a minor issue to get the detection
working.
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
>From what I can understand, the auto detection leverages the
preprocessor to extract the Fortran compiler identity from the defines.
This preprocessor output is then evaluated by the test suite to import
these defines.
In the case of armflang, this evaluation step is disrupted by the
presence of the following warning:
$ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
$ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
The evaluation logic is already set up to filter this warning, but the
prefix differs.
This commit fixes the issue by updating the filter to exclude the
armflang flavour of warning.
gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
regressions detected.
The gdb.fortran test results with ACfL 23.04.1 are as follows.
Before:
# of expected passes 560
# of unexpected failures 113
# of unresolved testcases 2
# of untested testcases 5
# of duplicate test names 2
After:
# of expected passes 5388
# of unexpected failures 628
# of known failures 10
# of untested testcases 8
# of unsupported tests 5
# of duplicate test names 5
As can be seen from the above, there are now considerably more passing
assertions.
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Tom Tromey <tom@tromey.com>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.