Bug 1544650 - g++ crash
Summary: g++ crash
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-13 07:26 UTC by Darcy
Modified: 2018-03-09 15:51 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-09 15:51:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Preprocessed text (5.71 MB, text/x-csrc)
2018-02-13 07:26 UTC, Darcy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 82795 0 None None None 2018-02-13 12:21:38 UTC

Description Darcy 2018-02-13 07:26:22 UTC
Created attachment 1395242 [details]
Preprocessed text

Description of problem:

Compiling code that worked before an OS update gives the following error:

/home/dbeurle/apps/neon/build/eigen3/src/eigen3/Eigen/src/SparseCore/SparseSelfAdjointView.h: In function ‘void Eigen::internal::permute_symm_to_symm(const MatrixType&, Eigen::SparseMatrix<typename MatrixType::Scalar, DestOrder, typename MatrixType::StorageIndex>&, const typename MatrixType::StorageIndex*) [with int SrcMode = 1; int DstMode = 2; MatrixType = Eigen::SparseMatrix<double, 0, int>; int DestOrder = 0]’:
/home/dbeurle/apps/neon/build/eigen3/src/eigen3/Eigen/src/SparseCore/SparseSelfAdjointView.h:517:6: internal compiler error: in predicate_mem_writes, at tree-if-conv.c:2252
 void permute_symm_to_symm(const MatrixType& mat, SparseMatrix<typename MatrixType::Scalar,DstOrder,typename MatrixType::StorageIndex>& _dest, const typename MatrixType::StorageIndex* perm)
      ^~~~~~~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.

Version-Release number of selected component (if applicable):

How reproducible:

Occurs on my F27 system and also a colleague's machine using F27.  He encountered this error first and when I did an dnf update I got the same behaviour.

Steps to Reproduce:
1. Latest updates
2. Compile the code
3. Observe the error
4. Follow instructions given by g++ and file a bug report

Actual results:

It fails to compile.

Expected results:

It works.

Additional info:

This error could be a bug somewhere else in the code but g++ told me to file a bug report.  Any hints on what is going on here would be appreciated.

