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

[Andrew Senkevich <andrew dot n dot senkevich at gmail dot com>]

2016-02-17 20:17 GMT+03:00 Joseph Myers <joseph@codesourcery.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.)

I didn't see libgomp dependency.  I stay -fopenmp only for new tests.

Is attached version finally Ok for trunk?


--
WBR,
Andrew

Attachment: bz19590_v3.1.patch
Description: Binary data