[Bug math/28481] New: Glibc "--disable-mathvec" configure option fail to disable traces to libmvec

[Bug math/28481] New: Glibc "--disable-mathvec" configure option fail to disable traces to libmvec

[haochen.jiang at intel dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28481

            Bug ID: 28481
           Summary: Glibc "--disable-mathvec" configure option fail to
                    disable traces to libmvec
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

When I build Glibc with "--disable-mathvec" and run through this simple
testcase in fortran: 

program test_overloaded_intrinsic
  real(4) :: x4(3200), y4(3200)
  real(8) :: x8(3200), y8(3200)

  y4 = sin(x4)
  print *, y4
end

It reports error: undefined reference to `_ZGVeN8v_sin'

Also for c, it has the same error using similar simple testcase in c. It is
trying to find libmvec functions, while because of the disabling, libmvec.so
will not be generated.

When I go through gcc file. In gcc/config/gnu-user.h Line 156, we have:

#undef TARGET_F951_OPTIONS
#define TARGET_F951_OPTIONS "%{!nostdinc:\
  %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"

, which is maybe the cause of the error for fortran. Because when I clear that
math-vector-fortran.h, the testcase will pass, which means glibc did not tell
gcc to exclude that file under "--disable-mathvec" option.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28481] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28481

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
A remark on what the ideal approach for fixing this should be:

Installed headers don't normally depend on how glibc is configured, except 
for the chosen ABI, but in this case some such dependency is needed.  It's 
also possible for a set of installed headers to be shared between multiple 
ABIs, each with glibc built separately, and bits/math-vector.h and 
finclude/math-vector-fortran.h duly contain conditionals to reflect that 
mathvec functionality is supported for x86_64 (both 64-bit and x32 ABIs) 
but not for i386.

In principle, someone could build x86_64 glibc with libmvec and x32 glibc 
without and have them using the same installed headers.  To me, this 
suggests having another generated installed header using the same logic as 
for gnu/lib-names.h and gnu/stubs.h: there is a wrapper header, which 
contains conditionals to include the appropriate ABI-specific header.  
And the ABI-specific header, say gnu/mathvec.h, would define e.g. 
__LIBMVEC_ENABLED to 0 or 1, and be included by bits/math-vector.h to 
provide an additional conditional for whether the functionality is 
available.  Only the generated ABI-specific header would depend on how 
glibc was configured.

However, I don't know if this would work for the Fortran case: whether 
such a structure with an ABI-specific header that might depend on how 
glibc was configured, and an ABI-independent header that doesn't, can be 
used in for Fortran.  If it won't work for Fortran, maybe you need to fall 
back to the simpler but less general approach of using different sysdeps 
directories, and thus different versions of the installed 
finclude/math-vector-fortran.h, depending on whether --disable-mathvec is 
used (but still trying to get i386 glibc with default configure options to 
install a version suitable for use with x86_64 glibc with default 
configure options).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28481] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28481

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.