GCC Bugzilla – Bug 25502
I64d format Werror problem in build
Last modified: 2008-10-13 10:39:42 UTC
On i686-pc-mingw32, configuring with the following: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=$HOME/local --with-mpfr=$HOME/local --disable-libssp --disable-libmudflap --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as and running make gives: cc1.exe: warnings being treated as errors ../../gcc/gcc/tree-pretty-print.c: In function 'dump_bb_header': ../../gcc/gcc/tree-pretty-print.c:2267: warning: ISO C does not support the 'I' printf flag ../../gcc/gcc/tree-pretty-print.c:2267: warning: format '%I64d' expects type 'int', but argument 3 has type 'gcov_type' make: *** [tree-pretty-print.o] Error 1
Same problem for gcc/cfg.c, gcc/loop-unroll.c, gcc/loop-iv.c and others. Seems like a definition problem with HOST_WIDEST_INT_PRINT_DEC.
Would be caused by: 2005-08-23 Mark Mitchell <mark@codesourcery.com> * hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT. 2004-11-23 Mark Mitchell <mark@codesourcery.com> * hwint.h (HOST_LONG_LONG_FORMAT): New macro. Use it throughout. * config/i386/xm-mingw32.h (HOST_LONG_LONG_FORMAT): Define. * doc/hostconfig.texi (HOST_LONG_LONG_FORMAT): Document.
This was discussed after I posted the patch. The GCC format-checking stuff does not know about the Windows extensions. So, on MinGW, you should --disable-werror. This bug should be reclassified as a diagnostic bug; it's a limitation in the format checkers, not a bug in the macros.
(In reply to comment #3) > So, on MinGW, you should --disable-werror. I can understand the why, but I don't think it should be required (because that means other warnings will not be spotted). And anyway, it should at least be release-noted.
Subject: Re: Werror problem in build fxcoudert at gcc dot gnu dot org wrote: > ------- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-22 07:35 ------- > (In reply to comment #3) > >>So, on MinGW, you should --disable-werror. > > > I can understand the why, but I don't think it should be required (because that > means other warnings will not be spotted). There is no way around this; if you do not use the special Microsoft formats you will not get incorrect results; there are places where GCC must print a 64-bit integer, especially when configured with 64-bit HOST_WIDE_INTs, which is required for some targets. > And anyway, it should at least be release-noted. Good idea! Care to submit a patch for the caveats page?
By the way, x-mingw32 contains: # On MinGW, we use "%IA64d" to print 64-bit integers, and the format-checking # code does not handle that, so we have to disable checking here. WERROR_FLAGS += -Wno-format This should have fixed the problem, but it doesn't for some reason. See also: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02223.html (and the follow-up messages).
In my local tree (and in the 3.4.x mingw tree), I have added a modification and extension of this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02296.html I plan to follow up in stage 1 of 4.3 This patch silences the worst of the warnings. However, because of the -pedantic switch, I still get warnings like ../../gcc/gcc/gcov-dump.c:408: warning: ISO C does not support the 'I64' printf length modifier -Wno-pedantic-errors doesn't work for me, so --disable-werror is still necessary.
(In reply to comment #7) > I plan to follow up in stage 1 of 4.3 ping? There was a patch for %I64 proposed here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00767.html
*** Bug 32794 has been marked as a duplicate of this bug. ***
Still, 4.3.0 can't recoginze %I64d
(In reply to comment #10) > Still, 4.3.0 can't recoginze %I64d And that is because it is just being added: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html
(In reply to comment #11) > (In reply to comment #10) > > Still, 4.3.0 can't recoginze %I64d > > > And that is because it is just being added: > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html > Even with that patch, we still get "ISO C does not support the 'I64' printf length modifier" warnings because of --predantic. IMO, that warning is valid and useful and should not be "fixed". Danny
What would be an acceptable solution other than having bootstrap perpetually broken, and other than --disable-werror? 1) We could only enable this warning when in strict mode, eg -std=c99 -pedantic. -std=gnu99 -pedantic would not warn. This seems like it might be best. 2) Adding __extension__ will silence this warning. Should we make a macro to decorate these uses of HOST_WIDEST_INT_PRINT_DEC? 3) Worse case, can we just HOST_WIDEST_INT long?
Another question: why does "lld" not cause warnings on linux here? I don't see what the difference is. Whatever the situation is, I don't see any reason that "I64d" should behave differently from "lld" in gnu89 mode.
Subject: Re: Werror problem in build On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote: > ------- Comment #13 from aaronavay62 at aaronwl dot com 2008-05-11 03:04 ------- > What would be an acceptable solution other than having bootstrap perpetually > broken, and other than --disable-werror? You could disable -pedantic when bootstrapping on Windows hosts, or use -Wno-error=format, or make it possible to control these warnings separately with -Wno-error=format-pedantic. > 1) We could only enable this warning when in strict mode, eg -std=c99 > -pedantic. -std=gnu99 -pedantic would not warn. This seems like it might be > best. This isn't how the warning options are meant to work; I don't think we want yet more variations on when particular warnings are enabled.
Subject: Re: I64d format Werror problem in build On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote: > Another question: why does "lld" not cause warnings on linux here? I don't see > what the difference is. Whatever the situation is, I don't see any reason that > "I64d" should behave differently from "lld" in gnu89 mode. The difference is that "lld" is a standard C99 format and "I64d" isn't; -Wno-long-long disables warnings in gnu89 -pedantic mode for certain standard C99 usages, not for non-standard usages. You could add -Wno-long-long-windows-formats to disable warning for "I64d" in both gnu89 and gnu99 modes.
(In reply to comment #16) > -Wno-long-long disables warnings in gnu89 -pedantic mode for certain > standard C99 usages, not for non-standard usages. You could add > -Wno-long-long-windows-formats to disable warning for "I64d" in both gnu89 > and gnu99 modes. I like this idea; it lets us resolve this issue without having to neuter this port in one way or another. If there are no objections, I will prepare a patch for this. On naming, this isn't so much a Windowsism as a MSVCism. Maybe this should be named -Wlong-long-ms-formats similarly to -fms-extension or -fvisibility-ms-compat?
The problem here is not that the ms-formatter patch can't treat I/I32/I64. The problem is, that the ms-extensions are treated as gnu-extensions, which is in my option wrong. The scalar width specifiers should be treated as C89, and C90. So those meaningless warnings are avoided. The initial patch made this. I tried to discuss this while implementation with Danny, but he insisted that it should be implemented as gnu extensions, so it is. Cheers, Kai
Kai, I'm assigning this to you because you said on IRC a month or two ago that you were working on a patch for this. I've been working around this with a local patch that adds __extension__ everywhere that needs it.
Danny has recommended that we wait until 4.5 to add -Wno-pedantic-ms-format which will resolve this problem. <http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00664.html>. In the meantime, I'll keep the patch at <http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00594.html> in my tree to allow bootstraps from trunk to work without using --disable-werror. It's important we keep keep using -Werror so that more problems don't creep into Windows-specific code, whether they're bona fide bugs or just false positives. (Previously, I was adding __extension__ to each the site of each printf to allow the build to work.) Anyway, this shouldn't affect 4.4.x release builds, for which --disable-werror is the default.
Fix on trunk on revision 141087. See http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00428.html for the patch.