This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/61555] [4.9/4.10 Regression] LLVM build failure


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]