This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] BZ #19590: Fixed build of shared objects that use libmvec.so functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 11 Feb 2016 16:43:13 +0000
- Subject: Re: [PATCH] BZ #19590: Fixed build of shared objects that use libmvec.so functions
- Authentication-results: sourceware.org; auth=none
- References: <CAMXFM3tML81iuKQMKRU-T4Fw0+=sYk0q_BNavMGagt21VcYvzQ at mail dot gmail dot com> <CAMe9rOp7BF2avdWbGTbsxuYQV_rmXSxzDUAwz+nHK-GhWqPKJA at mail dot gmail dot com> <CAMXFM3sG90jn3Em-REfaqtj3OGAjh51OcO=yn1qHqJ4aStkPrg at mail dot gmail dot 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. 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).
--
Joseph S. Myers
joseph@codesourcery.com