Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 02/01/2018 04:54 AM, Renlin Li wrote: Hi Martin, On 01/02/18 00:40, Martin Sebor wrote: On 01/31/2018 10:36 AM, Renlin Li wrote: Hi there, I have a patch to fix to regressions we observed in armhf native environment. To effectively check out of range for format string, a target type should be used. And according to the standard, int type is used for "width" and "precision" field of format string. Here target_strtol10 is rename to target_strtoi10, and fixed to use target_int_max () which is target dependent. The value returned by target_strtol10 is (target_int_max () + 1) when it exceeds the range. This is used to indicate its value exceeds target INT_MAX for the later warning. Sorry for not responding to your original email. It's still in my inbox, just buried under a pile of stuff. Using LONG_MAX is not ideal but unless I missed something (it's been a while) I think using INT_MAX for the target would be even less optimal. Unless specified by the asterisk, width and precision can be arbitrarily large. I cannot find more document about this other than here: http://en.cppreference.com/w/c/io/fprintf The best reference is the C standard. The most recent publicly available draft of C11 is here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf The next best (and sometimes better) reference is POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html (optional) integer value or * that specifies minimum field width. (optional) . followed by integer number or *, or neither that specifies precision of the conversion. It only mentions a integer value, with no type. I assume it could be of type int? It is indeed very unclear about the range of width and precision. Because the spec doesn't say what precision the number is to be interpreted in, it must be taken to mean a number with an arbitrary precision. constraining either to INT_MAX would trigger warnings on LP64 targets for safe calls like: // INT_MAX is 2147483647 sprintf (d, "%.2147483648s", ""); I think we want to use the maximum value of an unsigned type with the greatest precision on the host. It will still warn for directives with precisions in excess of HOST_WIDE_INT_MAX Is it here a target type should be used to test the range against? Instead of the host where the toolchain is built? I think for the purposes of runtime evaluation by a conforming implementation, both the width and the precision need to be interpreted "as if" with infinite precision. But after sleeping on it, I suppose that for the purposes of the warning, it could be helpful to point out values that exceed even INT_MAX on the host (rather than target) because they aren't very meaningful and are most likely mistakes (e.g., hidden by macro expansion). It might still be useful to have the pass store the larger number (up to its limit, whatever that is on the host), and use it for its internal computation and subsequent diagnostics for accuracy. Martin Regards, Renlin but short of using something like offset_int it's probably as good as it's going to get. (It has been suggested that the whole pass would benefit from using offset_int to track large numbers so if/when it's enhanced to make this change it should also make the code behave more consistently across different hosts.) Martin Is it Okay to commit? Regards, Renlin gcc/ChangeLog: 2018-01-31 Renlin Li * gimple-ssa-sprintf.c (target_strtol10): Use target integer to check the range. Rename it into (target_strtoi10): This. (parse_directive): Compare with target int max instead of LONG_MAX. On 20/06/17 12:00, Renlin Li wrote: Hi Martin, I did a little investigation into this. Please correct me if I missed anything. I build a native arm-linux-gnueabihf toolchain in armhf hardware. It's ILP32. So in this situation: HOST_WIDE_INT is long, which is 32-bit. integer type 32-bit as well, so target_int_max () == LONG_MAX gimple-ssa-sprintf.c line 2887 /* Has the likely and maximum directive output exceeded INT_MAX? */ bool likelyximax = *dir.beg && res->range.likely > target_int_max (); likelyximax will be false as the latter expression is always false. res->range.likely is truncated to LONG_MAX (in target_strtol10 function) I have checked in cross build environment (host x86_64), this variable is true. Regards, Renlin On 13/06/17 09:16, Renlin Li wrote: Hi Martin, On 04/06/17 23:24, Martin Sebor wrote: On 06/02/2017 09:38 AM, Renlin Li wrote: Hi Martin, After r247444, I saw the following two regressions in arm-linux-gnueabihf environment: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119) PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) The warning message related to those two lines are: testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning: '%9223372036854
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi Martin, On 01/02/18 00:40, Martin Sebor wrote: On 01/31/2018 10:36 AM, Renlin Li wrote: Hi there, I have a patch to fix to regressions we observed in armhf native environment. To effectively check out of range for format string, a target type should be used. And according to the standard, int type is used for "width" and "precision" field of format string. Here target_strtol10 is rename to target_strtoi10, and fixed to use target_int_max () which is target dependent. The value returned by target_strtol10 is (target_int_max () + 1) when it exceeds the range. This is used to indicate its value exceeds target INT_MAX for the later warning. Sorry for not responding to your original email. It's still in my inbox, just buried under a pile of stuff. Using LONG_MAX is not ideal but unless I missed something (it's been a while) I think using INT_MAX for the target would be even less optimal. Unless specified by the asterisk, width and precision can be arbitrarily large. I cannot find more document about this other than here: http://en.cppreference.com/w/c/io/fprintf (optional) integer value or * that specifies minimum field width. (optional) . followed by integer number or *, or neither that specifies precision of the conversion. It only mentions a integer value, with no type. I assume it could be of type int? It is indeed very unclear about the range of width and precision. constraining either to INT_MAX would trigger warnings on LP64 targets for safe calls like: // INT_MAX is 2147483647 sprintf (d, "%.2147483648s", ""); I think we want to use the maximum value of an unsigned type with the greatest precision on the host. It will still warn for directives with precisions in excess of HOST_WIDE_INT_MAX Is it here a target type should be used to test the range against? Instead of the host where the toolchain is built? Regards, Renlin but short of using something like offset_int it's probably as good as it's going to get. (It has been suggested that the whole pass would benefit from using offset_int to track large numbers so if/when it's enhanced to make this change it should also make the code behave more consistently across different hosts.) Martin Is it Okay to commit? Regards, Renlin gcc/ChangeLog: 2018-01-31 Renlin Li * gimple-ssa-sprintf.c (target_strtol10): Use target integer to check the range. Rename it into (target_strtoi10): This. (parse_directive): Compare with target int max instead of LONG_MAX. On 20/06/17 12:00, Renlin Li wrote: Hi Martin, I did a little investigation into this. Please correct me if I missed anything. I build a native arm-linux-gnueabihf toolchain in armhf hardware. It's ILP32. So in this situation: HOST_WIDE_INT is long, which is 32-bit. integer type 32-bit as well, so target_int_max () == LONG_MAX gimple-ssa-sprintf.c line 2887 /* Has the likely and maximum directive output exceeded INT_MAX? */ bool likelyximax = *dir.beg && res->range.likely > target_int_max (); likelyximax will be false as the latter expression is always false. res->range.likely is truncated to LONG_MAX (in target_strtol10 function) I have checked in cross build environment (host x86_64), this variable is true. Regards, Renlin On 13/06/17 09:16, Renlin Li wrote: Hi Martin, On 04/06/17 23:24, Martin Sebor wrote: On 06/02/2017 09:38 AM, Renlin Li wrote: Hi Martin, After r247444, I saw the following two regressions in arm-linux-gnueabihf environment: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119) PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) The warning message related to those two lines are: testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning: '%9223372036854775808i' directive width out of range [-Wformat-overflow=] testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] Did you notice similar things from your test environment, Christophe? Looks like you're missing a couple of warnings. I see the following output with both my arm-linux-gnueabihf cross compiler and my native x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test, so I don't see the same issue in my environment. Yes, it happens on arm-linux-gnueabihf native environment. the warnings with "INT_MAX" line are missing. I don't know if the host environment will cause the difference. Regards, Renlin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 01/31/2018 10:36 AM, Renlin Li wrote: Hi there, I have a patch to fix to regressions we observed in armhf native environment. To effectively check out of range for format string, a target type should be used. And according to the standard, int type is used for "width" and "precision" field of format string. Here target_strtol10 is rename to target_strtoi10, and fixed to use target_int_max () which is target dependent. The value returned by target_strtol10 is (target_int_max () + 1) when it exceeds the range. This is used to indicate its value exceeds target INT_MAX for the later warning. Sorry for not responding to your original email. It's still in my inbox, just buried under a pile of stuff. Using LONG_MAX is not ideal but unless I missed something (it's been a while) I think using INT_MAX for the target would be even less optimal. Unless specified by the asterisk, width and precision can be arbitrarily large. It seems to me that constraining either to INT_MAX would trigger warnings on LP64 targets for safe calls like: // INT_MAX is 2147483647 sprintf (d, "%.2147483648s", ""); I think we want to use the maximum value of an unsigned type with the greatest precision on the host. It will still warn for directives with precisions in excess of HOST_WIDE_INT_MAX but short of using something like offset_int it's probably as good as it's going to get. (It has been suggested that the whole pass would benefit from using offset_int to track large numbers so if/when it's enhanced to make this change it should also make the code behave more consistently across different hosts.) Martin Is it Okay to commit? Regards, Renlin gcc/ChangeLog: 2018-01-31 Renlin Li * gimple-ssa-sprintf.c (target_strtol10): Use target integer to check the range. Rename it into (target_strtoi10): This. (parse_directive): Compare with target int max instead of LONG_MAX. On 20/06/17 12:00, Renlin Li wrote: Hi Martin, I did a little investigation into this. Please correct me if I missed anything. I build a native arm-linux-gnueabihf toolchain in armhf hardware. It's ILP32. So in this situation: HOST_WIDE_INT is long, which is 32-bit. integer type 32-bit as well, so target_int_max () == LONG_MAX gimple-ssa-sprintf.c line 2887 /* Has the likely and maximum directive output exceeded INT_MAX? */ bool likelyximax = *dir.beg && res->range.likely > target_int_max (); likelyximax will be false as the latter expression is always false. res->range.likely is truncated to LONG_MAX (in target_strtol10 function) I have checked in cross build environment (host x86_64), this variable is true. Regards, Renlin On 13/06/17 09:16, Renlin Li wrote: Hi Martin, On 04/06/17 23:24, Martin Sebor wrote: On 06/02/2017 09:38 AM, Renlin Li wrote: Hi Martin, After r247444, I saw the following two regressions in arm-linux-gnueabihf environment: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119) PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121) The warning message related to those two lines are: testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning: '%9223372036854775808i' directive width out of range [-Wformat-overflow=] testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] Did you notice similar things from your test environment, Christophe? Looks like you're missing a couple of warnings. I see the following output with both my arm-linux-gnueabihf cross compiler and my native x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test, so I don't see the same issue in my environment. Yes, it happens on arm-linux-gnueabihf native environment. the warnings with "INT_MAX" line are missing. I don't know if the host environment will cause the difference. Regards, Renlin
Re: Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi there,
I have a patch to fix to regressions we observed in armhf native environment.
To effectively check out of range for format string, a target type should be
used. And according to the standard, int type is used for "width" and
"precision"
field of format string.
Here target_strtol10 is rename to target_strtoi10, and fixed to use
target_int_max () which is target dependent.
The value returned by target_strtol10 is (target_int_max () + 1) when it
exceeds the range.
This is used to indicate its value exceeds target INT_MAX for the later warning.
Is it Okay to commit?
Regards,
Renlin
gcc/ChangeLog:
2018-01-31 Renlin Li
* gimple-ssa-sprintf.c (target_strtol10): Use target integer to check
the range. Rename it into
(target_strtoi10): This.
(parse_directive): Compare with target int max instead of LONG_MAX.
On 20/06/17 12:00, Renlin Li wrote:
Hi Martin,
I did a little investigation into this. Please correct me if I missed anything.
I build a native arm-linux-gnueabihf toolchain in armhf hardware.
It's ILP32. So in this situation:
HOST_WIDE_INT is long, which is 32-bit.
integer type 32-bit as well, so target_int_max () == LONG_MAX
gimple-ssa-sprintf.c line 2887
/* Has the likely and maximum directive output exceeded INT_MAX? */
bool likelyximax = *dir.beg && res->range.likely > target_int_max ();
likelyximax will be false as the latter expression is always false.
res->range.likely is truncated to LONG_MAX (in target_strtol10 function)
I have checked in cross build environment (host x86_64), this variable is true.
Regards,
Renlin
On 13/06/17 09:16, Renlin Li wrote:
Hi Martin,
On 04/06/17 23:24, Martin Sebor wrote:
On 06/02/2017 09:38 AM, Renlin Li wrote:
Hi Martin,
After r247444, I saw the following two regressions in
arm-linux-gnueabihf environment:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 119)
PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
The warning message related to those two lines are:
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning:
'%9223372036854775808i' directive width out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
Did you notice similar things from your test environment, Christophe?
Looks like you're missing a couple of warnings. I see the following
output with both my arm-linux-gnueabihf cross compiler and my native
x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test,
so I don't see the same issue in my environment.
Yes, it happens on arm-linux-gnueabihf native environment. the warnings with
"INT_MAX"
line are missing. I don't know if the host environment will cause the
difference.
Regards,
Renlin
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 14b12191d9b16699b28541cb24914fa9f8d8fea9..3a903ffad8e524c6d2fd405812ebc0869bfed7a7 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -399,12 +399,12 @@ target_to_host (char *hostr, size_t hostsz, const char *targstr)
}
/* Convert the sequence of decimal digits in the execution character
- starting at S to a long, just like strtol does. Return the result
- and set *END to one past the last converted character. On range
- error set ERANGE to the digit that caused it. */
+ starting at S to a int. Return the result and set *END to one past the last
+ converted character.
+ On range error set ERANGE to the digit that caused it. */
-static inline long
-target_strtol10 (const char **ps, const char **erange)
+static inline HOST_WIDE_INT
+target_strtoi10 (const char **ps, const char **erange)
{
unsigned HOST_WIDE_INT val = 0;
for ( ; ; ++*ps)
@@ -415,9 +415,9 @@ target_strtol10 (const char **ps, const char **erange)
c -= '0';
/* Check for overflow. */
- if (val > (LONG_MAX - c) / 10LU)
+ if (val > (target_int_max () - c) / 10LU)
{
- val = LONG_MAX;
+ val = target_int_max () + 1;
*erange = *ps;
/* Skip the remaining digits. */
@@ -3082,7 +3082,7 @@ parse_directive (sprintf_dom_walker::call_info &info,
width and sort it out later after the next character has
been seen. */
pwidth = pf;
- width = target_strtol10 (&pf, &werange);
+ width = target_strtoi10 (&pf, &werange);
}
else if (target_to_host (*pf) == '*')
{
@@ -3164,7 +3164,7 @@ parse_directive (sprintf_dom_walker::call_info &info,
{
werange = 0;
pwidth = pf;
- width = target_strtol10 (&pf, &werange);
+ width = target_strtoi10 (&pf, &werange);
}
else if (target_to_host (*pf) == '*')
{
@
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi Martin,
I did a little investigation into this. Please correct me if I missed anything.
I build a native arm-linux-gnueabihf toolchain in armhf hardware.
It's ILP32. So in this situation:
HOST_WIDE_INT is long, which is 32-bit.
integer type 32-bit as well, so target_int_max () == LONG_MAX
gimple-ssa-sprintf.c line 2887
/* Has the likely and maximum directive output exceeded INT_MAX? */
bool likelyximax = *dir.beg && res->range.likely > target_int_max ();
likelyximax will be false as the latter expression is always false.
res->range.likely is truncated to LONG_MAX (in target_strtol10 function)
I have checked in cross build environment (host x86_64), this variable is true.
Regards,
Renlin
On 13/06/17 09:16, Renlin Li wrote:
Hi Martin,
On 04/06/17 23:24, Martin Sebor wrote:
On 06/02/2017 09:38 AM, Renlin Li wrote:
Hi Martin,
After r247444, I saw the following two regressions in
arm-linux-gnueabihf environment:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 119)
PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
The warning message related to those two lines are:
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning:
'%9223372036854775808i' directive width out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
Did you notice similar things from your test environment, Christophe?
Looks like you're missing a couple of warnings. I see the following
output with both my arm-linux-gnueabihf cross compiler and my native
x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test,
so I don't see the same issue in my environment.
Yes, it happens on arm-linux-gnueabihf native environment. the warnings with
"INT_MAX"
line are missing. I don't know if the host environment will cause the
difference.
Regards,
Renlin
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning:
‘%9223372036854775808i’ directive width out of range [-Wformat-overflow=]
T ("%9223372036854775808i", 0);/* { dg-warning "width out of range" } */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning:
‘%9223372036854775808i’ directive output of 9223372036854775807 bytes causes
result to
exceed ‘INT_MAX’ [-Wformat-overflow=]
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning:
‘%.9223372036854775808i’ directive precision out of range [-Wformat-overflow=]
T ("%.9223372036854775808i", 0); /* { dg-warning "precision out of range"
} */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning:
‘%.9223372036854775808i’ directive output of 9223372036854775807 bytes causes
result to
exceed ‘INT_MAX’ [-Wformat-overflow=]
Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi Martin,
On 04/06/17 23:24, Martin Sebor wrote:
On 06/02/2017 09:38 AM, Renlin Li wrote:
Hi Martin,
After r247444, I saw the following two regressions in
arm-linux-gnueabihf environment:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 119)
PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
The warning message related to those two lines are:
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning:
'%9223372036854775808i' directive width out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
Did you notice similar things from your test environment, Christophe?
Looks like you're missing a couple of warnings. I see the following
output with both my arm-linux-gnueabihf cross compiler and my native
x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test,
so I don't see the same issue in my environment.
Yes, it happens on arm-linux-gnueabihf native environment. the warnings with "INT_MAX"
line are missing. I don't know if the host environment will cause the difference.
Regards,
Renlin
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning:
‘%9223372036854775808i’ directive width out of range [-Wformat-overflow=]
T ("%9223372036854775808i", 0);/* { dg-warning "width out of range" } */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning:
‘%9223372036854775808i’ directive output of 9223372036854775807 bytes causes
result to
exceed ‘INT_MAX’ [-Wformat-overflow=]
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning:
‘%.9223372036854775808i’ directive precision out of range [-Wformat-overflow=]
T ("%.9223372036854775808i", 0); /* { dg-warning "precision out of range"
} */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning:
‘%.9223372036854775808i’ directive output of 9223372036854775807 bytes causes
result to
exceed ‘INT_MAX’ [-Wformat-overflow=]
Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 06/02/2017 09:38 AM, Renlin Li wrote:
Hi Martin,
After r247444, I saw the following two regressions in
arm-linux-gnueabihf environment:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 119)
PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings,
line 121)
The warning message related to those two lines are:
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning:
'%9223372036854775808i' directive width out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range
[-Wformat-overflow=]
Did you notice similar things from your test environment, Christophe?
Looks like you're missing a couple of warnings. I see the following
output with both my arm-linux-gnueabihf cross compiler and my native
x86_64 GCC, both in 32-bit and 64-bit modes, as expected by the test,
so I don't see the same issue in my environment.
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning: ‘%9223372036854775808i’ directive width out of range
[-Wformat-overflow=]
T ("%9223372036854775808i", 0);/* { dg-warning "width out of
range" } */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3:
warning: ‘%9223372036854775808i’ directive output of 9223372036854775807
bytes causes result to exceed ‘INT_MAX’ [-Wformat-overflow=]
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning: ‘%.9223372036854775808i’ directive precision out of range
[-Wformat-overflow=]
T ("%.9223372036854775808i", 0); /* { dg-warning "precision out of
range" } */
^
/ssd/src/gcc/git/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3:
warning: ‘%.9223372036854775808i’ directive output of
9223372036854775807 bytes causes result to exceed ‘INT_MAX’
[-Wformat-overflow=]
Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi Martin,
After r247444, I saw the following two regressions in arm-linux-gnueabihf
environment:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119)
PASS: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 121)
The warning message related to those two lines are:
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:119:3: warning:
'%9223372036854775808i' directive width out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range [-Wformat-overflow=]
testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:121:3: warning:
'%.9223372036854775808i' directive precision out of range [-Wformat-overflow=]
Did you notice similar things from your test environment, Christophe?
Regards,
Renlin
On 03/05/17 16:02, Christophe Lyon wrote:
On 3 May 2017 at 16:54, Martin Sebor wrote:
On 05/03/2017 08:22 AM, Christophe Lyon wrote:
Hi,
On 29 April 2017 at 19:56, Andreas Schwab wrote:
On Apr 28 2017, Martin Sebor wrote:
+void test_width_and_precision_out_of_range (char *d)
+{
+#if __LONG_MAX__ == 2147483647
+# define MAX_P1_STR "2147483648"
+#elif __LONG_MAX__ == 9223372036854775807
+# define MAX_P1_STR "9223372036854775808"
+#endif
+
+ T ("%" MAX_P1_STR "i", 0);/* { dg-warning "width out of range" }
*/
+ /* { dg-warning "result to exceed .INT_MAX. " "" { target *-*-* } .-1
} */
+ T ("%." MAX_P1_STR "i", 0); /* { dg-warning "precision out of
range" } */
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line
123)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line
125)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170429/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:125:3:
warning: '%.2147483648i' directive output of 2147483648 bytes causes result
to exceed 'INT_MAX' [-Wformat-overflow=]
Andreas.
I've noticed the same errors on arm* targets, if it's easier to reproduce.
Thanks. I committed a trivial fix for this on Monday
(https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00036.html).
I don't see the failures in recent test results for the few
ILP32 targets I've checked so I'm hoping they're gone but if
they persist on some others please let me know.
Indeed, I confirm your commit r247444 fixed the error.
I didn't notice your message because it was in a different thread.
Thanks,
Christophe
Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 3 May 2017 at 16:54, Martin Sebor wrote:
> On 05/03/2017 08:22 AM, Christophe Lyon wrote:
>>
>> Hi,
>>
>>
>> On 29 April 2017 at 19:56, Andreas Schwab wrote:
>>>
>>> On Apr 28 2017, Martin Sebor wrote:
>>>
+void test_width_and_precision_out_of_range (char *d)
+{
+#if __LONG_MAX__ == 2147483647
+# define MAX_P1_STR "2147483648"
+#elif __LONG_MAX__ == 9223372036854775807
+# define MAX_P1_STR "9223372036854775808"
+#endif
+
+ T ("%" MAX_P1_STR "i", 0);/* { dg-warning "width out of range" }
*/
+ /* { dg-warning "result to exceed .INT_MAX. " "" { target *-*-* } .-1
} */
+ T ("%." MAX_P1_STR "i", 0); /* { dg-warning "precision out of
range" } */
>>>
>>>
>>> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line
>>> 123)
>>> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line
>>> 125)
>>> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
>>> Excess errors:
>>>
>>> /daten/aranym/gcc/gcc-20170429/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:125:3:
>>> warning: '%.2147483648i' directive output of 2147483648 bytes causes result
>>> to exceed 'INT_MAX' [-Wformat-overflow=]
>>>
>>> Andreas.
>>
>>
>> I've noticed the same errors on arm* targets, if it's easier to reproduce.
>
>
> Thanks. I committed a trivial fix for this on Monday
> (https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00036.html).
> I don't see the failures in recent test results for the few
> ILP32 targets I've checked so I'm hoping they're gone but if
> they persist on some others please let me know.
>
Indeed, I confirm your commit r247444 fixed the error.
I didn't notice your message because it was in a different thread.
Thanks,
Christophe
> Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 05/03/2017 08:22 AM, Christophe Lyon wrote:
Hi,
On 29 April 2017 at 19:56, Andreas Schwab wrote:
On Apr 28 2017, Martin Sebor wrote:
+void test_width_and_precision_out_of_range (char *d)
+{
+#if __LONG_MAX__ == 2147483647
+# define MAX_P1_STR "2147483648"
+#elif __LONG_MAX__ == 9223372036854775807
+# define MAX_P1_STR "9223372036854775808"
+#endif
+
+ T ("%" MAX_P1_STR "i", 0);/* { dg-warning "width out of range" } */
+ /* { dg-warning "result to exceed .INT_MAX. " "" { target *-*-* } .-1 } */
+ T ("%." MAX_P1_STR "i", 0); /* { dg-warning "precision out of range" } */
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 123)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 125)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170429/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:125:3:
warning: '%.2147483648i' directive output of 2147483648 bytes causes result to
exceed 'INT_MAX' [-Wformat-overflow=]
Andreas.
I've noticed the same errors on arm* targets, if it's easier to reproduce.
Thanks. I committed a trivial fix for this on Monday
(https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00036.html).
I don't see the failures in recent test results for the few
ILP32 targets I've checked so I'm hoping they're gone but if
they persist on some others please let me know.
Martin
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Hi,
On 29 April 2017 at 19:56, Andreas Schwab wrote:
> On Apr 28 2017, Martin Sebor wrote:
>
>> +void test_width_and_precision_out_of_range (char *d)
>> +{
>> +#if __LONG_MAX__ == 2147483647
>> +# define MAX_P1_STR "2147483648"
>> +#elif __LONG_MAX__ == 9223372036854775807
>> +# define MAX_P1_STR "9223372036854775808"
>> +#endif
>> +
>> + T ("%" MAX_P1_STR "i", 0);/* { dg-warning "width out of range" } */
>> + /* { dg-warning "result to exceed .INT_MAX. " "" { target *-*-* } .-1 } */
>> + T ("%." MAX_P1_STR "i", 0); /* { dg-warning "precision out of range" }
>> */
>
> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 123)
> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 125)
> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170429/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:125:3:
> warning: '%.2147483648i' directive output of 2147483648 bytes causes result
> to exceed 'INT_MAX' [-Wformat-overflow=]
>
> Andreas.
I've noticed the same errors on arm* targets, if it's easier to reproduce.
Thanks,
Christophe
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On Apr 28 2017, Martin Sebor wrote:
> +void test_width_and_precision_out_of_range (char *d)
> +{
> +#if __LONG_MAX__ == 2147483647
> +# define MAX_P1_STR "2147483648"
> +#elif __LONG_MAX__ == 9223372036854775807
> +# define MAX_P1_STR "9223372036854775808"
> +#endif
> +
> + T ("%" MAX_P1_STR "i", 0);/* { dg-warning "width out of range" } */
> + /* { dg-warning "result to exceed .INT_MAX. " "" { target *-*-* } .-1 } */
> + T ("%." MAX_P1_STR "i", 0); /* { dg-warning "precision out of range" } */
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 123)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 125)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170429/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c:125:3:
warning: '%.2147483648i' directive output of 2147483648 bytes causes result to
exceed 'INT_MAX' [-Wformat-overflow=]
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 04/28/2017 12:05 PM, Martin Sebor wrote:
So the initialization could be done once per translation unit rather
than once per function -- assuming the target character set doesn't
change within a translation unit.
That seems like it ought to be easy.
It is easy. I was going to respond by saying "It already is done
that way" because I implemented it in the first patch (by checking
the mapping for '%'. But now I see I accidentally removed the code
in the update while exploring ways to optimize it some more. Sigh.
Let me put it back.
:-)
+ set corresponding to the string TARGSTR consisting of characters in
+ the execution character set. */
+
+static const char*
+target_to_host (const char *targstr)
+{
+ /* The interesting subset of source and execution characters are
+ the same so no conversion is necessary. */
+ if (target_to_host_charmap['\0'] == 1)
+return targstr;
+
+ /* Convert the initial substring of TARGSTR to the corresponding
+ characters in the host set, appending "..." if TARGSTR is too
+ long to fit. Using the static buffer assumes the function is
+ not called in between sequence points (which it isn't). */
+ static char hostr[32];
+ for (char *ph = hostr; ; ++targstr)
+{
+ *ph++ = target_to_host (*targstr);
+ if (!*targstr)
+break;
+
+ if (ph - hostr == sizeof hostr - 4)
+{
+ *ph = '\0';
+ strcat (ph, "...");
+ break;
+}
+}
+
+ return hostr;
Ewww. I guess the alternative would be something like:
Expand the return value to include a indicator of whether or not the
original string was returned (common case) or if a new string was
returned and thus needs to be deallocated by the caller.
That's probably pretty unpleasant given we don't have a central place
where we call target_to_host, so the caller side would be much uglier.
Are there any downstream impacts when the string is too long to covert
other than not warning for things which were unconverted?
The function is only used when printing the text of the directive
in the warning. It doesn't prevent the warnings, it just truncates
them.
Noted. Thanks.
I don't like returning a pointer to a static buffer but given that
the scope of the function is limited to the pass it seems fairly
safe. Another alternative would be to pass in a buffer and its
size. That shouldn't complicate the caller too much. The easiest,
cleanest, and safest solution by far is to return a std::string,
but I have the impression that would be against GCC convention of
avoiding the STL.
That's what caught my eye. I don't generally like that either.
Putting the buffer into the caller is better. Thanks for doing that.
Attached is an updated patch with these two tweaks.
Martin
gcc-80523.diff
PR tree-optimization/80523 - -Wformat-overflow doesn't consider -fexec-charset
gcc/ChangeLog:
PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.
gcc/testsuite/ChangeLog:
PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.
OK.
jeff
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 04/28/2017 10:22 AM, Jeff Law wrote:
On 04/27/2017 03:05 PM, Martin Sebor wrote:
On 04/26/2017 04:34 PM, Jakub Jelinek wrote:
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that
needs to do
something with the exec charset chars caches its own results of the
langhook?
The biggest overhead is calling lang_hooks.to_target_charset
to initialize each character in the source set. That could
be avoided if there were a way to determine in the middle-end
whether the input and target charsets are the same, but I don't
see one. Alternatively, it could be optimized by converting
all the characters in one shot as a string, but without adding
a new target hook to do that I don't see how to do that either.
It might be a useful enhancement but given the scope it feels
like it should be done independently of this change. But if
you know of a solution that escaped me please let me know.
The overhead of the additional processing should be negligible
irrespective of whether the charsets are different or the same
(all it entails is indexing into a table).
So the initialization could be done once per translation unit rather
than once per function -- assuming the target character set doesn't
change within a translation unit.
That seems like it ought to be easy.
It is easy. I was going to respond by saying "It already is done
that way" because I implemented it in the first patch (by checking
the mapping for '%'. But now I see I accidentally removed the code
in the update while exploring ways to optimize it some more. Sigh.
Let me put it back.
+ set corresponding to the string TARGSTR consisting of characters in
+ the execution character set. */
+
+static const char*
+target_to_host (const char *targstr)
+{
+ /* The interesting subset of source and execution characters are
+ the same so no conversion is necessary. */
+ if (target_to_host_charmap['\0'] == 1)
+return targstr;
+
+ /* Convert the initial substring of TARGSTR to the corresponding
+ characters in the host set, appending "..." if TARGSTR is too
+ long to fit. Using the static buffer assumes the function is
+ not called in between sequence points (which it isn't). */
+ static char hostr[32];
+ for (char *ph = hostr; ; ++targstr)
+{
+ *ph++ = target_to_host (*targstr);
+ if (!*targstr)
+break;
+
+ if (ph - hostr == sizeof hostr - 4)
+{
+ *ph = '\0';
+ strcat (ph, "...");
+ break;
+}
+}
+
+ return hostr;
Ewww. I guess the alternative would be something like:
Expand the return value to include a indicator of whether or not the
original string was returned (common case) or if a new string was
returned and thus needs to be deallocated by the caller.
That's probably pretty unpleasant given we don't have a central place
where we call target_to_host, so the caller side would be much uglier.
Are there any downstream impacts when the string is too long to covert
other than not warning for things which were unconverted?
The function is only used when printing the text of the directive
in the warning. It doesn't prevent the warnings, it just truncates
them. I think the truncation beyond a certain length is a good
thing regardless of the conversion. Without it, the warning might
end up printing thousands of lines of text, e.g., in
sprintf (d, "thousands of lines of text...");
I don't like returning a pointer to a static buffer but given that
the scope of the function is limited to the pass it seems fairly
safe. Another alternative would be to pass in a buffer and its
size. That shouldn't complicate the caller too much. The easiest,
cleanest, and safest solution by far is to return a std::string,
but I have the impression that would be against GCC convention of
avoiding the STL.
Attached is an updated patch with these two tweaks.
Martin
PR tree-optimization/80523 - -Wformat-overflow doesn't consider -fexec-charset
gcc/ChangeLog:
PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.
gcc/testsuite/ChangeLog:
PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index d3771dd..3e1c119 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -66,6 +66,7 @@ along with GCC; see the file COPYING3. If not see
#include "calls.h"
#include "cfgloop.h"
#include "intl.h"
+#include "langhooks.h"
#include "builtins.h"
#include "stor-layout.h"
@@ -273,6 +274,158 @@ target_size_max ()
return tree_to_uhwi (TYPE_MAX_VALUE (size_type_node));
}
+/* A straightforward mapping from the execution character set to the host
+
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 04/28/2017 10:27 AM, Jakub Jelinek wrote: On Fri, Apr 28, 2017 at 10:22:29AM -0600, Jeff Law wrote: So the initialization could be done once per translation unit rather than once per function -- assuming the target character set doesn't change within a translation unit. That seems like it ought to be easy. The table-lookup seems like a reasonable cost and I don't think we should litter the code with conditionals to conditionally lookup based on whether or not the charsets are the same. One option would be to have the cache array initialized say to 0 for all chars except for % (which can be taken from target_percent or how is that called), and then query (and cache) chars you need (you don't need anything until % is seen, then obviously you need to translate chars following that until end of the format string is recognized, then again skip until next % etc. That seems like a significant over-complication for little real world benefit. Jeff
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On Fri, Apr 28, 2017 at 10:22:29AM -0600, Jeff Law wrote: > So the initialization could be done once per translation unit rather than > once per function -- assuming the target character set doesn't change within > a translation unit. > > That seems like it ought to be easy. > > The table-lookup seems like a reasonable cost and I don't think we should > litter the code with conditionals to conditionally lookup based on whether > or not the charsets are the same. One option would be to have the cache array initialized say to 0 for all chars except for % (which can be taken from target_percent or how is that called), and then query (and cache) chars you need (you don't need anything until % is seen, then obviously you need to translate chars following that until end of the format string is recognized, then again skip until next % etc. And/or enhance libcpp and the langhooks so that they will tell you when the exec charset is identical to host (or at least the subset format strings care about). Jakub
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 04/27/2017 03:05 PM, Martin Sebor wrote:
On 04/26/2017 04:34 PM, Jakub Jelinek wrote:
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that needs
to do
something with the exec charset chars caches its own results of the
langhook?
The biggest overhead is calling lang_hooks.to_target_charset
to initialize each character in the source set. That could
be avoided if there were a way to determine in the middle-end
whether the input and target charsets are the same, but I don't
see one. Alternatively, it could be optimized by converting
all the characters in one shot as a string, but without adding
a new target hook to do that I don't see how to do that either.
It might be a useful enhancement but given the scope it feels
like it should be done independently of this change. But if
you know of a solution that escaped me please let me know.
The overhead of the additional processing should be negligible
irrespective of whether the charsets are different or the same
(all it entails is indexing into a table).
So the initialization could be done once per translation unit rather
than once per function -- assuming the target character set doesn't
change within a translation unit.
That seems like it ought to be easy.
The table-lookup seems like a reasonable cost and I don't think we
should litter the code with conditionals to conditionally lookup based
on whether or not the charsets are the same.
I agree that sharing data would be a good thing but as it is,
the little that can be be shared already is (the target_percent
character with builtins.c). The rest of it (i.e., the mapping)
is only being used by gimple-ssa-sprintf.c.
If we ever get to a point where we need this level of mapping elsewhere,
we can always pull the code out of gimple-ssa-sprintf into a more
generic location. I don't think we need to over-engineering sharing
into this right now.
If/when -Wformat is ever enhanced to handle -fexec-charset, or
if another area needs to, then implementinng some more general
would be worthwhile.
Right.
Attached is an updated patch with just the overflow handling
suggested by Joseph.
Martin
gcc-80523.diff
PR tree-optimization/80523 - -Wformat-overflow doesn't consider -fexec-charset
gcc/ChangeLog:
PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.
gcc/testsuite/ChangeLog:
PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.
Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c(revision 247263)
+++ gcc/gimple-ssa-sprintf.c(working copy)
+/* Return a string consisting of charavters in the host source character
s/charavters/characters/
+ set corresponding to the string TARGSTR consisting of characters in
+ the execution character set. */
+
+static const char*
+target_to_host (const char *targstr)
+{
+ /* The interesting subset of source and execution characters are
+ the same so no conversion is necessary. */
+ if (target_to_host_charmap['\0'] == 1)
+return targstr;
+
+ /* Convert the initial substring of TARGSTR to the corresponding
+ characters in the host set, appending "..." if TARGSTR is too
+ long to fit. Using the static buffer assumes the function is
+ not called in between sequence points (which it isn't). */
+ static char hostr[32];
+ for (char *ph = hostr; ; ++targstr)
+{
+ *ph++ = target_to_host (*targstr);
+ if (!*targstr)
+ break;
+
+ if (ph - hostr == sizeof hostr - 4)
+ {
+ *ph = '\0';
+ strcat (ph, "...");
+ break;
+ }
+}
+
+ return hostr;
Ewww. I guess the alternative would be something like:
Expand the return value to include a indicator of whether or not the
original string was returned (common case) or if a new string was
returned and thus needs to be deallocated by the caller.
That's probably pretty unpleasant given we don't have a central place
where we call target_to_host, so the caller side would be much uglier.
Are there any downstream impacts when the string is too long to covert
other than not warning for things which were unconverted?
Jeff
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On 04/26/2017 04:34 PM, Jakub Jelinek wrote:
On Wed, Apr 26, 2017 at 10:26:56PM +, Joseph Myers wrote:
On Wed, 26 Apr 2017, Martin Sebor wrote:
Testing my solution for bug 77671 (missing -Wformat-overflow
sprintf with "%s") caused a regression in the charset/builtin2.c
test for bug 25120 (builtin *printf handlers are confused by
-fexec-charset). That led me to realize that like -Wformat
itself, the whole gimple-ssa-sprintf pass is oblivious to
potential differences between the source character set on
the host and the execution character set on the target. As
a result, when the host and target sets are different, the
pass misinterprets ordinary format characters as special
(e.g., parts of directives) and vice versa.
The attached patch implements a simple solution to this problem
by introducing a mapping between the two sets.
target_strtol10 appears to do no checking for overflow, which I'd expect
would result in nonsensical results for large width values overflowing
host long (whereas strtol would reliably return LONG_MAX in such cases).
Thanks, good catch! I've added overflow detection (along with
a warning) in the updated version.
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that needs to do
something with the exec charset chars caches its own results of the
langhook?
The biggest overhead is calling lang_hooks.to_target_charset
to initialize each character in the source set. That could
be avoided if there were a way to determine in the middle-end
whether the input and target charsets are the same, but I don't
see one. Alternatively, it could be optimized by converting
all the characters in one shot as a string, but without adding
a new target hook to do that I don't see how to do that either.
It might be a useful enhancement but given the scope it feels
like it should be done independently of this change. But if
you know of a solution that escaped me please let me know.
The overhead of the additional processing should be negligible
irrespective of whether the charsets are different or the same
(all it entails is indexing into a table).
I agree that sharing data would be a good thing but as it is,
the little that can be be shared already is (the target_percent
character with builtins.c). The rest of it (i.e., the mapping)
is only being used by gimple-ssa-sprintf.c.
If/when -Wformat is ever enhanced to handle -fexec-charset, or
if another area needs to, then implementinng some more general
would be worthwhile.
Attached is an updated patch with just the overflow handling
suggested by Joseph.
Martin
PR tree-optimization/80523 - -Wformat-overflow doesn't consider -fexec-charset
gcc/ChangeLog:
PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.
gcc/testsuite/ChangeLog:
PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.
Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c (revision 247263)
+++ gcc/gimple-ssa-sprintf.c (working copy)
@@ -66,6 +66,7 @@ along with GCC; see the file COPYING3. If not see
#include "calls.h"
#include "cfgloop.h"
#include "intl.h"
+#include "langhooks.h"
#include "builtins.h"
#include "stor-layout.h"
@@ -273,6 +274,143 @@ target_size_max ()
return tree_to_uhwi (TYPE_MAX_VALUE (size_type_node));
}
+/* A straightforward mapping from the execution character set to the host
+ character set indexed by execution character. */
+
+static char target_to_host_charmap[256];
+
+/* Initialize a mapping from the execution character set to the host
+ character set. */
+
+static bool
+init_target_to_host_charmap ()
+{
+ if (!init_target_chars ())
+return false;
+
+ /* The subset of the source character set used by printf conversion
+ specifications (strictly speaking, not all letters are used but
+ they are included here for the sake of simplicity). The dollar
+ sign must be included even though it's not in the basic source
+ character set. */
+ const char srcset[] = " 0123456789!\"#%&'()*+,-./:;<=>?[\\]^_{|}~$"
+"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
+
+ /* Set the mapping for all characters to some ordinary value (i,e.,
+ not none used in printf conversion specifications) and overwrite
+ those that are used by conversion specifications to their
+ corresponding values. */
+ memset (target_to_host_charmap + 1, '?', sizeof target_to_host_charmap - 1);
+
+ /* Are the two sets of characters the same? */
+ bool all_same_p = true;
+
+ for (const char *pc = srcset; *pc; ++pc)
+{
+ /* Slice off the high end bits in case target charac
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On Wed, Apr 26, 2017 at 10:26:56PM +, Joseph Myers wrote: > On Wed, 26 Apr 2017, Martin Sebor wrote: > > > Testing my solution for bug 77671 (missing -Wformat-overflow > > sprintf with "%s") caused a regression in the charset/builtin2.c > > test for bug 25120 (builtin *printf handlers are confused by > > -fexec-charset). That led me to realize that like -Wformat > > itself, the whole gimple-ssa-sprintf pass is oblivious to > > potential differences between the source character set on > > the host and the execution character set on the target. As > > a result, when the host and target sets are different, the > > pass misinterprets ordinary format characters as special > > (e.g., parts of directives) and vice versa. > > > > The attached patch implements a simple solution to this problem > > by introducing a mapping between the two sets. > > target_strtol10 appears to do no checking for overflow, which I'd expect > would result in nonsensical results for large width values overflowing > host long (whereas strtol would reliably return LONG_MAX in such cases). Also, can't there be a way to shortcut all this processing if the charsets are the same? And is it a good idea if every pass that needs to do something with the exec charset chars caches its own results of the langhook? Jakub
Re: [PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
On Wed, 26 Apr 2017, Martin Sebor wrote: > Testing my solution for bug 77671 (missing -Wformat-overflow > sprintf with "%s") caused a regression in the charset/builtin2.c > test for bug 25120 (builtin *printf handlers are confused by > -fexec-charset). That led me to realize that like -Wformat > itself, the whole gimple-ssa-sprintf pass is oblivious to > potential differences between the source character set on > the host and the execution character set on the target. As > a result, when the host and target sets are different, the > pass misinterprets ordinary format characters as special > (e.g., parts of directives) and vice versa. > > The attached patch implements a simple solution to this problem > by introducing a mapping between the two sets. target_strtol10 appears to do no checking for overflow, which I'd expect would result in nonsensical results for large width values overflowing host long (whereas strtol would reliably return LONG_MAX in such cases). -- Joseph S. Myers jos...@codesourcery.com
[PATCH] have -Wformat-overflow handle -fexec-charset (PR 80503)
Testing my solution for bug 77671 (missing -Wformat-overflow
sprintf with "%s") caused a regression in the charset/builtin2.c
test for bug 25120 (builtin *printf handlers are confused by
-fexec-charset). That led me to realize that like -Wformat
itself, the whole gimple-ssa-sprintf pass is oblivious to
potential differences between the source character set on
the host and the execution character set on the target. As
a result, when the host and target sets are different, the
pass misinterprets ordinary format characters as special
(e.g., parts of directives) and vice versa.
The attached patch implements a simple solution to this problem
by introducing a mapping between the two sets.
Martin
PR tree-optimization/80523 - -Wformat-overflow doesn't consider -fexec-charset
gcc/ChangeLog:
PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.
gcc/testsuite/ChangeLog:
PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.
Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c (revision 247263)
+++ gcc/gimple-ssa-sprintf.c (working copy)
@@ -66,6 +66,7 @@ along with GCC; see the file COPYING3. If not see
#include "calls.h"
#include "cfgloop.h"
#include "intl.h"
+#include "langhooks.h"
#include "builtins.h"
#include "stor-layout.h"
@@ -273,6 +274,118 @@ target_size_max ()
return tree_to_uhwi (TYPE_MAX_VALUE (size_type_node));
}
+/* A straightforward mapping from the execution character set to the host
+ character set indexed by execution character. */
+
+static char target_to_host_charmap[256];
+
+/* Initialize a mapping from the execution character set to the host
+ character set. */
+
+static bool
+init_target_to_host_charmap ()
+{
+ if (!init_target_chars ())
+return false;
+
+ /* The subset of the source character set used by printf conversion
+ specifications (strictly speaking, not all letters are used but
+ they are included here for the sake of simplicity). The dollar
+ sign must be included even though it's not in the basic source
+ character set. */
+ const char srcset[] = " ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+"abcdefghijklmnopqrstuvwxyz0123456789#%'*+-.$";
+
+ /* Set the mapping for all characters to some ordinary value (i,e.,
+ not one used in printf conversion specifications) and overwrite
+ those that are used by conversion specifications with their
+ corresponding values. */
+ memset (target_to_host_charmap + 1, '?', sizeof target_to_host_charmap - 1);
+
+ for (const char *pc = srcset; *pc; ++pc)
+{
+ /* Slice off the high end bits in case target characters are
+ signed. All values are expected to be non-nul, otherwise
+ there's a problem. */
+ if (unsigned char tc = lang_hooks.to_target_charset (*pc))
+ target_to_host_charmap[tc] = *pc;
+ else
+ return false;
+}
+
+ return true;
+}
+
+/* Return the host source character corresponding to the character
+ CH in the execution character set if one exists, or some innocuous
+ (non-special, non-nul) source character otherwise. */
+
+static inline int
+target_to_host (unsigned char ch)
+{
+ return target_to_host_charmap[ch];
+}
+
+/* Return a string consisting of characters in the host source character
+ set corresponding to the string TARGSTR consisting of characters in
+ the execution character set. */
+
+static const char*
+target_to_host (const char *targstr)
+{
+ if (target_to_host ('%') == '%')
+return targstr;
+
+ static char hostr[32];
+ for (char *ph = hostr; *targstr; ++targstr)
+{
+ *ph++ = target_to_host (*targstr);
+ if (!*targstr)
+ break;
+
+ if (ph - hostr == sizeof hostr - 4)
+ {
+ *ph = '\0';
+ strcat (ph, "...");
+ break;
+ }
+}
+
+ return hostr;
+}
+
+/* Convert the sequence of decimal digits in the execution character
+ starting at S to a long, just like strtol does. Return the result
+ and set *END to one past the last converted character. */
+
+static inline long
+target_strtol10 (const char *s, char** end)
+{
+ /* As an optimization use the host strtol if the digit zero is the same
+ in the host and target character sets. */
+ if ('0' == target_to_host ('0'))
+return strtol (s, end, 10);
+
+ long val = 0;
+ for ( ; ; )
+{
+ unsigned char c = target_to_host (*s);
+ if (ISDIGIT (c))
+ {
+ val *= 10;
+ val += c - '0';
+ }
+ else
+ break;
+
+ ++s;
+}
+
+ *end = const_cast(s);
+
+ return val;
+}
+
/* Return the constant initial value of DECL if available or DECL
otherwise. Same as the synonymous function in c/c-typeck.c. */
@@ -2289,7 +2402,7 @@ maybe_warn (substring_loc &dirloc