Comment 1 Jakub Jelinek 2018-02-13 11:44:03 UTC
Reduced testcase for -march=haswell -std=gnu++17 -O3:
namespace b {
template <typename c> c d(c e, c f) {
  if (f < e)
    return f;
}
template <typename c> c &g(c &e, c &f) {
  if (e < f)
    return f;
  return e;
}
}
const int h = 1;
enum { l, n };
enum { aa };
template <typename> struct o;
struct p {
  enum { q, r };
};
template <typename> struct ab;
template <typename> struct s;
template <typename> class t;
template <typename, int = p::r> class ac;
template <typename, int ad, int u, int = 0, int = ad, int = u> class v;
template <int, int, typename> class w;
class x {
public:
  x(int);
};
template <typename y> struct ae { typedef ac<y> af; };
template <typename> struct ag {};
template <typename y> class ac<y, aa> : public s<y> {};
template <typename y> class ac<y> : ac<y, aa> {
public:
  typedef typename o<y>::ah ah;
  using ac<y, aa>::ai;
  ah &aj(long ak) { return ab<y>(ai()).aj(ak); }
  ah &operator[](long ak) { return aj(ak); }
};
template <typename y> struct s {
  y ai() {}
};
class al {
public:
  int *am;
};
template <typename y> struct ab<t<y>> {
  typedef y an;
  ab(an) {}
  typename an::ah &aj(long ak) { return ao.am[ak]; }
  al ao;
};
template <typename ah, int ap, int aq, int ar, int as, int at>
struct ab<v<ah, ap, aq, ar, as, at>> : ab<t<v<ah, ap, aq>>> {
  typedef v<ah, ap, aq> au;
  ab(au m) : ab<t<au>>(m) {}
};
template <typename, typename> struct av;
template <typename aw, typename ax, typename ay> void az(aw ba, ax bb, ay bc) {
  av<ax, ay>::bd(ba, bb, bc);
}
template <typename aw, typename ax> void az(aw ba, ax bb) {
  az(ba, bb, ag<typename aw::ah>());
}
template <typename y> class t : public ae<y>::af {
public:
  typename o<y>::ah *am();
};
template <typename be, int ad, int u, int bf, int bg, int bh>
struct o<v<be, ad, u, bf, bg, bh>> {
  typedef be ah;
};
template <typename, int ad, int u, int, int, int>
class v : public t<v<int, ad, u>> {
public:
  template <typename bi> v(const bi &);
};
template <typename y> class bj {
public:
  typename o<y>::bk bl();
};
template <int bm, int bn, typename bo> struct o<w<bm, bn, bo>> {
  typedef v<bo, bn, 1> bk;
};
template <int bm, int bn, typename> class w : public bj<w<bm, bn, int>> {};
template <typename, int = 0, typename = int> class bp;
template <typename, unsigned> class bq;
template <typename, int> class br;
class bs {
public:
  struct bt {
    typedef bq<int, 1> bu;
  };
  template <int> bt::bu bv();
};
template <typename> class bw;
template <typename y> struct o<bw<y>> : o<y> {};
template <typename> class bw : public bs {
public:
  typedef typename o<bw>::ah ah;
  typedef typename o<bw>::bx bx;
  class by;
};
template <typename y> class bw<y>::by {
public:
  by(bw, long bz) : ca(), cb(bz) {}
  void operator++() { cc++; }
  bx ak() { return cd[cc]; }
  operator bool() { return cc < ce; }
  ah ca;
  bx *cd;
  x cb;
  long cc;
  long ce;
};
template <typename y> struct ab { operator y(); };
template <typename be, int bf, typename bo> struct o<bp<be, bf, bo>> {
  typedef be ah;
  typedef bo bx;
};
template <typename, int, typename> class bp : public bw<bp<int>> {
public:
  bx *cf() {}
  bp(long, long);
};
template <typename be, int bf, typename bo>
struct ab<bp<be, bf, bo>> : ab<bw<bp<be>>> {
  ab(bp<be>);
};
template <typename, unsigned> class bq {
public:
  enum { cg } typedef ah;
  bp<int> ci();
  br<int, cg> cj(w<1, 1, int>);
  template <typename z, int ck> bq(br<z, ck> cl) { az(*this, cl); }
};
template <int, int, typename ch, int cm>
void cn(ch co, bp<typename ch::ah, cm> cp, typename ch::bx *cq) {
  typedef typename ch::bx bx;
  bp cr(cp);
  ab<ch> cs(co);
  long ct;
  v<bx, 1, 1> count(ct);
  for (bx j; ct; ++j)
    for (typename ch::by cu(cs, j); cu; ++cu) {
      bx i = cu.ak();
      if (i < j)
        continue;
      bx cv = cq ? cq[j] : j;
      bx cw = cq ? cq[i] : i;
      long k = count[b::g(cw, cv)]++;
      cr.cf()[k] = b::d(cw, cv);
    }
}
template <typename, int> class br {
public:
  bp<int> ci();
  w<1, 1, int> cq();
};
template <typename ch, int cg, typename ah> struct av<br<ch, cg>, ag<ah>> {
  template <typename cx, unsigned cy>
  static void bd(bq<cx, cy> ba, br<ch, cg> bb, ag<ah>) {
    bp cz = bb.ci();
    int da = *bb.cq().bl().am();
    cn<cg, cy>(cz, ba.ci(), &da);
  }
};
template <typename y> class db {
public:
  typedef typename o<y>::ch ch;
  enum { dc };
  template <int> void dd(ch a) {
    bp<typename ch::ah> de(0, 0);
    de.template bv<n>() = a.template bv<dc>().cj(df);
  }
  w<h, 1, typename ch::bx> df;
};
template <typename, int = l, typename = int> class dg;
template <typename dh, int di, typename dj> struct o<dg<dh, di, dj>> {
  typedef dh ch;
};
template <typename, int, typename> class dg : db<dg<bp<double>>> {
public:
  bp<double> dk;
  void dd() { db::dd<false>(dk); }
};
class dl {
  void dm();
  dg<double> dn;
};
void dl::dm() { dn.dd(); }

Comment 2 Darcy 2018-02-13 11:50:32 UTC
Reminds me of FORTRAN variable names.  Bad jokes aside, was this an in-built tool you used to generate?  It's much friendlier than uploading 6MB of preprocessed code.

This definitely occurs due to an upgrade in gcc-c++ in F27.  Performing a downgrade of the package doesn't expose this issue.

Comment 3 Jakub Jelinek 2018-02-13 11:52:35 UTC
This was reduced with creduce.

Comment 4 Jakub Jelinek 2018-02-13 12:21:39 UTC
Already fixed upstream.

Comment 5 Darcy 2018-02-13 12:37:48 UTC
Super.  Thank you very much!

Comment 6 Dave Malcolm 2018-03-09 14:46:11 UTC
The upstream bug was fixed:

* for gcc 8 in r254342 on 2017-11-02, and that fix is thus in all of our gcc 8 RPMs for Fedora 28 onwards.

* for gcc 7 in r257292 on 2018-02-01, and that fix is thus in our gcc 7 RPMSs for Fedora 27 from 7.3.1-5 onwards.

Do these fix the issue for you?  Thanks.

Comment 7 Darcy 2018-03-09 15:46:05 UTC
Works for me.  Thank you kindly.

Comment 8 Dave Malcolm 2018-03-09 15:51:27 UTC
(In reply to Darcy from comment #7)
> Works for me.  Thank you kindly.

Thanks for the info; I'll close this out, then.


Note You need to log in before you can comment on or make changes to this bug.