* [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64
@ 2020-04-03 16:03 Paul E. Murphy
2020-04-03 19:04 ` Adhemerval Zanella
0 siblings, 1 reply; 4+ messages in thread
From: Paul E. Murphy @ 2020-04-03 16:03 UTC (permalink / raw)
To: libc-alpha
This prevents generating a second alias for __fmaieee128 when
compiling with ldouble == ieee128 redirects.
---
sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
index 7374a799af..ab0c4d03a8 100644
--- a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
+++ b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
@@ -18,6 +18,8 @@
#undef weak_alias
#define weak_alias(a, b)
+#undef strong_alias
+#define strong_alias(a, b)
#define __fmaf128 __fmaf128_ppc64
--
2.21.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64
2020-04-03 16:03 [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64 Paul E. Murphy
@ 2020-04-03 19:04 ` Adhemerval Zanella
2020-04-03 20:04 ` Paul E Murphy
0 siblings, 1 reply; 4+ messages in thread
From: Adhemerval Zanella @ 2020-04-03 19:04 UTC (permalink / raw)
To: libc-alpha
On 03/04/2020 13:03, Paul E. Murphy via Libc-alpha wrote:
> This prevents generating a second alias for __fmaieee128 when
> compiling with ldouble == ieee128 redirects.
I trying to pinpoint where exactly this strong_alias is being
issued, but fix make sense (since the idea is to just provide
a unique function to ifunc selection).+
> ---
> sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
> index 7374a799af..ab0c4d03a8 100644
> --- a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
> +++ b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
> @@ -18,6 +18,8 @@
>
> #undef weak_alias
> #define weak_alias(a, b)
> +#undef strong_alias
> +#define strong_alias(a, b)
>
> #define __fmaf128 __fmaf128_ppc64
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64
2020-04-03 19:04 ` Adhemerval Zanella
@ 2020-04-03 20:04 ` Paul E Murphy
2020-04-03 20:10 ` Adhemerval Zanella
0 siblings, 1 reply; 4+ messages in thread
From: Paul E Murphy @ 2020-04-03 20:04 UTC (permalink / raw)
To: libc-alpha, Adhemerval Zanella
On 4/3/20 2:04 PM, Adhemerval Zanella via Libc-alpha wrote:
>
>
> On 03/04/2020 13:03, Paul E. Murphy via Libc-alpha wrote:
>> This prevents generating a second alias for __fmaieee128 when
>> compiling with ldouble == ieee128 redirects.
>
> I trying to pinpoint where exactly this strong_alias is being
> issued, but fix make sense (since the idea is to just provide
> a unique function to ifunc selection).+
The aliasing macros for float128 are buried in indirection. Ultimately,
the macro libm_alias_float128_other_r_ldbl in
ldbl-128ibm-compat/libm-alias-float.h uses strong_alias.
>
>> ---
>> sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>> index 7374a799af..ab0c4d03a8 100644
>> --- a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>> +++ b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>> @@ -18,6 +18,8 @@
>>
>> #undef weak_alias
>> #define weak_alias(a, b)
>> +#undef strong_alias
>> +#define strong_alias(a, b)
>>
>> #define __fmaf128 __fmaf128_ppc64
>>
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64
2020-04-03 20:04 ` Paul E Murphy
@ 2020-04-03 20:10 ` Adhemerval Zanella
0 siblings, 0 replies; 4+ messages in thread
From: Adhemerval Zanella @ 2020-04-03 20:10 UTC (permalink / raw)
To: Paul E Murphy, libc-alpha
On 03/04/2020 17:04, Paul E Murphy wrote:
>
>
> On 4/3/20 2:04 PM, Adhemerval Zanella via Libc-alpha wrote:
>>
>>
>> On 03/04/2020 13:03, Paul E. Murphy via Libc-alpha wrote:
>>> This prevents generating a second alias for __fmaieee128 when
>>> compiling with ldouble == ieee128 redirects.
>>
>> I trying to pinpoint where exactly this strong_alias is being
>> issued, but fix make sense (since the idea is to just provide
>> a unique function to ifunc selection).+
>
> The aliasing macros for float128 are buried in indirection. Ultimately, the macro libm_alias_float128_other_r_ldbl in ldbl-128ibm-compat/libm-alias-float.h uses strong_alias.
Alright, LGTM then.
>
>>
>>> ---
>>> sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>>> index 7374a799af..ab0c4d03a8 100644
>>> --- a/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>>> +++ b/sysdeps/powerpc/powerpc64/le/fpu/multiarch/s_fmaf128-ppc64.c
>>> @@ -18,6 +18,8 @@
>>> #undef weak_alias
>>> #define weak_alias(a, b)
>>> +#undef strong_alias
>>> +#define strong_alias(a, b)
>>> #define __fmaf128 __fmaf128_ppc64
>>>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-04-03 20:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-03 16:03 [PATCH] powerpc64le/multiarch: don't generate strong aliases for fmaf128-ppc64 Paul E. Murphy
2020-04-03 19:04 ` Adhemerval Zanella
2020-04-03 20:04 ` Paul E Murphy
2020-04-03 20:10 ` Adhemerval Zanella
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).