[Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959

[Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

            Bug ID: 96989
           Summary: SSA_NAMEs in Wuninitialized warning messages after
                    r11-959
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

For example:
---
test.d:7:5: warning: ‘MEM[(int *)p_3 + 8B]’ is used uninitialized
test.d:8:9: warning: ‘p_4’ may be used uninitialized

Don't need any specific example, just one where a var is used after `= void'.

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
           Keywords|                            |diagnostic

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess an actual example is still helpful

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Richard Biener from comment #1)
> I guess an actual example is still helpful

After spending a few hours away and looking back, it looks like it only happens
when using any example related to pr96564 or pr96987.

This correctly prints 'a' in the warning message.
---
int fun (uint *x) {
  uint *a = void;
  return a[2];
}
---

Whereas this print '*_3'
---
import gcc.builtins;
int fun (uint *x) {
  uint *a = cast(uint*)__builtin_malloc(*x);
  return a[2];
}
---

This prints 'MEM[(int *)a_6 + 8B]'
---
import gcc.builtins;
int fun (uint *x) {
  int *a = cast(int*)__builtin_malloc(*x);
  return a[2];
}
---

So now I'm unsure whether I should wait until the broader regression in the
middle-end is fixed, or just go ahead and implement a d_tree_printer out of
necessity to prevent the middle-end warning about lowered nodes instead of the
original symbol/code it represents.

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The MEM_REF formatting done by the C and C++ pretty-printers is very basic and
doesn't always result in useful output (usually in the most interesting cases).

I posted a patch some time ago to improve it for C++ (as part of fix for an ICE
reported in pr95768):
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548698.html

Richi had some concerns with it but I think it's a significant improvement
despite them.  I plan to extend the C++-only patch to C and post it again at
some point when I'm done with stage 1 work.  If it's approved it should be
straightforward to use the same approach in the D front end (in fact, all front
ends should share the same code for this).

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Created attachment 49233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49233&action=edit
d tree printer

Very minimal tree printing support just to cover SSA_NAME and MEM_REF nodes.

I'm not entirely convinced by having to resort to this:

else if (SSA_NAME_DEF_STMT (expr)
        && is_gimple_assign (SSA_NAME_DEF_STMT (expr)))
 d_print_expression (pp, gimple_assign_rhs1 (SSA_NAME_DEF_STMT (expr)));

But it's the only place I can see to coax out the original variable from an
anonymous SSA_NAME.  Trying the same example with gcc/g++, and the warning
emits *(<unknown>) - so the problem is at least shared between all front-ends.

[Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|ibuclaw at gdcproject dot org      |unassigned at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
          Component|d                           |middle-end
   Last reconfirmed|                            |2021-08-06

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed.  The format depends on the IL which is less than ideal since that
exposes internal differences that users don't care about and that can be
confusing.

$ cat pr96989.c && gcc -S -Wall pr96989.c
int f (void)
{ 
  unsigned a[3];
  return a[2];
}

int g (unsigned n)
{ 
  int a[n];
  return a[2];
}

int h (unsigned n)
{
  unsigned *a = __builtin_malloc (n);
  return a[2];
}
pr96989.c: In function ‘f’:
pr96989.c:4:11: warning: ‘a’ is used uninitialized [-Wuninitialized]
    4 |   return a[2];
      |          ~^~~
pr96989.c:3:12: note: ‘a’ declared here
    3 |   unsigned a[3];
      |            ^
pr96989.c: In function ‘g’:
pr96989.c:10:11: warning: ‘*a[2]’ is used uninitialized [-Wuninitialized]
   10 |   return a[2];
      |          ~^~~
pr96989.c: In function ‘h’:
pr96989.c:16:11: warning: ‘*a_7 + 8’ is used uninitialized [-Wuninitialized]
   16 |   return a[2];
      |          ~^~~

[Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96989

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
The tree pretty-printer would do better by obviating the internal differences:
e.g., it could convert the IL for h():

   a = __builtin_malloc (_1);
  _2 = a + 8;
  _3 = *_2;

directly to a[2].