[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|6.4 |8.0

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #18 from Jeffrey A. Law  ---
I really don't see anything we can do here without more information.

As Richi noted, the assembly codes don't include 
Chi2MeasurementEstimator::estimate.

There's no runnable testcase.

The included .s files aren't particularly useful.  

I'm going to keep this open for now, but we really need David to engage here so
that we can dig into the issue.  If we can't get more information from David,
we'll have to close with insufficient data.

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
David, can you reproduce with latest trunk?  Any chance to have some reduced
self-contained testcase (including main that invokes it)?

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.3 |6.4

--- Comment #16 from Jakub Jelinek  ---
GCC 6.3 is being released, adjusting target milestone.

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-06
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #15 from Aldy Hernandez  ---
David, could you verify that this is still happening on trunk?

I can't reproduce on a ppc64le box with a stage1 build.  Compilation succeeds:

$ ~/gcc/configure --disable-multilib --disable-bootstrap 
$ make all-gcc
$ cd gcc
$ ./xg++ -B./ -O2 ~/MuonTrajectoryUpdator2.ii -c -w
/home/aldyh/MuonTrajectoryUpdator2.ii: In instantiation of ‘class
Basic2DVector’:
/home/aldyh/MuonTrajectoryUpdator2.ii:47851:11:   required from here
/home/aldyh/MuonTrajectoryUpdator2.ii:47371:7: note: the layout of aggregates
containing vectors with 32-byte alignment has changed in GCC 5
 class Basic2DVector {
   ^
$

But perhaps what you are mean is that there is a segfault executing your
program, not compiling it.  In which case, could you reduce your testcase (a
lot :)), and provide a standalone testcase that runs, that we could use to
reproduce the problem?

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to fail||6.2.0

--- Comment #14 from Richard Biener  ---
Actually P2, we've released 6.2 with this bug so it doesn't block a 6.3
release.  It's also still UNCONFIRMED (we prefer to leave those at P3).

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

--- Comment #13 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #11)
> CCing libstdc++ people -- not sure if std::stable_sort (on which kind of
> collection?) is safe for std::shared_ptr.

It's required to work correctly. It should be equivalent to sorting
TrackingRecHit* pointers.

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

--- Comment #12 from David Abdurachmanov  
---
Looks to be std::vector (aka
ConstRecHitContainer).

Here is the class and typedef for the containers:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/DataFormats/TrackingRecHit/interface/TrackingRecHit.h#L35

Here we call sort which is a member function (at the end of the file):
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L119

That member function calls stable_sort.

stable_sort is called here:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L260

This is the comparison function used:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/interface/MuonTrajectoryUpdator.h#L98

Will try to check where dtor is happening.

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Richard Biener  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
CCing libstdc++ people -- not sure if std::stable_sort (on which kind of
collection?) is safe for std::shared_ptr.

Would be nice if you could track down where the object gets destroyed btw
(maybe use a watchpoint on the vtable slot?)

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

--- Comment #10 from David Abdurachmanov  
---
We have been bitten by DSE with TBB already on GCC 6.2.0.

I decided to try -fno-lifetime-dse on the first bad commit and got some
surprising results. Now it fails with:

pure virtual method called
terminate called without an active exception

In this case we have a standard library container with 7 elements,
std::shared_ptr, where TrackingRecHit is abstract class, which
has:

  virtual int dimension() const = 0;

If I dump the actual type: typeid(*(x.get())).name() the actual object is of
MuonTransientTrackingRecHit type.

Then the code does std::stable_sort on the collection and now in some cases
MuonTransientTrackingRecHit changes to TrackingRecHit (abstract class). Thus we
are really calling pure virtual method.

This does not happen on x86_64.

I guess, this could be caused by actual MuonTransientTrackingRecHit being
destroyed if the last std::shared_ptr point to it goes away.

DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit

// after std::stable_sort

DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit

SIZE: 7

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493

Richard Biener  changed:

   What|Removed |Added

 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.3
Summary|[6 Regression]  |[6/7 Regression]
   |-fcrossjumping (-O2) on |-fcrossjumping (-O2) on
   |ppc64le causes segfaults|ppc64le causes segfaults
   |(jump to 0x0) (first bad|(jump to 0x0) (first bad
   |r230091)|r230091)

--- Comment #9 from Richard Biener  ---
The bisection result is odd as that only changes vectorization (whether it
happens or not), and vectorization is _not_ enabled at -O2.

The attached assembly doesn't contain Chi2MeasurementEstimator::estimate as far
as I can see.

Note that doing

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

probably has no effect on the operator itself but it prevents inlining it.
Are BOOST_ASSERT assertions enabled?  Can you enable them _and_ compile
with -fno-delete-null-pointer-checks?

Btw, another not mentioned issue people hit with GCC 6 (see also
https://gcc.gnu.org/gcc-6/porting_to.html) is dead code elimination around
constructors/destructors.  Use -flifetime-dse=1 to restore GCC 5 behavior
(or -fno-lifetime-dse to pre-GCC 5 behavior).