[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #28 from LIU Hao --- (In reply to Andrew Pinski from comment #27) > %zu should be added to ms_printf too. MSVCRT.DLL from Windows 7 does not support the `z` modifier. It seems supported on Windows 10; however people really should prefer UCRT there.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #27 from Andrew Pinski --- %zu should be added to ms_printf too.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #26 from LIU Hao --- (In reply to Martin Storsjö from comment #25) > But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released > in GCC 12 already), we probably don't need this any longer. So I think it > might be more correct to revert to ms_printf for UCRT, at least for GCC >= > 12 - what do you think? Yes, makes perfect sense. One reason for it is the difference about `long double`, and another is that there are GNU specifiers that MS doesn't support e.g. `%m`.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #25 from Martin Storsjö --- (In reply to Andrew Pinski from comment #23) > Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be > fixed to incldue that. > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification- > syntax-printf-and-wprintf-functions?view=msvc-140 > > I think for GCC 15, we should just update ms_printf to the 2015 version of > what is supported ... As long as GCC links against msvcrt.dll, distributed with the OS, the time since it's supported in MSVC doesn't affect things much though. But as Liu Hao noted, we already do support %lld in ms_printf since c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a, since it apparently was supported in the OS provided msvcrt.dll since a number of versions anyway. (In reply to LIU Hao from comment #24) > `%L` (for floating-point specifiers) is not compatible between `ms_printf` > and `gnu_printf`. We do use gnu_printf for the UCRT printf functions (which is what MSVC ships since 2015) though, see e.g. https://github.com/mingw-w64/mingw-w64/commit/8565cdb729b96f1122b1e9c490a7baba7b788f18. But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released in GCC 12 already), we probably don't need this any longer. So I think it might be more correct to revert to ms_printf for UCRT, at least for GCC >= 12 - what do you think?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #24 from LIU Hao --- (In reply to Andrew Pinski from comment #23) > Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be > fixed to incldue that. > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification- > syntax-printf-and-wprintf-functions?view=msvc-140 > > I think for GCC 15, we should just update ms_printf to the 2015 version of > what is supported ... `%ll` has been supported since c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a. `%L` (for floating-point specifiers) is not compatible between `ms_printf` and `gnu_printf`.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #23 from Andrew Pinski --- Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be fixed to incldue that. https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-140 I think for GCC 15, we should just update ms_printf to the 2015 version of what is supported ...
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #22 from Tomas Kalibera --- (In reply to CVS Commits from comment #21) > The master branch has been updated by Jonathan Yong : > > https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 > > commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 > Author: Tomas Kalibera > Date: Sun Aug 20 02:16:16 2023 + > > Fix format attribute for printf > > Since a long time (GCC 4.4?) GCC does support annotating functions > with either the format attribute "gnu_printf" or "ms_printf" to > distinguish between different format string interpretations. > > However, it seems like the attribute is ignored for the "printf" > symbol; regardless what the function declaration says, GCC treats > it as "ms_printf". This has become an issue now that mingw-w64 > supports using the UCRT instead of msvcrt.dll, and in this case > the stdio functions are declared with the gnu_printf attribute, > and inttypes.h uses the same format specifiers as in GNU mode. > > A reproducible example of the problem: > > $ cat format.c > __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char > *__format, ...); > __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char > *__format, ...); > > void function(void) { > long long unsigned x = 42; > othername("%llu\n", x); > printf("%llu\n", x); > } > $ x86_64-w64-mingw32-gcc -c -Wformat format.c > format.c: In function 'function': > format.c:7:15: warning: unknown conversion type character 'l' in format > [-Wformat=] > 7 | printf("%llu\n", x); > | ^ > format.c:7:12: warning: too many arguments for format > [-Wformat-extra-args] > 7 | printf("%llu\n", x); > |^~~~ > > Note how both functions, printf and othername, are declare with > identical gnu_printf format attributes - GCC does take this into > account for "othername" and doesn't produce a warning, but GCC > seems to disregard the attribute in the printf declaration and > behave as if it was declared as ms_printf. > > If the printf function declaration is changed into a static inline > function, the actual attribute used is honored though. > > gcc/c-family/ChangeLog: > > PR c/95130 > * c-format.cc: skip default format for printf symbol if > explicitly declared by prototype. > > Signed-off-by: Tomas Kalibera > Signed-off-by: Jonathan Yong <10wa...@gmail.com> Great, thanks a lot for finishing and adding this, Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3 Author: Tomas Kalibera Date: Sun Aug 20 02:16:16 2023 + Fix format attribute for printf Since a long time (GCC 4.4?) GCC does support annotating functions with either the format attribute "gnu_printf" or "ms_printf" to distinguish between different format string interpretations. However, it seems like the attribute is ignored for the "printf" symbol; regardless what the function declaration says, GCC treats it as "ms_printf". This has become an issue now that mingw-w64 supports using the UCRT instead of msvcrt.dll, and in this case the stdio functions are declared with the gnu_printf attribute, and inttypes.h uses the same format specifiers as in GNU mode. A reproducible example of the problem: $ cat format.c __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char *__format, ...); __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char *__format, ...); void function(void) { long long unsigned x = 42; othername("%llu\n", x); printf("%llu\n", x); } $ x86_64-w64-mingw32-gcc -c -Wformat format.c format.c: In function 'function': format.c:7:15: warning: unknown conversion type character 'l' in format [-Wformat=] 7 | printf("%llu\n", x); | ^ format.c:7:12: warning: too many arguments for format [-Wformat-extra-args] 7 | printf("%llu\n", x); |^~~~ Note how both functions, printf and othername, are declare with identical gnu_printf format attributes - GCC does take this into account for "othername" and doesn't produce a warning, but GCC seems to disregard the attribute in the printf declaration and behave as if it was declared as ms_printf. If the printf function declaration is changed into a static inline function, the actual attribute used is honored though. gcc/c-family/ChangeLog: PR c/95130 * c-format.cc: skip default format for printf symbol if explicitly declared by prototype. Signed-off-by: Tomas Kalibera Signed-off-by: Jonathan Yong <10wa...@gmail.com>
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #20 from Tomas Kalibera --- (In reply to Julian Waters from comment #19) > (In reply to Tomas Kalibera from comment #17) > > (In reply to Tomas Kalibera from comment #16) > > > (In reply to Julian Waters from comment #15) > > > > It seems like the patch also doesn't fix the strftime case too, > > > > strangely > > > > enough. gcc with that patch applied still causes a compilation failure > > > > in > > > > the Windows JDK when encountering strftime with the %T specifier > > > > > > > > > I don't easily see why the patch doesn't help with %T in strftime. In > > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > > > attribute is present. > > > > The older version of the patch I use with gcc 12 doesn't seem to be helping > > with %T, but the newer one (patch_master.diff) helps with %T on the current > > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with > > MinGW-W64 11.0.1. > > If I may ask, could I have the link to patch_master.diff? It is one of the attachments of this report, https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778 This patch has not been reviewed. I am not an expert on GCC internals and I cannot guarantee that adding meta-data this way to the AST is safe. So please use with care.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #19 from Julian Waters --- (In reply to Tomas Kalibera from comment #17) > (In reply to Tomas Kalibera from comment #16) > > (In reply to Julian Waters from comment #15) > > > It seems like the patch also doesn't fix the strftime case too, strangely > > > enough. gcc with that patch applied still causes a compilation failure in > > > the Windows JDK when encountering strftime with the %T specifier > > > > > > I don't easily see why the patch doesn't help with %T in strftime. In > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > > attribute is present. > > The older version of the patch I use with gcc 12 doesn't seem to be helping > with %T, but the newer one (patch_master.diff) helps with %T on the current > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with > MinGW-W64 11.0.1. If I may ask, could I have the link to patch_master.diff?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #18 from Julian Waters --- That's great news! With regards to this patch, I'm fairly certain you have to proactively send it to gcc-patches mailing list for it to be merged; No gcc committer has the time to look for this issue and commit it. I also think it's probably time for ms_printf to formally recognize ISO C format specifiers once and for all, too
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #17 from Tomas Kalibera --- (In reply to Tomas Kalibera from comment #16) > (In reply to Julian Waters from comment #15) > > It seems like the patch also doesn't fix the strftime case too, strangely > > enough. gcc with that patch applied still causes a compilation failure in > > the Windows JDK when encountering strftime with the %T specifier > > > I don't easily see why the patch doesn't help with %T in strftime. In > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > attribute is present. The older version of the patch I use with gcc 12 doesn't seem to be helping with %T, but the newer one (patch_master.diff) helps with %T on the current gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with MinGW-W64 11.0.1.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #16 from Tomas Kalibera --- (In reply to Julian Waters from comment #15) > It seems like the patch also doesn't fix the strftime case too, strangely > enough. gcc with that patch applied still causes a compilation failure in > the Windows JDK when encountering strftime with the %T specifier Given that this bug hasn't attracted enough attention to get fixed, perhaps you could try reporting this as a wish for improvement of the ms_strftime format (msformat-c.c, ms_time_char_table): probably it should support %T. I don't easily see why the patch doesn't help with %T in strftime. In MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format attribute is present.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Julian Waters changed: What|Removed |Added CC||tanksherman27 at gmail dot com --- Comment #15 from Julian Waters --- It seems like the patch also doesn't fix the strftime case too, strangely enough. gcc with that patch applied still causes a compilation failure in the Windows JDK when encountering strftime with the %T specifier
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Alvin Wong changed: What|Removed |Added CC||alvinhochun at gmail dot com --- Comment #14 from Alvin Wong --- `strftime` is another case that's affected. UCRT supports C99 formats (e.g. %F, %T) but GCC warns because of the hardcoded built-in ms_strftime format attribute, even though mingw-w64 has specified gnu_strftime.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #13 from Tomas Kalibera --- Another instance of this problem is %z (to print size_t). It is supported by UCRT, but the GCC's Microsoft format warns, because it wasn't supported with MSVCRT (seen with GCC 12.2).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Tomas Kalibera changed: What|Removed |Added Attachment #52007|0 |1 is obsolete|| --- Comment #12 from Tomas Kalibera --- Created attachment 53778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778=edit Draft patch to ignore built-in format attribute for a builtin, if there is another one This is a draft of an alternative patch, which addresses the concern that in theory the built in format attribute may not be the first one in the list of attributes of a built-in function. This patch puts attribute flags inside TREE_PURPOSE of the attribute, so that it can be checked later whether it is a built in attribute. I am not sure whether this is legal, but it should be easy to update it to store the flags somewhere else, if needed.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #11 from Tomas Kalibera --- (In reply to LIU Hao from comment #10) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > > Thanks for the patch. Updated locally. I will test it against trunk as soon > as I get a little time. Thanks. Re Jeff's comment from the mailing list: > I guess we're going to depend on the builtin-format always appearing > first in the chain? While it's probably true in practice, I doubt we > really want to depend on that. > > Is there any sensible way to distinguish between the builtin format and > one that comes from the source? I didn't find any elegant way to find out whether a format attribute is a built-in attribute in check_function_format(). So unless I overlooked something (which is very much possible), it would make the patch more intrusive. handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN). Maybe handle_format_attribute() could add the flags (or only a boolean whether it is a builtin attribute) to the attribute tree, so that check_function_format() can access it, e.g. similarly to how no_sanitize does it. Would this be better? And if so, is there a recommended place in the format attribute tree where it should be added to?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #10 from LIU Hao --- (In reply to Tomas Kalibera from comment #7) > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > mailing list in May: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > The patches still apply to current 10,11,12 and trunk. Please see the email > linked above for more information. Thanks for the patch. Updated locally. I will test it against trunk as soon as I get a little time.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #9 from Tomas Kalibera --- (In reply to Martin Storsjö from comment #8) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > Did you notice the review comment in July, > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/59.html? Ah, thanks, I missed it (as I wasn't on the to/cc).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #8 from Martin Storsjö --- (In reply to Tomas Kalibera from comment #7) > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > mailing list in May: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > The patches still apply to current 10,11,12 and trunk. Please see the email > linked above for more information. Did you notice the review comment in July, https://gcc.gnu.org/pipermail/gcc-patches/2022-July/59.html?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #7 from Tomas Kalibera --- I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches mailing list in May: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html The patches still apply to current 10,11,12 and trunk. Please see the email linked above for more information.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #6 from LIU Hao --- This patch no longer applies to trunk. Would you please update it?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #5 from Tomas Kalibera --- (In reply to jos...@codesourcery.com from comment #1) > See bug 92292. The extra attribute isn't ignored, it simply means the > function has multiple format attributes, which is valid, but should > probably be special-cased for this case of built-in functions. I've added a draft of a patch to address the issue in the suggested way. I've tested it in gcc 10.3.0 on the example from comment 2 (also attached). With the patch applied, only line (2) gets a warning, as it should. When deciding whether to emit a format warning for a function with multiple format attributes, it skips the first format in case it is a builtin known to have a format added by gcc. Please let me know if you have any advice how to improve (thanks to Martin Liska for helping me with identifying the builtins), or indeed feel free to adjust and add your way. Fixing this would help the R community or anyone else who uses GCC with UCRT. Thanks, Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #4 from Tomas Kalibera --- Created attachment 52008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52008=edit Example from comment 2
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #3 from Tomas Kalibera --- Created attachment 52007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52007=edit Patch to ignore first format for builtins that have more than one This patch for 10.3.0 instructs gcc to ignore the first format attribute for functions that have multiple format attributes and are builtins with a format attribute added by GCC.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Tomas Kalibera changed: What|Removed |Added CC||tomas.kalibera at gmail dot com --- Comment #2 from Tomas Kalibera --- My apologies if this is obvious, but please let me note this issue means that one cannot print(f) a 64-bit integer without a compile-time warning with UCRT on Windows. It would be a great help if this could somehow be fixed. In the example below, lines (1) and (2) work without a warning with MSVCRT. But, all three issue a warning with UCRT. #include #include int main(int argc, char **argv) { long long unsigned x = 112; printf("Hello %"PRIu64"\n", x); // 1 printf("Hello %I64u\n", x); // 2 printf("Hello %llu\n", x); // 3 return 0; }
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #1 from joseph at codesourcery dot com --- See bug 92292. The extra attribute isn't ignored, it simply means the function has multiple format attributes, which is valid, but should probably be special-cased for this case of built-in functions.