committed – Re: [Patch] testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] (was: Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite))

[Tobias Burnus]

Now committed as obvious as https://gcc.gnu.org/r12-2808-g527a1cf32c27a3fbeaf6be7596241570d864cc4c

Follow-up suggestions are welcome. To recap, it changes three things:

* In the testcases, update "..." to "<...>" for the include
* -I $specpath/libgfortran - to find the .h file in the build dir (for in-build-tree testing)
* Update GFORTRAN_UNDER_TEST

The first two are very obvious, the latter applies, when running DejaGNU with, e.g.,
--target_board=unix\{-m32,-m64\}".
Those two multilib configs use different libgfortran build dirs and, hence,
the $specpath/libgfortran differs (e.g. x86.../libgfortran + x86.../32/libgfortran).

That's fine, except that when gfortran_init sets GFORTRAN_UNDER_TEST. That only
happend when it was unset. That's fine, except for multilib test runs, it is not
updated when gfortran_init is called for the next multilib run. Thus, in that case
the previous settings are used. – For the discussion in this thread, this means the
wrong ISO_Fortran_binding.h is read.

Or in previous wording:

On 29.07.21 11:51, Tobias Burnus wrote:
> On 29.07.21 09:09, Jakub Jelinek wrote:
>> On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub Jelinek wrote:
>>> On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote:
>>>> gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305]
>>> Wouldn't it be better to do that in gcc/testsuite/lib/gfortran.exp
>>> to GFORTRAN_UNDER_TEST there next to
>>> -B$specpath/libgfortran/ ?
>
> I guess so – and that's what I did. However, I had to ensure that it
> gets reset otherwise it picks up the wrong header in multilib runs;
> this also affects the -B$specpath/libgfortran bit, but I think that
> makes sense.
>
>> Though, I guess we need that mostly for the C FE, so perhaps it needs
>> to go
>> at the start of additional_flags=, whether TEST_ALWAYS_FLAGS is empty or
>> not.
>
> For the main testsuite (gcc/testsuite/*fortran*/), I believe the patch
> above is sufficient as everything runs through GFORTRAN_UNDER_TEST.
>
> I am also inclined not to add flags to TEST_ALWAYS_FLAGS which then
> might get applied to other/pure C/C++ tests.
>
> Regarding libgomp: that one uses xgcc for the compilation. I don't
> really see a need to use the Fortran array descriptor from a C program
> in libgomp's testsuite. Thus, I am inclined to ignore libgomp.
> Otherwise, as libgomp does not gfortran_init and handles libraries
> separately, I think the code needs to be put into
> libgomp.*fortran/fortran.exp.
>
> Thoughts? Okay?

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
-------------- next part --------------
A non-text attachment was scrubbed...
Name: committed.diff
Type: text/x-patch
Size: 13687 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210809/5804cae7/attachment.bin>