This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [C++ Patch] for c++/54537
- From: Fabien ChÃne <fabien dot chene at gmail dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, libstdc++ at gcc dot gnu dot org
- Date: Fri, 12 Jul 2013 11:53:12 +0200
- Subject: Re: [C++ Patch] for c++/54537
- References: <CAFH4-dhvTpRyzTNpieNnZ=VMDcRE7+wikB4pk3dadFSNs0BK8g at mail dot gmail dot com> <504D3146 dot 8070108 at redhat dot com> <CAFH4-dgOgUEgzumgy891xVUieU2vugGxw2=_-_ezdpfXzZV7RQ at mail dot gmail dot com> <CAFH4-dhcjdoYkxb7gLygQBwv9S02Lue9zoRFE0SBLwemLAc-uQ at mail dot gmail dot com> <ff93ce3c-2523-42b9-b801-96e667058527 at email dot android dot com> <CAFH4-dhNT8LsqTBuQkRJO9HA+CAbmqQ44OA6PAUusWcn2cWoVg at mail dot gmail dot com> <a0f17889-3346-4ae9-80c6-28e7e5361f73 at email dot android dot com> <5058FFC4 dot 4020905 at oracle dot com> <50590293 dot 7050904 at oracle dot com> <50590676 dot 4090705 at oracle dot com> <CAFH4-dgRJz5+i4UxRSmGNXkKe6fKLq8Yezw5tosmHjA8tiw7DQ at mail dot gmail dot com> <505A1002 dot 3040200 at oracle dot com> <CAFH4-dj3ZQqhrJ93rxMg_z4eZryKRH+j_jsZ7_cX5Wx9E1BGGA at mail dot gmail dot com> <50A4099F dot 1080409 at oracle dot com> <50A40A7B dot 30809 at redhat dot com> <CAFH4-dgycCh=JbQ3MSnHE86FQ=bUjEQZdT8-h5371cwzQkQh0g at mail dot gmail dot com> <50A50028 dot 7060303 at redhat dot com> <CAFH4-dimUUJvcSQ5LGhghzGcUPibxvCEKmXWd-+aE0VRcpDocA at mail dot gmail dot com> <519D9CD9 dot 1000107 at redhat dot com>
Hi,
2013/5/23 Jason Merrill <jason@redhat.com>
>
> On 05/22/2013 04:53 PM, Fabien ChÃne wrote:
>>
>> Ah, I see, it works. Then we end up with three solutions:
>> 1) remove the pow(double,double) overload
>> 2) add a specialization template <> pow(double,double)
>> 3) add an extern "C" declaration to refer to the C library function
>>
>> I don't have a strong preference, I would say that all solutions are
>> more or less equivalent. In the end, builtins are just reached in
>> different ways I guess, depending on the optimisations enabled.
>> Given that Paolo already OKed the solution 1), I would go for it.
>
>
> I guess #1 and #2 involve forwarding through a template, whereas #3 avoids that and might give cleaner code without optimization. But library design issues might be more important, so library folks should make the call here.
Saying that discussions are encouraged -- or even better a decision
--, is an understatement...
My opinion is that if #3 is the best choice, then it should not be
restricted to this case, and should be applied on all cases where
functions are forwarded through templates to builtins.
Then, It seems to me that such a change should ideally go in a separate patch.
Thank you.
--
Fabien