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: Wed, 17 Feb 2016 17:17:01 +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> <alpine dot DEB dot 2 dot 10 dot 1602111641250 dot 29940 at digraph dot polyomino dot org dot uk> <CAMXFM3uxH=0DHnwikPjs2AobQ0kxOqKg+j=CuOWX=RLB_i8hxg at mail dot gmail dot com> <CAMe9rOoWy+hqiCOKqFx0nOFVRT_kBETJ5hYE+cY6pFWUke=tkw at mail dot gmail dot com> <CAMXFM3vG1DNELfGaOOoUvRDGgrGWL4m3M8+5ngPg8RPnCLqUog at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602161347240 dot 26462 at digraph dot polyomino dot org dot uk> <CAMXFM3tXQi0wRFNN1gyu-T3C7g_EWPxMfhK4wexADGtcPojNZg at mail dot gmail dot com>
On Wed, 17 Feb 2016, Andrew Senkevich wrote:
> 2016-02-16 16:49 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> > On Tue, 16 Feb 2016, Andrew Senkevich wrote:
> >
> >> Here is patch with tests.
> >
> > This is the wrong approach for tests. Tests for this should not be
> > testing implementation details about aliases, and so should not be
> > creating any wrappers at all. They should be testing vectorizable calls
> > to the scalar functions, compiled several times with different options
> > into both executables and shared libraries.
>
> Please look at attached version.
I'm concerned about the change to use -fopenmp in libm-test-vec-cflags.
That's deliberately using defines to cause declarations to be visible
rather than other options such as -ffast-math that might have undesired
side effects.
(In this case, would it introduce any libgomp dependencies? If libgomp
needs copying to the glibc build directory for testing like libgcc_s and
libstdc++ do, in cases where it's not available in a directory searched by
default, that's a significant change to testing requirements that would
need to be carefully thought out. If -fopenmp is only used when compiling
and not when linking and there are no libgomp dependencies involved, it
may be safer, but it still needs careful consideration and testing and so
is unsuitable so close to a release. And it would seem best in any case
to use -fopenmp if needed only for the new tests, not for the ones using
wrappers.)
The tests also seem to fail to follow the GNU Coding Standards in various
places, such as regarding spaces before '(' and putting function names at
the start of a new line in function definitions.
--
Joseph S. Myers
joseph@codesourcery.com