|Summary:||benchmarks/bonnie: Fix build warning: format specifies type 'int' but the argument has type 'long long' [-Wformat] (armv6, -mcpu=cortex-a7 for rpi2)|
|Product:||Ports & Packages||Reporter:||Mark Millard <marklmi26-fbsd>|
|Component:||Individual Port(s)||Assignee:||Jun Kuriyama <kuriyama>|
|Severity:||Affects Some People||CC:||w.schwarzenfeld|
Description Mark Millard 2016-07-05 20:40:08 UTC
Building benchmarks/bonnie on and for an rpi2 (armv6 with -mcpu=cortex-a7) under 11.0 -r302331 reports: Bonnie.c:392:49: warning: format specifies type 'int' but the argument has type 'long long' [-Wformat] printf("<TR><TD>%s</TD><TD>%d</TD>", machine, size / (1024 * 1024)); ~~ ^~~~~~~~~~~~~~~~~~~~ %lld This sort of thing makes the software likely big-endian vs. little-endian (vs. pdp-endian) sensitive and the like. Likely explicitly casting to long long or other such large type and using a matching format is required to survive various various targets. The above width mismatch is less likely to appear to work for powerpc or powerpc64 (big-endian). [It will be some time before I again have access to the powerpc's.] Side notes: Other build notices were. . . implicitly declaring library function 'strcmp' with type 'int (const char *, const char *)' include the header <string.h> or explicitly provide a declaration for 'strcmp' implicit declaration of function 'wait' is invalid in C99 implicitly declaring library function 'strerror' with type 'char *(int)' include the header <string.h> or explicitly provide a declaration for 'strerror'
Comment 1 Mark Millard 2016-08-02 08:38:21 UTC
The build was of bonnie-2.0.6_1 --which is still in place as of /usr/ports/ -r419343 .
Comment 2 Mark Linimon 2017-02-03 12:57:45 UTC
This error still appears as of 20170128, although the port does build.
Comment 3 Walter Schwarzenfeld 2018-03-12 23:33:07 UTC
Comment 4 Walter Schwarzenfeld 2019-09-02 12:11:11 UTC
Created attachment 207098 [details] svn-diff-bonnie
Comment 5 Kubilay Kocak 2019-09-03 01:13:07 UTC
(In reply to Walter Schwarzenfeld from comment #4) @Mark (Reporter), could you review and test this patch please Confirmation that this change passes QA (portlint, poudriere) would also be handy to progress the issue Finally, these issues should ultimately be reported and resolved upstream
Comment 6 Mark Millard 2019-09-03 06:45:30 UTC
(In reply to Kubilay Kocak from comment #5) I do not have a armv6 or armv7 or other 32-bit environment available/ready currently. But I could cross build via poudriere-devel. So I applied the patch to my /usr/ports/benchmarks/bonnie that my poudriere-devel environment uses and tried builds for amd64, aarch64, and armv7. Checking for logs containing 'format specifies', the ArmV7 context had matches: # grep 'format specifies' /usr/local/poudriere/data/logs/bulk/FBSDFSSDjailArmV7-default/2019-09-02_22h41m29s/logs/bonnie-2.0.6.log Bonnie.c:154:51: warning: format specifies type 'long' but the argument has type 'off_t' (aka 'long long') [-Wformat] Bonnie.c:394:50: warning: format specifies type 'long' but the argument has type 'long long' [-Wformat] Bonnie.c:427:35: warning: format specifies type 'long' but the argument has type 'long long' [-Wformat] The warnings did not stop the build. My guess is that the ":394" is analogous to the ":392" example from my original report. The 'int' changed to 'long' in the mean time. long matches long long widths for the LP64 contexts, but for the ILP32 contexts, long is 32 bits and long long is 64. The patch-Bonnie.c file ended up with: - printf("<TR><TD>%s</TD><TD>%d</TD>", machine, size / (1024 * 1024)); + printf("<TR><TD>%s</TD><TD>%ld</TD>", machine, size / (1024 * 1024)); for the :394 example (no %lld). It also ended up with: - printf("%-8.8s %4d ", machine, size / (1024 * 1024)); + printf("%-8.8s %4ld ", machine, size / (1024 * 1024)); for the :427 example (no %lld). The patch-Bonnie.c ended up with nothing spanning :154 . As for portlint: # portlint . FATAL: Makefile: extra item "2ORTREVISION" placed in the PORTNAME section. WARN: Makefile: Consider defining LICENSE. 1 fatal error and 1 warning found. The svn-diff-bonnie patch file that I downloaded does have: -PORTREVISION= 1 +2ORTREVISION= 2 For reference: ===> Building for bonnie-2.0.6 --- bsd --- Options are "make bsd" and "make SysV" - the default is "bsd". If you get messages about missing functions, try "make SysV." make Bonnie --- Bonnie --- /nxb-bin/usr/bin/cc -O2 -pipe -mcpu=cortex-a7 -g -fstack-protector-strong -fno-strict-aliasing -fstack-protector-strong Bonnie.c -o Bonnie Bonnie.c:154:51: warning: format specifies type 'long' but the argument has type 'off_t' (aka 'long long') [-Wformat] fprintf(stderr, "File '%s', size: %ld\n", name, size); ~~~ ^~~~ %lld Bonnie.c:394:50: warning: format specifies type 'long' but the argument has type 'long long' [-Wformat] printf("<TR><TD>%s</TD><TD>%ld</TD>", machine, size / (1024 * 1024)); ~~~ ^~~~~~~~~~~~~~~~~~~~ %lld Bonnie.c:427:35: warning: format specifies type 'long' but the argument has type 'long long' [-Wformat] printf("%-8.8s %4ld ", machine, size / (1024 * 1024)); ~~~~ ^~~~~~~~~~~~~~~~~~~~ %4lld 3 warnings generated. # svnlite info /usr/ports/benchmarks/bonnie Path: . Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head/benchmarks/bonnie Relative URL: ^/head/benchmarks/bonnie Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 509171 Node Kind: directory Schedule: normal Last Changed Author: bapt Last Changed Rev: 451957 Last Changed Date: 2017-10-13 01:21:36 -0700 (Fri, 13 Oct 2017) And the patch reported: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: Makefile |=================================================================== |--- Makefile (revision 510780) |+++ Makefile (working copy) -------------------------- Patching file Makefile using Plan A... Hunk #1 succeeded at 3. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: files/patch-Bonnie.c |=================================================================== |--- files/patch-Bonnie.c (revision 510780) |+++ files/patch-Bonnie.c (working copy) -------------------------- Patching file files/patch-Bonnie.c using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 12. Hunk #3 succeeded at 21. Hunk #4 succeeded at 30. Hunk #5 succeeded at 39. Hunk #6 succeeded at 48. Hunk #7 succeeded at 57. Hunk #8 succeeded at 65. Hunk #9 succeeded at 79. Hunk #10 succeeded at 109. Hunk #11 succeeded at 118. done I hope that this helps.
Comment 7 Mark Millard 2019-09-03 07:51:10 UTC
(In reply to Mark Millard from comment #6) I'll note that FreeBSD's off_t is 64 bits even for ILP32 contexts. My memory is that this is not true of linux (for example): 32 bits for ILP32. So there are 3 contexts overall for Bonnie to try to span for off_t formatting. Thus, if one tries to span both types of ILP32 contexts, the format %lld is used with a (long long) cast of the value so they are matched for all cases. (Some contexts end up with (long long) being redundant.) off_t may not be the only thing to have this distinction for ILP32. So there may be more contexts with both a cast and %lld use. Another common handling is using (intmax_t) and %jd. But Bonnie might be trying to allow older C vintages than ones that necessarily have intmax_t (for all I know).
Comment 8 Walter Schwarzenfeld 2019-09-04 02:23:32 UTC
Created attachment 207174 [details] svn-diff-bonnie_v2
Comment 9 Walter Schwarzenfeld 2019-09-04 02:26:58 UTC
Created attachment 207175 [details] svn-diff_bonnie_v2 Puzzled patch for bonnie and bonnie++.
Comment 10 Mark Millard 2019-09-04 03:30:08 UTC
(In reply to Walter Schwarzenfeld from comment #9) In (for example): fprintf(stderr, "File '%s', size: %lld\n", name, (unsigned long long)size); %lld gives a signed interpretation vs. the (unsigned long long) cast. The compiler reported long long in all 3 cases. At least for the one that was off_t (aka long long), signed is appropriate and unsigned would not be. For ILP32 off_t on linux (long long) would sign extend but (unsigned long long) would not, messing up display of negative offsets. %llu would give an unsigned interpretation in decimal in the format if it is needed someplace. (But it may not be needed.)
Comment 11 Walter Schwarzenfeld 2019-09-04 03:43:13 UTC
Created attachment 207179 [details] svn-diff-bonnie_v3
Comment 12 Mark Millard 2020-03-11 03:01:16 UTC
(In reply to Walter Schwarzenfeld from comment #11) I finally got back to this. I used the patch and built on each of: amd64, powerpc64, aarch64, 32-bit powerpc, armv7 and none of them got any complaints from the compilers. It covers LP64, IPL32, little endian, and big endian. All were at head -r358510 for FreeBSD. Looking at it, it looks reasonable to me. Running them seemed to wrk fine as well. I'd say to go ahead and update.