Hi everybody,
I have done the minimum to make the testsuite failures to go
away(thanks, Jakub) and to fix the first (offline) reported bug.
Committed as r267946.
As to the location of ISO_Fortran_binding_2.h, I am open to proposed
fixes. Thomas kindly engineered that part of the original patch since
I have tried to keep my nose out of the configure side of things.
Regards
Paul
2019-01-15 Paul Thomas <pa...@gcc.gnu.org>
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Deal with exprs
that are indirect references; ie. dummy arguments.
2019-01-15 Paul Thomas <pa...@gcc.gnu.org>
* gfortran.dg/ISO_Fortran_binding_2.c : Change reference to
ISO_Fortran_binding_2.h.
On Tue, 15 Jan 2019 at 08:02, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Jan 15, 2019 at 08:05:59AM +0100, Richard Biener wrote:
> > >It either should
> > >#include "../../../libgfortran/ISO_Fortran_binding.h"
> > >instead or the Fortran *.exp files should arrange for
> > >-I.../libgfortran/
> > >to be added to all gfortran tests. Because right now it FAILs if you
> > >don't
> > >have ISO_Fortran_binding.h header installed, or succeeds, but includes
> > >header from some other compiler version or even other compiler
> > >altogether.
>
> This still needs to be fixed.
>
> > >Where is that header installed BTW?
> > >Would be best if it got installed in directories like:
> > >$prefix/lib/gcc/$target/$version/include
> > >
> > >See e.g. libssp or libsanitizer, both have something like
> > >target_noncanonical = @target_noncanonical@
> > >libsubincludedir =
> > >$(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include
> > >nobase_libsubinclude_HEADERS = ssp/ssp.h ssp/string.h ssp/stdio.h
> > >ssp/unistd.h
> > >
> > >You probably want it to go directly in the include dir, so without the
> > >ssp/
> > >or whatever else prefixes.
> >
> > It's there, but also in the multilib locations (which is dubious? Not sure
> > if we ever search tose include paths)
>
> Yeah, for -m32 it is in
> .../lib/gcc/x86_64-pc-linux-gnu/9.0.0/32/include/
> which isn't that useful; while the finclude/ in there is needed, because
> those are target specific, this header is the same and so it could be
> just in .../9.0.0/include/ always (like e.g. the std*.h headers, intrinsics
> etc.).
>
> Jakub
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
