BZ #19590: Fixed build of shared objects that use libmvec.so functions

  2016-02-11 19:43 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> On Thu, 11 Feb 2016, Andrew Senkevich wrote:
>
>> If we need runtime tests with calls to finite aliases it looks better
>> to adopt build of existing libmvec tests. We can call finite aliases
>> in *-wrappers.c and build shared library from them and link with it
>> test binaries. Is this approach looks OK?
>
> I don't think the finite aliases should be considered part of the API to
> test; it's an implementation detail of the header that they may get
> referenced in certain circumstances.

I agree.

>  The relevant thing to test is
> whether building a program that directly calls the scalar functions, with
> options such that the calls get vectorized, works (including with variant
> options for e.g. LTO).

But it looks more like compiler test, not library. Or do you mean some
ABI test for vector functions?
In any case is it necessary for this patch or the following patch is
Ok for thrunk?




--
WBR,
Andrew
  

On Thu, Feb 11, 2016 at 9:21 AM, Andrew Senkevich
<andrew.n.senkevich@gmail.com> wrote:
> 2016-02-11 19:43 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>> On Thu, 11 Feb 2016, Andrew Senkevich wrote:
>>
>>> If we need runtime tests with calls to finite aliases it looks better
>>> to adopt build of existing libmvec tests. We can call finite aliases
>>> in *-wrappers.c and build shared library from them and link with it
>>> test binaries. Is this approach looks OK?
>>
>> I don't think the finite aliases should be considered part of the API to
>> test; it's an implementation detail of the header that they may get
>> referenced in certain circumstances.
>
> I agree.
>
>>  The relevant thing to test is
>> whether building a program that directly calls the scalar functions, with
>> options such that the calls get vectorized, works (including with variant
>> options for e.g. LTO).
>
> But it looks more like compiler test, not library. Or do you mean some
> ABI test for vector functions?
> In any case is it necessary for this patch or the following patch is
> Ok for thrunk?
>
> diff --git a/ChangeLog b/ChangeLog
> index 11c3156..6ebcefb 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,9 @@
> +2016-02-10  Andrew Senkevich  <andrew.senkevich@intel.com>
> +           Carlos O'Donell  <carlos@redhat.com>
> +
> +       [BZ #19590]
> +       * sysdeps/x86_64/fpu/svml_finite_alias.S (ALIAS_IMPL): Use PLT.
> +
>  2016-02-04  Rajalakshmi Srinivasaraghavan  <raji@linux.vnet.ibm.com>
>
>         * sysdeps/powerpc/fpu/libm-test-ulps: Regenerated.
> diff --git a/sysdeps/x86_64/fpu/svml_finite_alias.S
> b/sysdeps/x86_64/fpu/svml_finite_alias.S
> index 0062fe4..8314cf4 100644
> --- a/sysdeps/x86_64/fpu/svml_finite_alias.S
> +++ b/sysdeps/x86_64/fpu/svml_finite_alias.S
> @@ -23,8 +23,7 @@
>
>  #define ALIAS_IMPL(alias, target) \
>  ENTRY (alias); \
> -       call target; \
> -       ret; \
> +       jmp target@PLT; \
>  END (alias)
>
>         .text
>

You need to a test to show your change fixes something.
  

On Thu, 11 Feb 2016, Andrew Senkevich wrote:

> >  The relevant thing to test is
> > whether building a program that directly calls the scalar functions, with
> > options such that the calls get vectorized, works (including with variant
> > options for e.g. LTO).
> 
> But it looks more like compiler test, not library. Or do you mean some

It's a library test (that inclusion of the header and making function 
calls works), not a compiler test.

> ABI test for vector functions?

No, what I suggest is entirely an API test (with variants for building a 
shared library instead of an executable, etc. - probably built several 
times with different vector instruction set options), not an ABI test.  
Testing the interfaces in the way that a normal user program would use 
them, i.e. via the normal math.h APIs in code that happens to be 
vectorizable.