On Wed, Jan 16, 2019 at 10:42:13AM +0100, Martin Liška wrote:
> On 1/15/19 6:45 PM, Joseph Myers wrote:
> > On Mon, 14 Jan 2019, Martin Liška wrote:
> >
> >> Thanks for review, fixed that in updated version of the patch.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >
> > This patch is OK.
> >
>
> Great, thank you very much for advises you provided.
>
> Now we should add the header file into glibc, I kicked a discussion here:
> https://sourceware.org/ml/libc-help/2018-11/msg00015.html
>
> Joseph: will you please help with a patch for glibc?
>
> I'm also planning to document the header file in gfortran so that other
> compiler can leverage that.
I'd like to raise a concern I have.
On IRC you've mentioned you'd like to see that header in
/usr/include/finclude/{,32/}math-vector-fortran.h
(with 32/ header being empty) which looks problematic to me.
The 32/ in there is the compiler's multilib suffix, which is though
dependent on how exactly one configures the compiler.
On x86_64-linux-gnu, one can either build (native) x86_64-pc-linux-gnu compiler
that defaults to -m64, supports -m32 and uses . and 32/ multilibs for those,
or one can build also native i686-pc-linux-gnu compiler (ideally with 32-bit
binutils too) that only supports -m32 and uses . multilib for the 32-bit.
If glibc installs the above, then if one uses the 32-bit i686-linux
gfortran, it will misbehave, as it will think glibc.i686 provides the
math-vector.h entrypoints when it doesn't.
Right now no other target supports them, but if say powerpc64-linux got
them, there one can build powerpc-linux gcc that supports -m32 and -m64
with . and 64/ multilib subdirs, or powerpc64-linux gcc that supports
-m64 and -m32 with . and 32/ multilib subdirs. So, what would
/usr/include/finclude/math-vector-fortran.h stand for in that case (again,
assuming the entry points are implemented in one of the multilibs only).
In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or
defined(__ILP64__) and similar, but in these headers we can't, as no
preprocessing is happening.
So, I think we need more multi-arch like setup for these locations, say
/usr/include/finclude/<target-triplet>{,<multisubdir>/}/
or similar which would be less ambiguous.
Jakub
