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

[Joseph Myers]

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