https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
Bug ID: 77493
Summary: [6 Regression] -fcrossjumping (-O2) on ppc64le causes
segfaults (jump to 0x0) (first bad r230091)
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 39568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39568&action=edit
pre-processed source code
Finally I moved our PPC64LE builds to GCC 6.2.0 from 5.3.0 and quickly found
that majority of workflows are segfaulting in a similar strange manner.
Quickly noticed that this starts happening with -O2, works fine with -O1.
Started bisection of GCC -O2 flags and it -fcrossjumping is the causing it.
Found that most issues are caused by MuonTrajectoryUpdator.o. Then started
hunting for the function causing regression. Found that it was
boost/smart_ptr/intrusive_ptr.hpp (from 1.57.0 version).
Doing the following resolves the issue:
165 #pragma GCC push_options
166 #pragma GCC optimize ("no-crossjumping")
167
168 T & operator*() const
169 {
170 BOOST_ASSERT( px != 0 );
171 return *px;
172 }
173
174 #pragma GCC pop_options
Started GCC bisection and did it twice with the same result.
First bad commit r230091 or b873d7f7eba25120074b3d74add21224e860df43
Last good commit r230090 or 79a77fee9f8eebf5bdd2b4868a0ba18b3ad3b74d
Does not happen on x86_64 and I still didn't move AArch64 to GCC 6.2.0.
This is quick look into GDB:
Dump of assembler code for function
Chi2MeasurementEstimator::estimate(TrajectoryStateOnSurface const&,
TrackingRecHit const&) const:
0x00003fff985a7e40 <+0>: addis r2,r12,4
0x00003fff985a7e44 <+4>: addi r2,r2,-320
=> 0x00003fff985a7e48 <+8>: mflr r0
0x00003fff985a7e4c <+12>: std r27,-40(r1)
0x00003fff985a7e50 <+16>: std r28,-32(r1)
0x00003fff985a7e54 <+20>: mr r28,r4
0x00003fff985a7e58 <+24>: std r30,-16(r1)
0x00003fff985a7e5c <+28>: std r31,-8(r1)
0x00003fff985a7e60 <+32>: mr r27,r3
0x00003fff985a7e64 <+36>: mr r3,r5
0x00003fff985a7e68 <+40>: std r29,-24(r1)
0x00003fff985a7e6c <+44>: mr r31,r5
0x00003fff985a7e70 <+48>: std r0,16(r1)
0x00003fff985a7e74 <+52>: stdu r1,-288(r1)
0x00003fff985a7e78 <+56>: ld r9,0(r5) // beginning of TrackingRecHit
0x00003fff985a7e7c <+60>: ld r4,88(r9) // we load 0x0 (loading
function address from vtable?)
0x00003fff985a7e80 <+64>: std r2,24(r1)
0x00003fff985a7e84 <+68>: mtctr r4 // we load CTR with 0x0
0x00003fff985a7e88 <+72>: mr r12,r4
0x00003fff985a7e8c <+76>: bctrl // ucondition branch to CTR
with is 0x0
0x00003fff985a7e90 <+80>: ld r2,24(r1)
0x00003fff985a7e94 <+84>: li r5,21
0x00003fff985a7e98 <+88>: mr r30,r3
Code looks like:
34 std::pair<bool,double>
35 Chi2MeasurementEstimator::estimate(const TrajectoryStateOnSurface& tsos,
36 const TrackingRecHit& aRecHit) const {
37 switch (aRecHit.dimension()) {
38 case 1: return returnIt(lestimate<1>(tsos,aRecHit));
39 case 2: return returnIt(lestimate<2>(tsos,aRecHit));
40 case 3: return returnIt(lestimate<3>(tsos,aRecHit));
41 case 4: return returnIt(lestimate<4>(tsos,aRecHit));
42 case 5: return returnIt(lestimate<5>(tsos,aRecHit));
43 }
44 throw cms::Exception("RecHit of invalid size (not 1,2,3,4,5)");
45 }
We are failing trying to make this call: aRecHit.dimension() [line 37].
