On 2/22/19 4:33 PM, Jakub Jelinek wrote:
On Fri, Feb 22, 2019 at 04:17:14PM -0700, Martin Sebor wrote:
On 2/22/19 3:44 PM, Jakub Jelinek wrote:
On Tue, Feb 19, 2019 at 05:43:53PM -0700, Martin Sebor wrote:
PR tree-optimization/88993
PR tree-optimization/88835
* gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
Can you please, when testing a patch like this where you should expect
tbe wordsize will play an important role to test it with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
tree-ssa.exp=builtin-*printf-warn*'
?
There are many failures on ilp32 targets.
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c (test for warnings, line 114)
I don't see these failures with -m32. They must be specific to 32-bit
GCC itself.
My bootstrap was indeed i686-linux, not x86_64-linux compiler with -m32.
E.g. target_strtol10 for some strange reason returns long rather than
HOST_WIDE_INT and checks LONG_MAX rather than HOST_WIDE_INT_MAX, making
it host dependent rather than target dependent. Either it should work with
HWI and its max always, or should cap at precision of some target type
(e.g. glibc I think uses int type for both width and precision, parsing
through read_int that is similar to target_strtol10, except that it returns
(target) int and if over INT_MAX uses -1).
target_strtol10 returns long because it's wide enough for what it's
used for (width and precision, both int) for all supported hosts
and targets. What it's not good enough for (and what I forgot about)
is capturing the value of width and precision in excess of host
LONG_MAX in diagnostics. For instance
printf ("%2147483650i", 1);
in LP64 results in
warning: ‘%2147483650i’ directive output of 2147483650 bytes exceeds
‘INT_MAX’
but in ILP32 in:
warning: ‘%2147483650i’ directive width out of range
But changing the function to work with HOST_WIDE_INT makes
the warnings consistent between the data models and will help
avoid these gotchas in the future so I've made the change. I'll
post the patch once it passes bootstrap/regtest.
Martin
