[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 Rafael Avila de Espindola changed: What|Removed |Added CC||rafael.espindola at gmail dot com --- Comment #4 from Rafael Avila de Espindola --- A valid testcase reduction is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 Hristo Venev changed: What|Removed |Added CC||mustrumr97 at gmail dot com --- Comment #3 from Hristo Venev --- In the LLVM codebase getOption() is defined but still not written in the object file. The reduced test case is wrong. Why can't I reopen this bug?
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 --- Comment #2 from Markus Trippelsdorf --- (In reply to Andrew Pinski from comment #1) > Are you sure this is not a LLVM source issue? > > llvm::cl::parser::getOption(unsigned int) const > is called by llvm::cl::C::getExtraOptionNames(int&). > > llvm::cl::C::getExtraOptionNames(int&) is part of vtable for > llvm::cl::C. > > > I don't see anything wrong here really as the type of Parser can found at > compile time and it is D inherits from cl::parser. > So getExtraOptionNames calls Parser.getExtraOptionNames which in turns calls > this->getOption (0) which is a virtual function call. Since we know the > type of *this here, we call directly llvm::cl::parser const*>::getOption(unsigned int) const. > > So the devirtuatization seems correct and it is just a LLVM source problem. Thanks. I just wasn't 100% sure. LLVM bug: http://llvm.org/bugs/show_bug.cgi?id=20067
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Are you sure this is not a LLVM source issue? llvm::cl::parser::getOption(unsigned int) const is called by llvm::cl::C::getExtraOptionNames(int&). llvm::cl::C::getExtraOptionNames(int&) is part of vtable for llvm::cl::C. I don't see anything wrong here really as the type of Parser can found at compile time and it is D inherits from cl::parser. So getExtraOptionNames calls Parser.getExtraOptionNames which in turns calls this->getOption (0) which is a virtual function call. Since we know the type of *this here, we call directly llvm::cl::parser::getOption(unsigned int) const. So the devirtuatization seems correct and it is just a LLVM source problem.