On 7/26/21 2:13 PM, Sandra Loosemore wrote:
On 7/26/21 3:45 AM, Tobias Burnus wrote:

[snip]

PS: Still, it would be nice if the proper multi-lib ISO*.h could be found;
while it usually does not matter, it could do so in some cases.

I think I ought to fix this now instead of just sweeping it under the rug.  The suggestion you made previously to add

# Flags for finding libgfortran ISO*.h files.
if [info exists TOOL_OPTIONS] {
   set specpath [get_multilibs ${TOOL_OPTIONS}]
} else {
   set specpath [get_multilibs]
}
set options "-I $specpath/libgfortran/"

to the .exp files looks consistent with what I see elsewhere for adding things to the include path, so I will give it a try and see how it works.

Unfortunately, I could not get this to work. For installed-tree testing, this resulted in diagnostics about a nonexistent directory on the include path. In my i686-pc-linux-gnu build I was having other problems when I tried build-tree testing using

make check-gfortran RUNTESTFLAGS="--target-board=localhost/m64"

or similar variants of --target-board (it seemed to be ignoring all the xfails?) so I did not think that could be the way people who normally test in the build tree can be doing it. And when I tried a recipe like

make check-gfortran RUNTESTFLAGS="ts29113.exp --tool_opts='-m64'"

it found the ISO_Fortran_binding.h via the correct /64-specific path via a -B option, same as for installed-tree testing.

Since the patch was already approved without additional hacks to include file paths, I went ahead and pushed it as-is. If somebody can provide me with an exact recipe for reproducing failures to find the include file, I'll take another stab at it, but TBH this is far from my area of expertise. :-(

BTW, I can't find any documentation for what get_multilibs is supposed to do. It seems to be part of Dejagnu itself rather than the gcc test support?

-Sandra

Reply via email to