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 lrn1...@gmail.com: 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
[Mingw-w64-public] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
Erik van Pienbroek schreef op za 31-01-2015 om 21:21 [+0100]: 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? Apparently gcc 5 is busted at the moment (20150125 snapshot, svn r220097) as it fails to build with this error: make[4]: Entering directory '/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp' /bin/sh ./libtool --tag=CC --mode=compile /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc -B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32 -I../../../libgomp/config/posix -I../../../libgomp -I../../../libgomp/../include -Wall -Werror -Wc,-pthread -g -O2 -MT target.lo -MD -MP -MF .deps/target.Tpo -c -o target.lo ../../../libgomp/target.c libtool: compile: /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc -B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/ -L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem /usr/i686-w64-mingw32/include -isystem /usr/mingw/include -B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem /usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32 -I../../../libgomp/config/posix -I../../../libgomp -I../../../libgomp/../include -Wall -pthread -Werror -g -O2 -MT target.lo -MD -MP -MF .deps/target.Tpo -c ../../../libgomp/target.c -DDLL_EXPORT -DPIC -o .libs/target.o ../../../libgomp/target.c: In function 'gomp_map_vars': ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] gomp_fatal (present clause: !acc_is_present (%p, ^ ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] ../../../libgomp/target.c:440:21: error: too many arguments for format [-Werror=format-extra-args] cc1: all warnings being treated as errors Makefile:613: recipe for target 'target.lo' failed make[4]: *** [target.lo] Error 1 make[4]: Leaving directory '/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp' The offending line contains this piece of code: gomp_fatal (present clause: !acc_is_present (%p, %zd (0x%zx)), (void *) k-host_start, size, size); I have no idea whether this is a gcc issue or a mingw-w64 one... -- 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] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
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. 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] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
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 0x922360B0.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] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
On 01.02.2015 1:02, Erik van Pienbroek wrote: Erik van Pienbroek schreef op za 31-01-2015 om 21:21 [+0100]: 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? Apparently gcc 5 is busted at the moment (20150125 snapshot, svn r220097) as it fails to build with this error: ../../../libgomp/target.c: In function 'gomp_map_vars': ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] gomp_fatal (present clause: !acc_is_present (%p, ^ ../../../libgomp/target.c:440:21: error: unknown conversion type character 'z' in format [-Werror=format=] ../../../libgomp/target.c:440:21: error: too many arguments for format [-Werror=format-extra-args] The offending line contains this piece of code: gomp_fatal (present clause: !acc_is_present (%p, %zd (0x%zx)), (void *) k-host_start, size, size); I have no idea whether this is a gcc issue or a mingw-w64 one... Could be a libgomp issue. GCC treats all functions attributed with format printf differently, depending on whether the target is W32 or not W32. For W32 it defaults to ms_printf, for non-W32 - gnu_printf. ms_printf doesn't support %z, gnu_printf does. This only affects format checking and is not directly related to the implementation of the printf function in question. This is what libgomp.h in 5.0 master says: extern void gomp_fatal (const char *, ...) __attribute__ ((noreturn, format (printf, 1, 2))); This defaults to ms_printf. The actual function called in the end is vfprintf, which could be from msvcrt (ms_printf-compatible) or libmingwex (gnu_printf-compatible) depending on whether __USE_MINGW_ANSI_STDIO is defined to 1 or not. (An aside: headers use the #if __USE_MINGW_ANSI_STDIO form, which may cause warnings in some gcc warning modes if __USE_MINGW_ANSI_STDIO is undefined. Consider fixing this). 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...). [1] https://stackoverflow.com/questions/15610053/correct-printf-format-specifier-for-size-t-zu-or-iu -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.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] GCC 5 build failure (Was: Re: Mass rebuild report for January 30 2015)
On 2/1/2015 06:02, Erik van Pienbroek wrote: The offending line contains this piece of code: gomp_fatal (present clause: !acc_is_present (%p, %zd (0x%zx)), (void *) k-host_start, size, size); I have no idea whether this is a gcc issue or a mingw-w64 one... It depends how gomp_fatal eventually calls *printf. If it calls the MS *printf, the warning is valid; if it calls the mingw-w64 *printf, the warning is false. Without adding __attribute__ hints, gcc isn't able to tell what kind of *printf function gomp_fatal is. 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
