install location of math-vector-fortran.h

install location of math-vector-fortran.h

[Matthias Klose]

[not subscribed to the libc-alpha list]

GCC and glibc need to agree on the install location for math-vector-fortran.h.
Currently it is installed into

  /usr/include/finclude/math-vector-fortran.h

However the file is architecture specific, currently only having variants for
x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.  This creates problems
when the file is contained in a Debian package which is marked as Multi-Arch:
same, also it should create problems installing the i386 and amd64 rpm's  on the
the same system.  How to solve this issue?

 - The header file currently seems to be completely conditionalized.
   Is it safe to assume that the x86 variant is still considered empty
   for any other architecture?  Will it stay this way?  In this case
   this variant could be installed everywhere, or better, glibc could
   stop maintaining the variant at all.

 - Move the file to an architecture specific location.  For multiarch that
   could be

     /usr/include/<multiarch>/finclude/math-vector-fortran.h

   GCC would need patching to look at this location as an alternative.
   Are other tools need patching as well?  What would be the
   solution for co-installable i386/amd64 packages?

Thanks, Matthias

Re: install location of math-vector-fortran.h

[Florian Weimer]

* Matthias Klose:

> [not subscribed to the libc-alpha list]
>
> GCC and glibc need to agree on the install location for math-vector-fortran.h.
> Currently it is installed into
>
>   /usr/include/finclude/math-vector-fortran.h
>
> However the file is architecture specific, currently only having
> variants for x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.
> This creates problems when the file is contained in a Debian package
> which is marked as Multi-Arch: same, also it should create problems
> installing the i386 and amd64 rpm's on the the same system.  How to
> solve this issue?

Uhm.  If you want an upstream solution, you need to upstream your
multi-arch patches.

>  - The header file currently seems to be completely conditionalized.
>    Is it safe to assume that the x86 variant is still considered empty
>    for any other architecture?  Will it stay this way?  In this case
>    this variant could be installed everywhere, or better, glibc could
>    stop maintaining the variant at all.

I do not understand these questions.  The Fortran header is the
equivalent of the <bits/math-vector.h> C header.  Its contents depends
on what is necessary to describe the libmvec ABI.  We will only know the
ABI for libmvec once there is a port for other architectures, so future
evolution of the header is impossible to predict.

Thanks,
Florian

Re: install location of math-vector-fortran.h

[Matthias Klose]

On 6/8/20 1:03 PM, Florian Weimer via Gcc wrote:
> * Matthias Klose:
> 
>> [not subscribed to the libc-alpha list]
>>
>> GCC and glibc need to agree on the install location for math-vector-fortran.h.
>> Currently it is installed into
>>
>>   /usr/include/finclude/math-vector-fortran.h
>>
>> However the file is architecture specific, currently only having
>> variants for x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.
>> This creates problems when the file is contained in a Debian package
>> which is marked as Multi-Arch: same, also it should create problems
>> installing the i386 and amd64 rpm's on the the same system.  How to
>> solve this issue?
> 
> Uhm.  If you want an upstream solution, you need to upstream your
> multi-arch patches.

they are in GCC.  Please note that there is no patch yet for this header file,
so I can't upstream anything yet.

>>  - The header file currently seems to be completely conditionalized.
>>    Is it safe to assume that the x86 variant is still considered empty
>>    for any other architecture?  Will it stay this way?  In this case
>>    this variant could be installed everywhere, or better, glibc could
>>    stop maintaining the variant at all.
> 
> I do not understand these questions.  The Fortran header is the
> equivalent of the <bits/math-vector.h> C header.  Its contents depends
> on what is necessary to describe the libmvec ABI.  We will only know the
> ABI for libmvec once there is a port for other architectures, so future
> evolution of the header is impossible to predict.

this file currently only has lines like:

!GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')

so it shouldn't have any effect to other architectures?  Or are the conditionals
explicitly done to exclude the 32bit x86 configuration?

Matthias

Re: install location of math-vector-fortran.h

[Florian Weimer]

* Matthias Klose:

> this file currently only has lines like:
>
> !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')
>
> so it shouldn't have any effect to other architectures?  Or are the
> conditionals explicitly done to exclude the 32bit x86 configuration?

Ah.  It's the latter.

Thanks,
Florian

Re: install location of math-vector-fortran.h

[Jakub Jelinek]

On Mon, Jun 08, 2020 at 12:52:36PM +0200, Matthias Klose wrote:
> GCC and glibc need to agree on the install location for math-vector-fortran.h.
> Currently it is installed into
> 
>   /usr/include/finclude/math-vector-fortran.h
> 
> However the file is architecture specific, currently only having variants for
> x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.  This creates problems
> when the file is contained in a Debian package which is marked as Multi-Arch:
> same, also it should create problems installing the i386 and amd64 rpm's  on the
> the same system.  How to solve this issue?
> 
>  - The header file currently seems to be completely conditionalized.
>    Is it safe to assume that the x86 variant is still considered empty
>    for any other architecture?  Will it stay this way?  In this case
>    this variant could be installed everywhere, or better, glibc could
>    stop maintaining the variant at all.
> 
>  - Move the file to an architecture specific location.  For multiarch that
>    could be
> 
>      /usr/include/<multiarch>/finclude/math-vector-fortran.h
> 
>    GCC would need patching to look at this location as an alternative.
>    Are other tools need patching as well?  What would be the
>    solution for co-installable i386/amd64 packages?

The file should be where gfortran looks for it.  For multi-arch, it is up to
you, that is a Debian/Ubuntu specific thing and if you get upstreamed
something into both glibc and gcc, fine.  But you could also just look for
where gfortran is looking for it ATM and pick up a more suitable location
for glibc.
For non-multiarch, I believe it works fine as is.

	Jakub

Re: install location of math-vector-fortran.h

[Joseph Myers]

On Mon, 8 Jun 2020, Matthias Klose wrote:

> However the file is architecture specific, currently only having variants for
> x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.  This creates problems
> when the file is contained in a Debian package which is marked as Multi-Arch:
> same, also it should create problems installing the i386 and amd64 rpm's  on the
> the same system.  How to solve this issue?

The general principle in glibc is that installed header files contain 
conditionals for variants within an architecture that can be used by a 
single GCC installation in a multilib configuration, most often for 32-bit 
and 64-bit variants, so that a single set of header files can be shared 
between such multilibs.  However, they do not generally contain 
conditionals for different target architectures (where "different" means 
different GCC ports - for example, Arm and AArch64 are different for this 
purpose) or target OSes, so in those cases separate sets of installed 
headers are needed for each architecture / OS.

Although most of the architecture-specific headers are in bits/ or sys/, 
this isn't the case for all of them (e.g. fpu_control.h and ieee754.h, as 
well as the case of finclude/math-vector-fortran.h that you've noted).  It 
would be possible to change some headers such as fpu_control.h and 
ieee754.h to have an architecture-independent wrapper round an 
architecture-specific file in bits/, but probably a separate directory 
such as finclude/ for Fortran files would still be appropriate.

-- 
Joseph S. Myers
joseph@codesourcery.com