> On Dec 15, 2021, at 11:33 AM, Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
>
>> On Dec 14, 2021, at 4:06 PM, Martin Sebor <mse...@gmail.com> wrote:
>>
>>>>>>
>>>>>
>>>>> Dynamically creating the string seems quite cumbersome here, and
>>>>> it leaks the allocated block. I wonder if it might be better to
>>>>> remove the gmsgid argument from the function and assign it to
>>>>> one of the literals based on the other arguments.
>>>>>
>>>>> Since only one of var and var_name is used, I also wonder if
>>>>> the %qs form could be used for both to simplify the overall
>>>>> logic. (I.e., get the IDENTIFIER_POINTER string from var and
>>>>> use it instead of %qD).
>>> Looks like that using “%qs” + get the IDENTIFIER_POINTER string from var
>>> did not work very well for the following testing case:
>>> 1 /* PR tree-optimization/45083 */
>>> 2 /* { dg-do compile } */
>>> 3 /* { dg-options "-O2 -Wuninitialized" } */
>>> 4
>>> 5 struct S { char *a; unsigned b; unsigned c; };
>>> 6 extern int foo (const char *);
>>> 7 extern void bar (int, int);
>>> 8
>>> 9 static void
>>> 10 baz (void)
>>> 11 {
>>> 12 struct S cs[1]; /* { dg-message "was declared here" } */
>>> 13 switch (cs->b) /* { dg-warning "cs\[^\n\r\]*\\.b\[^\n\r\]*is
>>> used uninitialized" } */
>>> 14 {
>>> 15 case 101:
>>> 16 if (foo (cs->a)) /* { dg-warning "cs\[^\n\r\]*\\.a\[^\n\r\]*may
>>> be used uninitialized" } */
>>> 17 bar (cs->c, cs->b); /* { dg-warning
>>> "cs\[^\n\r\]*\\.c\[^\n\r\]*may be used uninitialized" } */
>>> 18 }
>>> 19 }
>>> 20
>>> 21 void
>>> 22 test (void)
>>> 23 {
>>> 24 baz ();
>>> 25 }
>>> For the uninitialized usages at line 13, 16, 17: the IDENTIFIER_POINTER
>>> string of var are:
>>> cs$0$b, cs$0$a ,cs$0$c
>>> However, with %qD, they are printed as cs[0].b, cs[0].a, cs[0].c
>>> But with %qs, they are printed as cs$0$b, cs$0$a ,cs$0$c.
>>> Looks like that %qD does not simplify print out the IDENTIFIER_POINTER
>>> string directly, it specially handle it for some cases.
>>> I tried to see how %qD specially handle the strings, but didn’t get it so
>>> far.
>>> Do you know where the %qD handle this case specially?
>>
>> In the front end's pretty printer where it handles %D (e.g.,
>> for C in c_tree_printer in c/c-objc-common.c). For VARs with
>> DECL_HAS_DEBUG_EXPR_P (temp) the code uses DECL_DEBUG_EXPR().
>>
>> There's also print_generic_expr_to_str(tree) that formats a decl
>> or an expression to a dynamically allocated string (the string
>> needs to be freed).
>
> Thanks a lot.
> This resolved the issue.
However, there is another testing case gcc.dg/uninit-40.c still had issue when
printing out the variable names:
24 q[0] = bar (pt + __builtin_offsetof (struct T, u.b)); /* { dg-warning
"'t\\.u\\.b' is used uninitialized" } */
I guess that there are other details I need to copy into the routine
“warn_uninit”.
So, I gave up copying the details of %D to the routine “warn_uninit”, and kept
%D for Var. that might be better.
thanks.
Qing
>
> Qing
>>
>> Martin
>>
>>> Thanks.
>>> Qing
>>>> Both are good suggestions, I will try to update the code based on this.
>>>>
>>>> Thanks again.
>>>>
>>>> Qing
