Re: [Mingw-w64-public] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
This is for sure a gcc-bug. Could you report issue to gcc's bz? Thanks in advance. Well, the fourth variant is to add for non-gnu-printf (or in general for _WIN32 defining hosts) the diagnostic print, or alter it to something not using gnu-ish printf-formatters. Regards, Kai 2015-02-01 3:51 GMT+01:00 LRN : > On 01.02.2015 4:21, JonY wrote: >> On 2/1/2015 08:56, LRN wrote: >>> Possible fixes: >>> A) Make "%z" the primary, fix libgomp (gcc) to explicitly decorate >>> gomp_fatal and gomp_fatal_va as gnu_printf. When compiled without a >>> gnu-compatible vfprintf, it will behave incorrectly at runtime, when a gmp >>> error happens. >>> B) Make printf the primary, fix libgomp (gcc) to use different format >>> strings depending on the host. According to [1], the right format for >>> size_t for MS CRT is "Iu". This could be a configure-time check, compile a >>> bunch of test programs with different format strings for size_t with >>> -Werror, see which one works. >>> C) Force libgomp to be compiled with __USE_MINGW_ANSI_STDIO defined to 1. >>> This might not sit well with non-mingw SDKs that compile gcc (sounds >>> weird...). >>> >> >> I think the last option is the path of least resistance, make >> configure.ac check if mingw* host and then use __USE_MINGW_ANSI_STDIO if so. > > Now that i'm thinking of it, this will probably not fix the warning. It will > guarantee that libgomp works correctly at runtime by ensuring that mingw-w64 > printf implementation is used, but compile-time format check is determined by > the printf format attribute of the function, and i doubt that gcc is smart > enough to figure out that the implementation is gnu-compatible. So (C) will > have to be combined with (A) for the warning to go away. > > -- > O< ascii ribbon - stop html email! - www.asciiribbon.org > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mass rebuild report for January 30 2015
> > OK, will go ahead with v4.0.0 shortly if there are no objections. I'm trying to get d3d11 idl additions into wine atm which jacek will pull into mingw-w64. VLC needs this for the new dx11-vout. Would it be possible to hold off a day or two for this ? On Sat, Jan 31, 2015 at 8:21 PM, Erik van Pienbroek wrote: > JonY schreef op za 31-01-2015 om 20:35 [+0800]: > > On 1/30/2015 08:10, Erik van Pienbroek wrote: > > > > > > All in all I see no blocking issues in mingw-w64 v4.0rc1. > > > > OK, will go ahead with v4.0.0 shortly if there are no objections. > > Is there still interest in doing another test mass rebuild against the > latest gcc 5 snapshot before releasing mingw-w64 v4.0? > > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mass rebuild report for January 30 2015
On 2/2/2015 03:27, Martell Malone wrote: >> >> OK, will go ahead with v4.0.0 shortly if there are no objections. > > I'm trying to get d3d11 idl additions into wine atm which jacek will pull > into mingw-w64. > VLC needs this for the new dx11-vout. > Would it be possible to hold off a day or two for this ? OK. 0xD4EBC740.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gfortran, open mp and floating point precision
Hi Pieter! This could be complete misinformation, or correct but not relevant. On Thu, Jan 15, 2015 at 12:57 PM, wrote: > I wrote a test program in fortran and used gfortran 4.9.2 (tdm64-gcc 4.9.2) > ... > However for extended floating point precision off-diagonal elements of the > identity matrix for thread 0 are <> 0 with the expected magnitude, for > threads 1 to 3 they are a factor 1000 (!) larger and moreover identical to > those of the identity matrix in the double floating point precision > calculation. > ... > Where is the error? I have a vague recollection of a discussion (probably on this list) about start-up code writing the Intel x87 floating-point control word to the floating-point processor. This was maybe something about setting a mode where extended precision (80-bit) was degraded to double precision (64-bit). If any of this is right (and not just a figment of my imagination), there was some talk of the floating-point control word start-up code getting called at thread start-up, so that even if your own initialization code in your main thread wrote the desired floating-point control word (e.g., to enable extended precision), this setting would not apply to other threads because they would get initialized with some default control word (hypothetically setting those threads to non-extended double precision). Again, this is a long shot, but I do seem to recall some discussion of floating-point control word start-up code from a month or two ago. > With regards > Pieter Bedijn - retired scientist and software developer Good luck. K. Frank -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
