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: "trippels 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:46:30 +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
--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> 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.
Thanks. I just wasn't 100% sure. LLVM bug:
http://llvm.org/bugs/show_bug.cgi?id=20067