Re: [Mingw-w64-public] Patch for finally fix fesetenv
Something like this?
#include
#include
int main(void)
{
/* Compute 1.0/3.0 in default FPU mode */
volatile float somefloat = 1.0;
somefloat /= 3.0;
/* Output it in float and hex formats */
printf("%.9g\thex: %x\n", somefloat, *(int *));
fenv_t a, b;
fegetenv(); /* Save fpu env */
fesetround(FE_TOWARDZERO); /* Set round mode */
fesetenv(); /* Restore fpu env (round mode must also be restored) */
fegetenv(); /* Get current fpu env */
/* Compute 1.0/3.0 after changing and restoring fpu env */
volatile float somefloat2 = 1.0;
somefloat2 /= 3.0;
/* Output it in float and hex formats */
printf("%.9g\thex: %x\n", somefloat2, *(int *));
/* Output FPU control words */
printf ("FPU control words: %x, %x\n", a.__control_word, b.__control_word);
return 0;
}
Output for incorrect work of fesetenv:
0.33343 hex: 3eab
0.33313 hex: 3eaa
FPU control words: 37f, f7f
For correct work output :
0.33343 hex: 3eab
0.33343 hex: 3eab
FPU control words: 37f, 37f
чт, 7 мар. 2019 г. в 21:50, Liu Hao :
>
> 在 2019/2/25 22:41, Liu Hao 写道:
> > 在 2019/2/25 19:27, Zidane Sama 写道:
> >> After this commit:
> >>
> >> [e98d80] (2.0 kB) by Kai Tietz
> >> Add a fix for working fesetenv in libquadmath-library
> >>
> >> fesetenv was broken and do not sets new fpu state because it's now
> >> overwrites new env state by fnstenv.
> >>
> >> And this patch must fix it by store only mxcsr and load its afterwards:
> >>
> >> diff --git a/mingw-w64-crt/misc/fesetenv.c b/mingw-w64-crt/misc/fesetenv.c
> >> index f998017b..07035c66 100644
> >> --- a/mingw-w64-crt/misc/fesetenv.c
> >> +++ b/mingw-w64-crt/misc/fesetenv.c
> >> @@ -66,8 +66,7 @@ int fesetenv (const fenv_t * envp)
> >> {
> >>fenv_t env = *envp;
> >>int _mxcsr;
> >> - __asm__ ("fnstenv %0\n"
> >> - "stmxcsr %1" : "=m" (*), "=m" (*&_mxcsr));
> >> + __asm__ ("stmxcsr %0" : "=m" (*&_mxcsr));
> >>/*_mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1;
> >> *//* mxcsr low and high */
> >>env.__unused0 = 0x;
> >>env.__unused1 = 0x;
> >>
> >>
> >>
> >
> > This seems a good catch.
> >
> > However I think the `STMXCSR` instruction should follow
> > `__mingw_has_sse()`, although CPUs without SSE are rare. I propose
> > another patch to address this issue.
> >
> >
> >
>
> Ping? Do you have any testcases related to this issue? Please notice
> that without any response we will not act on this.
>
>
> --
> Best regards,
> LH_Mouse
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patch for finally fix fesetenv
在 2019/2/25 22:41, Liu Hao 写道:
> 在 2019/2/25 19:27, Zidane Sama 写道:
>> After this commit:
>>
>> [e98d80] (2.0 kB) by Kai Tietz
>> Add a fix for working fesetenv in libquadmath-library
>>
>> fesetenv was broken and do not sets new fpu state because it's now
>> overwrites new env state by fnstenv.
>>
>> And this patch must fix it by store only mxcsr and load its afterwards:
>>
>> diff --git a/mingw-w64-crt/misc/fesetenv.c b/mingw-w64-crt/misc/fesetenv.c
>> index f998017b..07035c66 100644
>> --- a/mingw-w64-crt/misc/fesetenv.c
>> +++ b/mingw-w64-crt/misc/fesetenv.c
>> @@ -66,8 +66,7 @@ int fesetenv (const fenv_t * envp)
>> {
>>fenv_t env = *envp;
>>int _mxcsr;
>> - __asm__ ("fnstenv %0\n"
>> - "stmxcsr %1" : "=m" (*), "=m" (*&_mxcsr));
>> + __asm__ ("stmxcsr %0" : "=m" (*&_mxcsr));
>>/*_mxcsr = ((int)envp->__unused0 << 16) | (int)envp->__unused1;
>> *//* mxcsr low and high */
>>env.__unused0 = 0x;
>>env.__unused1 = 0x;
>>
>>
>>
>
> This seems a good catch.
>
> However I think the `STMXCSR` instruction should follow
> `__mingw_has_sse()`, although CPUs without SSE are rare. I propose
> another patch to address this issue.
>
>
>
Ping? Do you have any testcases related to this issue? Please notice
that without any response we will not act on this.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] ctime inline wrapper is also needed for msvcrt 0x1200
在 2019/3/7 17:45, Jacek Caban 写道: > Note that when doing 32-bit builds, _USE_32BIT_TIME_T will be most > likely defined so this code path will not be used. Currently (although > it might be improved in the future), one has to define > __MINGW_USE_VC2005_COMPAT to use 64-bit time_t, and it's the only config > that would break on XP. > > > Current code, instead of load failure, will call a function with wrong > arguments and will likely corrupt stack. I don't think that's something > we want to preserve. If we really want to support this case properly, > we'd need _mkgmtime64 compat implementation inside libmsvcrt.a. > > Indeed, the actual `ctime()` etc. exported from the DLL are always 32-bit or 64-bit, so we can't support both without tampering with the source code rather than the library. I pushed these three patches. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] ctime inline wrapper is also needed for msvcrt 0x1200
On 07/03/2019 03:22, Liu Hao wrote: 在 2019/3/7 上午5:11, Martin Storsjö 写道: On Wed, 6 Mar 2019, Jacek Caban wrote: It exists in msvcrt.dll that I checked (I think it's from win10). The patch looks good to me. _mkgmtime64 appeared in msvcrt.dll in Vista, it's missing in XP. // Martin I think it might be safer to keep the condition but have 0x1200 in place of 0x1400. Note that when doing 32-bit builds, _USE_32BIT_TIME_T will be most likely defined so this code path will not be used. Currently (although it might be improved in the future), one has to define __MINGW_USE_VC2005_COMPAT to use 64-bit time_t, and it's the only config that would break on XP. Current code, instead of load failure, will call a function with wrong arguments and will likely corrupt stack. I don't think that's something we want to preserve. If we really want to support this case properly, we'd need _mkgmtime64 compat implementation inside libmsvcrt.a. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
On Thu, Mar 7, 2019 at 10:30 AM Matthias Apitz wrote: > > Re/ crosscompiling: I'm used to do so on FreeBSD amd64 for x86 target, > but never compiled something on FreeBSD/Linux for Windows. use the mingw-w64 toolchain (sould be available in your freebsd distribution) i686-w64-mingw32-gcc, etc... for 32 bits x86_64-w64-mingw32-gcc, etc... for 64 bits Vincent Torri >The CPP files > here in question were written years ago with some Microsoft Visual > Studio (at least some artefacts around the CPP files say so). I think, > it's enough and easy to write some makefiles in addition and if I could > integrate this in our Jenkins CI on Linux this would be the finest solution. > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, > Druschba > instead of Nazis, to live instead of to survive. > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
El día Thursday, March 07, 2019 a las 09:36:28AM +0100, Vincent Torri escribió: > > Below is the (very short) list of missing pieces which I can't see on my > > Windows file system. > > > > Any ideas? > > - - > > -- > > [ ? ] LIBGCC_S_SEH-1.DLL Error opening file. > > Das System kann die angege > > [ ? ] LIBSTDC++-6.DLLError opening file. > > Das System kann die angege > > those 2 files are in your gcc installation directory. They must be > copied in the directory of your DLL > > > [D? ] API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL Error opening file. > > Das System kann die angege > > [D? ] API-MS-WIN-CORE-WINRT-L1-1-0.DLL Error opening file. > > Das System kann die angege > > [D? ] API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL Error opening file. > > Das System kann die angege > > [D? ] API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLLError opening file. > > Das System kann die angege > > [D? ] DCOMP.DLL Error opening file. > > Das System kann die angege > > [D? ] IESHIMS.DLLError opening file. > > Das System kann die angege > > these above should be part of Windows. > > normally you only need to copy the 2 above gcc dll where your dll is located. I've copied the following DLLs into the place where my DLL SiPrinter.dll is: -rwxr-xr-x+ 1 apitzm Domain Users 354545 7. Mrz 08:27 SiPrinter.dll -rwxr-xr-x+ 1 apitzm Domain Users 78848 7. Mrz 09:53 libgcc_s_seh-1.dll -rwxr-xr-x+ 1 apitzm Domain Users 1407488 7. Mrz 09:54 libstdc++-6.dll -rwxr-xr-x+ 1 apitzm Domain Users 53779 7. Mrz 09:58 libwinpthread-1.dll And this made the Java DLL loader happy. Thanks Re/ crosscompiling: I'm used to do so on FreeBSD amd64 for x86 target, but never compiled something on FreeBSD/Linux for Windows. The CPP files here in question were written years ago with some Microsoft Visual Studio (at least some artefacts around the CPP files say so). I think, it's enough and easy to write some makefiles in addition and if I could integrate this in our Jenkins CI on Linux this would be the finest solution. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
Personally I use PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/bin:$PATH" ldd DEADBEEF.exe which is not exactly what you would like but still better than simply launching ldd. чт, 7 мар. 2019 г. в 11:27, Matthias Apitz : > El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson > escribió: > > > Your experience matches mine: the Cygwin ldd utility does not work > properly > > with MinGW DLLs and prints a bunch of question marks. There is an ntldd > > utility you can use instead. If it's not on your path already, I'm not > > sure the best way to obtain it. I just use MSYS2, because it's > basically a > > fork of Cygwin that makes it easy to install MinGW compilers and all the > > other open source utilities you would need to build software on Linux, > > including ntldd. > > > > --David > > David, thanks for your reply. Does this mean I could move to a Linux system > with Mingw-w64 to produce the DLL for Windows there? This would be the > first > option as I do know less as nothing about Windows, but 30++ years about > UNIX :-) > > This also would allow to produce the DLL together with the Java software > on our Jenkins server hosted on Linux... > > Re/ my problem "Can't find dependent libraries." from the Java DLL loader, > I found > a thread in stackoverflow > > https://stackoverflow.com/questions/6092200/how-to-fix-an-unsatisfiedlinkerror-cant-find-dependent-libraries-in-a-jni-pro/6092576#6092576 > with a hint to a tool which analyses the DLL for missing dependencie (etc.) > Below is the (very short) list of missing pieces which I can't see on my > Windows file system. > > Any ideas? > > Thanks > > matthias > > $ cut -c1-100 short.txt > | Module List > |* > * > * > * Legend: D Delay Load Module ? Missing Module 6 64-bit > Module * > * * Dynamic Module ! Invalid Module > * > *E Import/Export Mismatch or Load > Failure * > * > * > > > >Module File Time Stamp > Link Time Stamp File Size > - - > -- > [ ? ] LIBGCC_S_SEH-1.DLL Error opening file. > Das System kann die angege > [ ? ] LIBSTDC++-6.DLLError opening file. > Das System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL Error opening file. > Das System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-L1-1-0.DLL Error opening file. > Das System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL Error opening file. > Das System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLLError opening file. > Das System kann die angege > [D? ] DCOMP.DLL Error opening file. > Das System kann die angege > [D? ] IESHIMS.DLLError opening file. > Das System kann die angege > [ 6] API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL 09.01.2019 04:06 > 09.01.2019 04:07 4.608 > [D 6] DWMAPI.DLL 09.07.2015 18:58 > 09.07.2015 18:53 82.944 > [DE6] ESENT.DLL 11.03.2011 07:33 > 11.03.2011 07:22 2.565.632 > ... > > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, > Druschba > instead of Nazis, to live instead of to survive. > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Байкалов Пётр ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
On 07.03.2019 11:26, Matthias Apitz wrote: > El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson > escribió: > >> Your experience matches mine: the Cygwin ldd utility does not work properly >> with MinGW DLLs and prints a bunch of question marks. There is an ntldd >> utility you can use instead. If it's not on your path already, I'm not >> sure the best way to obtain it. I just use MSYS2, because it's basically a >> fork of Cygwin that makes it easy to install MinGW compilers and all the >> other open source utilities you would need to build software on Linux, >> including ntldd. > > David, thanks for your reply. Does this mean I could move to a Linux system > with Mingw-w64 to produce the DLL for Windows there? This would be the first > option as I do know less as nothing about Windows, but 30++ years about > UNIX :-) > You must have heard of cross-compilation in all these 30++ years. Cross-compilation is less convenient than using MSYS (since you have to have buildsystem support, and be careful not to grab non-cross tools), but if you are the developer of the program(s) you are compiling, and know your way around autotools (or whatver buildsystem you're using) then it's perfectly doable. Though that's not what David meant. He meant using MSYS (MSYS2, specifically), which is, basically, Cygwin with serial numbers filed off a few small changes that allow developers to trivially mix native (GCC and binutils, specifically) and non-native (bash and perl, specifically, for autotools) programs on Windows for the purpose of compiling native Windows stuff. If you use Cygwin to build native Windows software, you're cross-compiling. So unless you need to do testing or do something else that involves running the stuff you compile right after you get it, there's no advantage in cross-compiling in Cygwin, as opposed to cross-compiling from Debian or somesuch (and even then, you can achieve that on Linux too, by using Wine, it's just more work than running Cygwin on Windows). signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
On Thu, Mar 7, 2019 at 9:27 AM Matthias Apitz wrote: > > El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson > escribió: > > > Your experience matches mine: the Cygwin ldd utility does not work properly > > with MinGW DLLs and prints a bunch of question marks. There is an ntldd > > utility you can use instead. If it's not on your path already, I'm not > > sure the best way to obtain it. I just use MSYS2, because it's basically a > > fork of Cygwin that makes it easy to install MinGW compilers and all the > > other open source utilities you would need to build software on Linux, > > including ntldd. > > > > --David > > David, thanks for your reply. Does this mean I could move to a Linux system > with Mingw-w64 to produce the DLL for Windows there? This would be the first > option as I do know less as nothing about Windows, but 30++ years about > UNIX :-) > > This also would allow to produce the DLL together with the Java software > on our Jenkins server hosted on Linux... > > Re/ my problem "Can't find dependent libraries." from the Java DLL loader, I > found > a thread in stackoverflow > https://stackoverflow.com/questions/6092200/how-to-fix-an-unsatisfiedlinkerror-cant-find-dependent-libraries-in-a-jni-pro/6092576#6092576 > with a hint to a tool which analyses the DLL for missing dependencie (etc.) dependency walker is a very nice tool too. > Below is the (very short) list of missing pieces which I can't see on my > Windows file system. > > Any ideas? > - - > -- > [ ? ] LIBGCC_S_SEH-1.DLL Error opening file. Das > System kann die angege > [ ? ] LIBSTDC++-6.DLLError opening file. Das > System kann die angege those 2 files are in your gcc installation directory. They must be copied in the directory of your DLL > [D? ] API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL Error opening file. Das > System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-L1-1-0.DLL Error opening file. Das > System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL Error opening file. Das > System kann die angege > [D? ] API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLLError opening file. Das > System kann die angege > [D? ] DCOMP.DLL Error opening file. Das > System kann die angege > [D? ] IESHIMS.DLLError opening file. Das > System kann die angege these above should be part of Windows. normally you only need to copy the 2 above gcc dll where your dll is located. Vincent Torri > [ 6] API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL 09.01.2019 04:06 > 09.01.2019 04:07 4.608 > [D 6] DWMAPI.DLL 09.07.2015 18:58 > 09.07.2015 18:53 82.944 > [DE6] ESENT.DLL 11.03.2011 07:33 > 11.03.2011 07:22 2.565.632 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson escribió: > Your experience matches mine: the Cygwin ldd utility does not work properly > with MinGW DLLs and prints a bunch of question marks. There is an ntldd > utility you can use instead. If it's not on your path already, I'm not > sure the best way to obtain it. I just use MSYS2, because it's basically a > fork of Cygwin that makes it easy to install MinGW compilers and all the > other open source utilities you would need to build software on Linux, > including ntldd. > > --David David, thanks for your reply. Does this mean I could move to a Linux system with Mingw-w64 to produce the DLL for Windows there? This would be the first option as I do know less as nothing about Windows, but 30++ years about UNIX :-) This also would allow to produce the DLL together with the Java software on our Jenkins server hosted on Linux... Re/ my problem "Can't find dependent libraries." from the Java DLL loader, I found a thread in stackoverflow https://stackoverflow.com/questions/6092200/how-to-fix-an-unsatisfiedlinkerror-cant-find-dependent-libraries-in-a-jni-pro/6092576#6092576 with a hint to a tool which analyses the DLL for missing dependencie (etc.) Below is the (very short) list of missing pieces which I can't see on my Windows file system. Any ideas? Thanks matthias $ cut -c1-100 short.txt | Module List |* * * * Legend: D Delay Load Module ? Missing Module 6 64-bit Module * * * Dynamic Module ! Invalid Module * *E Import/Export Mismatch or Load Failure * * * Module File Time Stamp Link Time Stamp File Size - - -- [ ? ] LIBGCC_S_SEH-1.DLL Error opening file. Das System kann die angege [ ? ] LIBSTDC++-6.DLLError opening file. Das System kann die angege [D? ] API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL Error opening file. Das System kann die angege [D? ] API-MS-WIN-CORE-WINRT-L1-1-0.DLL Error opening file. Das System kann die angege [D? ] API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL Error opening file. Das System kann die angege [D? ] API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLLError opening file. Das System kann die angege [D? ] DCOMP.DLL Error opening file. Das System kann die angege [D? ] IESHIMS.DLLError opening file. Das System kann die angege [ 6] API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL 09.01.2019 04:06 09.01.2019 04:07 4.608 [D 6] DWMAPI.DLL 09.07.2015 18:58 09.07.2015 18:53 82.944 [DE6] ESENT.DLL 11.03.2011 07:33 11.03.2011 07:22 2.565.632 ... -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
