This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
- From: "pinskia at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 18 Jun 2014 20:43:04 +0000
- Subject: [Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure
- Auto-submitted: auto-generated
- References: <bug-61555-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Are you sure this is not a LLVM source issue?
llvm::cl::parser<llvm::PassInfo const*>::getOption(unsigned int) const
is called by llvm::cl::C<llvm::D>::getExtraOptionNames(int&).
llvm::cl::C<llvm::D>::getExtraOptionNames(int&) is part of vtable for
llvm::cl::C<llvm::D>.
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<const PassInfo *>.
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<llvm::PassInfo
const*>::getOption(unsigned int) const.
So the devirtuatization seems correct and it is just a LLVM source problem.