Created attachment 1857122 [details] A reproducer generated from stap-session.ii using creduce. Description of problem: When attempted to address the FTBFS issue of systemtap (rhbz2046015) a newer version of systemtap with the expected fix was was put into the koji build system. All the architecture except armv7hl successfully built (https://koji.fedoraproject.org/koji/taskinfo?taskID=81941041). The armv7hl builds failed with a number of errors similar to the following: In file included from staptree.cxx:10: staptree.h: In member function 'next_statement::~next_statement()': staptree.h:841:8: error: pointer used after 'operator delete(void*, unsigned int)' [-Werror=use-after-free] 841 | struct next_statement: public statement | ^~~~~~~~~~~~~~ staptree.h:841:8: note: call to 'operator delete(void*, unsigned int)' here staptree.h: In member function 'continue_statement::~continue_statement()': staptree.h:834:8: error: pointer used after 'operator delete(void*, unsigned int)' [-Werror=use-after-free] 834 | struct continue_statement: public statement | ^~~~~~~~~~~~~~~~~~ Florian Weimer suggested it might be a similar issue to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 Applied creduce to that the original 2.8MB stap-session.ii file to create a much smaller stap-session.ii file that shows the issue. The simplified example fails on armv7hl rahide but compiles fine on rawhide x86_64. Version-Release number of selected component (if applicable): gcc-c++-12.0.1-0.2.fc36.armv7hl How reproducible: Every time Steps to Reproduce: 1. copy the stap-session.ii file attached to this bug 2. g++ -Wall -Werror -O2 -c -o stap-session.o stap-session.ii Actual results: $ g++ -Wall -Werror -O2 -c -o stap-session.o stap-session.ii stap-session.ii: In destructor ‘virtual b::~b()’: stap-session.ii:5:8: error: pointer used after ‘void operator delete(void*, unsigned int)’ [-Werror=use-after-free] 5 | struct b : a {}; | ^ stap-session.ii:5:8: note: call to ‘void operator delete(void*, unsigned int)’ here cc1plus: all warnings being treated as errors Expected results: No error compiling, the same as running on rawhide x86_64. Additional info:
Already fixed on trunk.
My plan is to start another gcc build later friday evening or saturday, so it will finish (hopefully) during the weekend and be in rawhide on Monday.
This ought to be fixed in gcc-12.0.1-0.4.fc36.
*** Bug 2046967 has been marked as a duplicate of this bug. ***