Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

[Sandra Loosemore <sandra@codesourcery.com>]

On 7/23/21 8:15 AM, Tobias Burnus wrote:
> Hi Sandra,
> 
> On 21.07.21 12:17, Tobias Burnus wrote:
>> On 13.07.21 23:28, Sandra Loosemore wrote:
>>> ISO_Fortran_binding.h is now generated in the libgfortran build
>>> directory where it is on the default include path.  Adjust includes in
>>> the gfortran testsuite not to include an explicit path pointing at the
>>> source directory.
>> ...
>>> -#include "../../../libgfortran/ISO_Fortran_binding.h"
>>> +#include "ISO_Fortran_binding.h"
>> Unfortunately, that does not help.
> 
> It seems as if the following works in the *.exp file:
> 
> # 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/"
> 
> I am not sure whether that should/can be added into
>    gfortran.dg/dg.exp
> or whether we only want to do this in
>    ts29113/ts29113.exp
> alias
>    c-interop/interop.exp
>    f18-c-interop/interop.exp
>    ...
> 
> That seems to work fine with -m32 and -m64.

Well, given that the original patch in this thread was for tests outside 
the ts29113 testsuite, any fix has to go someplace where those tests 
would pick it up too.

I'm not seeing the include path failures Tobias is seeing, so I can't 
confirm his change fixes them, either.  When I do "make check-fortran" 
in my build tree, it seems to be finding the include files because of 
there being a pile of -B options added to the gfortran command line.  I 
don't know where those are coming from, or why this isn't working for 
Tobias.  :-S

-Sandra