public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959
@ 2020-09-08 22:06 ibuclaw at gdcproject dot org
2020-09-09 6:47 ` [Bug d/96989] " rguenth at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: ibuclaw at gdcproject dot org @ 2020-09-08 22:06 UTC (permalink / raw)
To: gcc-bugs
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'.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
@ 2020-09-09 6:47 ` rguenth at gcc dot gnu.org
2020-09-09 9:11 ` ibuclaw at gdcproject dot org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-09-09 6:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
2020-09-09 6:47 ` [Bug d/96989] " rguenth at gcc dot gnu.org
@ 2020-09-09 9:11 ` ibuclaw at gdcproject dot org
2020-09-09 17:11 ` msebor at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: ibuclaw at gdcproject dot org @ 2020-09-09 9:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
2020-09-09 6:47 ` [Bug d/96989] " rguenth at gcc dot gnu.org
2020-09-09 9:11 ` ibuclaw at gdcproject dot org
@ 2020-09-09 17:11 ` msebor at gcc dot gnu.org
2020-09-17 10:23 ` ibuclaw at gdcproject dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-09-09 17:11 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
` (2 preceding siblings ...)
2020-09-09 17:11 ` msebor at gcc dot gnu.org
@ 2020-09-17 10:23 ` ibuclaw at gdcproject dot org
2021-08-06 22:22 ` [Bug middle-end/96989] " msebor at gcc dot gnu.org
2021-08-06 22:24 ` msebor at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: ibuclaw at gdcproject dot org @ 2020-09-17 10:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
` (3 preceding siblings ...)
2020-09-17 10:23 ` ibuclaw at gdcproject dot org
@ 2021-08-06 22:22 ` msebor at gcc dot gnu.org
2021-08-06 22:24 ` msebor at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-08-06 22:22 UTC (permalink / raw)
To: gcc-bugs
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];
| ~^~~
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
` (4 preceding siblings ...)
2021-08-06 22:22 ` [Bug middle-end/96989] " msebor at gcc dot gnu.org
@ 2021-08-06 22:24 ` msebor at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-08-06 22:24 UTC (permalink / raw)
To: gcc-bugs
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].
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-08-06 22:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-08 22:06 [Bug d/96989] New: SSA_NAMEs in Wuninitialized warning messages after r11-959 ibuclaw at gdcproject dot org
2020-09-09 6:47 ` [Bug d/96989] " rguenth at gcc dot gnu.org
2020-09-09 9:11 ` ibuclaw at gdcproject dot org
2020-09-09 17:11 ` msebor at gcc dot gnu.org
2020-09-17 10:23 ` ibuclaw at gdcproject dot org
2021-08-06 22:22 ` [Bug middle-end/96989] " msebor at gcc dot gnu.org
2021-08-06 22:24 ` msebor at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).