[PATCH] msvcrt: Provide pow2 implementation in static library for msvcrt versions that don't provide it.
Signed-off-by: Jacek Caban jacek@codeweavers.com ---
This is needed because compiler may optimize pow(2,x) to exp2(x) and clang does that in out msvcp code. This also needs -fno-builtin because otherwise clang will optimize our forwarding implementation back to exp2.
Long term, when we will have those functions implemented in msvcrt without libc dependency anyway, we will probably want to provide the actual implementation in static library as well. I think it's better to revisit that later, after moving msvcrt to PE file.
dlls/msvcr100/Makefile.in | 2 ++ dlls/msvcr110/Makefile.in | 2 ++ dlls/msvcr120/Makefile.in | 2 ++ dlls/msvcr70/Makefile.in | 2 ++ dlls/msvcr71/Makefile.in | 2 ++ dlls/msvcr80/Makefile.in | 2 ++ dlls/msvcr90/Makefile.in | 2 ++ dlls/msvcrt/Makefile.in | 2 ++ dlls/msvcrt/mathf.c | 4 ++++ dlls/ucrtbase/Makefile.in | 2 ++ 10 files changed, 22 insertions(+)
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
This is needed because compiler may optimize pow(2,x) to exp2(x) and clang does that in out msvcp code. This also needs -fno-builtin because otherwise clang will optimize our forwarding implementation back to exp2.
If -fno-builtin works to prevent this, then why doesn't it already prevent it from happening in msvcp?
On 11/13/19 9:40 AM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
This is needed because compiler may optimize pow(2,x) to exp2(x) and clang does that in out msvcp code. This also needs -fno-builtin because otherwise clang will optimize our forwarding implementation back to exp2.
If -fno-builtin works to prevent this, then why doesn't it already prevent it from happening in msvcp?
It would, but we don't use -fno-builtin to build msvcp using cross compiler. We use it only when mingw is not available.
BTW, before I wrote this patch, I used CROSSCFLAGS=-fno-builtin-exp2 as a workaround (-fno-builtin-pow should do the trick as well), but I don't think we should go in that direction.
Jacek
Jacek Caban jacek@codeweavers.com writes:
On 11/13/19 9:40 AM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
This is needed because compiler may optimize pow(2,x) to exp2(x) and clang does that in out msvcp code. This also needs -fno-builtin because otherwise clang will optimize our forwarding implementation back to exp2.
If -fno-builtin works to prevent this, then why doesn't it already prevent it from happening in msvcp?
It would, but we don't use -fno-builtin to build msvcp using cross compiler. We use it only when mingw is not available.
Ah, right.
BTW, before I wrote this patch, I used CROSSCFLAGS=-fno-builtin-exp2 as a workaround (-fno-builtin-pow should do the trick as well), but I don't think we should go in that direction.
Maybe not, but having to add -fno-builtin in all the msvcrt makefiles doesn't seem that much better.
On 11/13/19 7:52 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
BTW, before I wrote this patch, I used CROSSCFLAGS=-fno-builtin-exp2 as a workaround (-fno-builtin-pow should do the trick as well), but I don't think we should go in that direction.
Maybe not, but having to add -fno-builtin in all the msvcrt makefiles doesn't seem that much better.
Yeah, that's not pretty. Maybe we could just apply -fno-builtin to all files with "makedep implib" pragma.
Long term I think we want an actual exp2 implementation inside static lib for msvcrt versions that don't export it from DLL. From what I heard from Piotr, the plan is to import math functions from some libc implementation and have them built inside msvcrt. Once we have that, it should be straightforward to add that to static libs as well. We may require additional CROSSCFLAGS meantime.
Thanks,
Jacek
-
Alexandre Julliard -
Jacek Caban