https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373
Bug ID: 104373 Summary: [12 regression] bogus -Wmaybe-uninitialized warning with array new Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s...@li-snyder.org Target Milestone: --- hi - With a recent checkout of gcc12 (20220203), on a x86_64-pc-linux-gnu host, the following source gives bogus -Wmaybe-uninitialized warnings with -Wall: -------------------------------------------------------------- void* operator new[](unsigned long, void* __p); struct allocator { ~allocator(); }; void *foo (void *p) { return p ? new(p) allocator[1] : new allocator[1]; } -------------------------------------------------------------- $ g++ -Wall -c gccbug.cc gccbug.cc: In function ‘void* foo(void*)’: gccbug.cc:11:51: warning: ‘<anonymous>’ may be used uninitialized [-Wmaybe-uninitialized] 11 | return p ? new(p) allocator[1] : new allocator[1]; | ^ gccbug.cc:11:51: note: ‘<anonymous>’ was declared here 11 | return p ? new(p) allocator[1] : new allocator[1]; | ^ gccbug.cc:11:32: warning: ‘<anonymous>’ may be used uninitialized [-Wmaybe-uninitialized] 11 | return p ? new(p) allocator[1] : new allocator[1]; | ^ gccbug.cc:11:32: note: ‘<anonymous>’ was declared here 11 | return p ? new(p) allocator[1] : new allocator[1]; | ^ >From git bisect, this appears to have been introduced by this commit: commit beaee0a871b6485d20573fe050b1fd425581e56a (HEAD) Author: Jason Merrill <ja...@redhat.com> Date: Sat Jan 1 16:00:22 2022 -0500 c++: temporary lifetime with array aggr init [PR94041] The previous patch fixed temporary lifetime for aggregate initialization of classes; this one extends that fix to arrays. This specifically reverses my r74790, the patch for PR12253, which was made wrong when these semantics were specified in DR201. Since the array cleanup region encloses the regions for any temporaries, we don't need to add an additional region for the array object itself in either initialize_local_var or split_nonconstant_init; we do, however, need to tell split_nonconstant_init how to disable the cleanup once an enclosing object is fully constructed, at which point we want to run that destructor instead. FWIW, the warning goes away if the conditional expression in foo() is rewritten as an explicit if statement.