On Wed, Jul 27, 2022 at 06:41:09AM +0000, Richard Biener via Gcc-patches wrote: > On Tue, 26 Jul 2022, Marek Polacek wrote: > > > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r > > conversion by creating a NOP_EXPR. For e.g. > > > > const int i = i; > > > > that means that the DECL_INITIAL is '(int) i' and not 'i' anymore. > > Consequently, we don't suppress_warning here: > > > > 711 case DECL_EXPR: > > 715 if (VAR_P (DECL_EXPR_DECL (*expr_p)) > > 716 && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p)) > > 717 && !TREE_STATIC (DECL_EXPR_DECL (*expr_p)) > > 718 && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL > > (*expr_p)) > > 719 && !warn_init_self) > > 720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self); > > > > because of the check on line 718 -- (int) i is not i. So -Wno-init-self > > doesn't disable the warning as it's supposed to. > > > > The following patch fixes it...except it doesn't, for volatile variables > > in C++. The problem is that for > > > > volatile int k = k; > > > > we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic > > initialization. So there's no DECL_INITIAL and the suppress_warning > > call above is never done. I suppose we could amend get_no_uninit_warning > > to return true for volatile-qualified expressions. I mean, can we ever > > say for a fact that a volatile variable is uninitialized? > > As I said in the bug the bug is probably that we emit uninitialized > diagnostics for volatiles at all?
Non-volatile const variables also have this problem, so I think we still need this patch (or something like it). > OTOH 'volatile' is recommended > for vars live around setjmp/longjmp and there diagnostics would be > welcome. It's probably the difference between "compiler-hands-off" > and "hardware-controlled" :/ Ah, you're right. Then I guess it's better to leave the warning be, (but we still have a discrepancy between C and C++). Marek
