Ping in advance of stage 3 closing:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00680.html
(As the majority of the strlen issues I raised recently, this
one also came out of my testing of the -Wrray-bounds and
-Wrestrict warnings newly enhanced in GCC 8.)
On 01/09/2018 02:41 PM, Martin Sebor wrote:
I found a few problems in the previous revision:
1) It didn't handle the simple case of member arrays of const
struct objects (only member arrays of const arrays of structs
were handled).
2) The array_ctor_elt() function returned a narrow empty string
for an uninitialized CONSTRUCTOR element of any character type
when it should return the same string in the expected character
type (char, wchar_t, etc.)
3) The string_constant() function would in some cases use a byte
offset to get the initializer from a CONSTRUCTOR instead of
an array index.
The attached version 3 of the patch corrects these issues.
Retested on x86_64 and with the Glibc ToT.
After sleeping on it I realized that although enhancing
gimple_fold_builtin_strlen is an improvement, it only benefits
straight calls to strlen and nothing else. Calls to strcmp,
sprintf, or strcpy (and along with it the rest of the strlen
pass) are still expanded as if the argument were unknown. To
improve even those callers, the folding needs to be done at
a lower level (otherwise they'd all have to duplicate the same
code as gimple_fold_builtin_strlen). With that in mind I've
moved the logic to string_constant() so all of those clients
benefit.
Retested on x86_64-linux. Out of paranoia I also built and
tested the top of Glibc trunk with no unusual failures.
Martin
