[Bug math/19058] New: [x86_64] Link fail with -fopenmp and -flto

[Bug math/19058] New: [x86_64] Link fail with -fopenmp and -flto

[andrew.n.senkevich at gmail dot com]

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

            Bug ID: 19058
           Summary: [x86_64] Link fail with -fopenmp and -flto
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: andrew.n.senkevich at gmail dot com
  Target Milestone: ---

-bash-4.2$ cat test.c
#include <math.h>
#define size 4096
double x[size];
double y[size];

__attribute__((noinline))
int foo()
{
  int i;

#pragma omp simd
  for (i = 0; i < size; i++)
    {
      x[i] = log(y[i]);
    }

  return (int) x[0];
}

int main()
{
  int i = 0;

  for (i = 0; i < size; i++)
    {
      y[i] = sin(i);
    }

  return (foo());
}

-bash-4.2$ gcc test.c -I/GLIBC_2.22_install/include/ -
L/GLIBC_2.22_install/lib/ -O1 -fopenmp -ffast-math -lm -flto
-flto-partition=max -save-temps
/tmp/ccLnEA3M.ltrans1.ltrans.o: In function `foo':
<artificial>:(.text+0xf): undefined reference to `_ZGVbN2v___log_finite'
collect2: error: ld returned 1 exit status

Asm aliases _ZGV*N*v___log_finite = _ZGV*N*v_log are not enough for build with
-flto because alias and call can be placed in different LTO units:

-bash-4.2$ grep _ZGVbN2v___log_finite *ltrans*
ccRWvqdW.ltrans0.s:     _ZGVbN2v___log_finite = _ZGVbN2v_log
ccRWvqdW.ltrans1.s:     call    _ZGVbN2v___log_finite

GCC version >= 4.9.0
Discussion about these aliases addition:
https://sourceware.org/ml/libc-alpha/2015-06/msg00213.html

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

[Bug math/19058] [x86_64] Link fail with -fopenmp and -flto

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich <andrew.n.senkevich at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |andrew.n.senkevich at gmail dot co
                   |                            |m

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

[Bug math/19058] [x86_64] Link fail with -fopenmp and -flto

[kirill.yukhin at intel dot com]

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

Kirill Yukhin <kirill.yukhin at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |kirill.yukhin at intel dot com

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

[Bug math/19058] [x86_64] Link fail with -fopenmp and -flto

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I think you need to follow up on the compiler discussion of interfaces to 
avoid needing to remap the _finite name at all.  That is, the discussion 
starting at <https://gcc.gnu.org/ml/gcc/2015-06/msg00173.html>.  I don't 
see any replies from you to that thread at all.  You need to take an 
active role for as long as needed in developing consensus on appropriate 
interfaces and getting them implemented, not just start the thread.

As a glibc-based workaround for compilers without a fix, maybe you also 
need libmvec_nonshared.a with wrappers for the _finite names (that just 
jump to the functions with the preferred names) if the asms don't suffice 
in all cases?  The shared library ABI should be kept to the minimum 
needed.  libmvec_nonshared.a would be referenced from the libm.so linker 
script (and its contents would also be in libmvec.a so that users linking 
statically never need to do -lmvec_nonshared).  I think adding functions 
to libmvec-static-only-routines should do what you want (you also need to 
update the code generating the libm.so linker script).

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