@@ -210,7 +210,6 @@ proc libgomp_target_compile { source dest type options } {
lappend options "additional_flags=[libio_include_flags]"
lappend options "timeout=[timeout_value]"
- lappend options "compiler=$GCC_UNDER_TEST"
set options [concat $libgomp_compile_options $options]
@@ -4,6 +4,7 @@ load_gcc_lib gcc-dg.exp
global shlib_ext
set shlib_ext [get_shlib_extension]
+#TODO
set lang_link_flags "-lstdc++"
set lang_test_file_found 0
set lang_library_path "../libstdc++-v3/src/.libs"
@@ -41,6 +42,11 @@ if { $blddir != "" } {
}
if { $lang_test_file_found } {
+ if ![info exists GXX_UNDER_TEST] then {
+ set GXX_UNDER_TEST $GCC_UNDER_TEST
+ }
+ lappend libgomp_compile_options "compiler=$GXX_UNDER_TEST"
+
# Gather a list of all tests.
set tests [lsort [glob -nocomplain $srcdir/$subdir/*.C]]
@@ -23,6 +23,8 @@ dg-init
# Turn on OpenMP.
lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
+lappend libgomp_compile_options "compiler=$GCC_UNDER_TEST"
+
# Gather a list of all tests.
set tests [lsort [find $srcdir/$subdir *.c]]
@@ -7,6 +7,7 @@ global ALWAYS_CFLAGS
set shlib_ext [get_shlib_extension]
set lang_library_path "../libgfortran/.libs"
+#TODO
set lang_link_flags "-lgfortran"
if [info exists lang_include_flags] then {
unset lang_include_flags
@@ -44,6 +45,11 @@ if { $blddir != "" } {
}
if { $lang_test_file_found } {
+ if ![info exists GFORTRAN_UNDER_TEST] then {
+ set GFORTRAN_UNDER_TEST $GCC_UNDER_TEST
+ }
+ lappend libgomp_compile_options "compiler=$GFORTRAN_UNDER_TEST"
+
# Gather a list of all tests.
set tests [lsort [find $srcdir/$subdir *.\[fF\]{,90,95,03,08}]]
@@ -48,6 +48,8 @@ dg-init
# Turn on OpenMP.
lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
+lappend libgomp_compile_options "compiler=$GCC_UNDER_TEST"
+
# Gather a list of all tests.
set tests [lsort [find $srcdir/$subdir *.c]]
Hi! No matter whether it's C, C++, or Fortran source code, the libgomp testsuite always uses (for build-tree testing) gcc/xgcc, or (for installed testing) GCC_UNDER_TEST. It doesn't make use of GXX_UNDER_TEST, GFORTRAN_UNDER_TEST. To support the latter two languages' needs, some -l[...] flags are then added via lang_link_flags. For example, for Fortran this is -lgfortran. This is, however, not what would happen if using the gfortran driver to build (which is what a user would be doing -- which we should replicate as much as possible at least for installed testing): the gfortran driver also adds -lquadmath, if applicable. Now, I wonder why to re-invent all that in the libgomp testsuite, if the respective driver already has that knowledge, via spec files, for example? (Also, the regular GCC compiler tests, gcc/testsuite/, are doing the right thing.) Why is libgomp testsuite implemented this way -- just a legacy of the past, or is there a need for that (that I'm not seeing)? Maybe the question also is: why isn't the libgomp testsuite using more of the infrastructure for specific languages, that is already implemented in gcc/testsuite/lib/? (That is, why does libgomp have to use libgomp_target_compile, instead of [language]_target_compile, for example.) And maybe that problem also applied to additional target libraries' testsuites; I have not yet looked. Anyway, here is a prototype patch to describe how I began to address this for the issue I stumbled upon, which is that the linker complained: Executing on host: x86_64-none-linux-gnu-gcc [...]/libgomp/testsuite/libgomp.fortran/aligned1.f03 [...] -fopenmp -O0 -fopenmp -fcray-pointer -lgfortran -lm -o ./aligned1.exe (timeout = 300) [...]/ld: warning: libquadmath.so.0, needed by [...]/libgfortran.so, not found (try using -rpath or -rpath-link) [...]/libgfortran.so: undefined reference to `logq@QUADMATH_1.0' [...] (That goes away if I add -lquadmath to the command line, but that's not the point I'm making here.) Am I on the right track with the following? Grüße, Thomas