Bug 25502 - I64d format Werror problem in build
I64d format Werror problem in build
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: bootstrap
4.2.0
: P3 normal
: ---
Assigned To: Kai Tietz
: build
: 32794 (view as bug list)
Depends on:
Blocks: 36216
  Show dependency treegraph
 
Reported: 2005-12-20 11:30 UTC by Francois-Xavier Coudert
Modified: 2008-10-13 10:39 UTC (History)
6 users (show)

See Also:
Host: i686-pc-mingw32
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-05-11 21:24:33


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francois-Xavier Coudert 2005-12-20 11:30:56 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
Comment 1 Francois-Xavier Coudert 2005-12-20 11:35:41 UTC
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.
Comment 2 Andrew Pinski 2005-12-20 16:37:03 UTC
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.
Comment 3 Mark Mitchell 2005-12-20 16:44:25 UTC
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.
Comment 4 Francois-Xavier Coudert 2005-12-22 07:35:33 UTC
(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.
Comment 5 Mark Mitchell 2005-12-22 08:19:37 UTC
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?

Comment 6 Ranjit Mathew 2006-06-04 09:47:02 UTC
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).
Comment 7 Danny Smith 2006-06-04 11:02:34 UTC
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.
Comment 8 Francois-Xavier Coudert 2007-05-22 13:06:37 UTC
(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
Comment 9 Andrew Pinski 2007-07-17 21:13:27 UTC
*** Bug 32794 has been marked as a duplicate of this bug. ***
Comment 10 Zuxy 2008-03-19 06:43:06 UTC
Still, 4.3.0 can't recoginze %I64d
Comment 11 Andrew Pinski 2008-03-19 07:09:19 UTC
(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
Comment 12 Danny Smith 2008-03-19 21:35:36 UTC
(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
Comment 13 Aaron W. LaFramboise 2008-05-11 03:04:43 UTC
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?
Comment 14 Aaron W. LaFramboise 2008-05-11 04:48:19 UTC
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.
Comment 15 joseph@codesourcery.com 2008-05-11 12:15:22 UTC
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.

Comment 16 joseph@codesourcery.com 2008-05-11 12:17:50 UTC
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.

Comment 17 Aaron W. LaFramboise 2008-05-11 21:24:33 UTC
(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?
Comment 18 Kai Tietz 2008-05-19 10:27:58 UTC
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
Comment 19 Aaron W. LaFramboise 2008-08-24 01:17:24 UTC
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.
Comment 20 Aaron W. LaFramboise 2008-09-14 03:27:28 UTC
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.
Comment 21 Kai Tietz 2008-10-13 10:39:42 UTC
Fix on trunk on revision 141087. See http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00428.html for the patch.