I've completed a survey of llvm for unnecessary dependencies on libstdc++, and on conflicts with the upcoming C++0X standard, and am recommending several changes in the enclosed patch (created with svn diff). Here is a summary of the patch: --- #include <cstdlib> added to LinkAllVMCore.h and LinkAllCodegenComponents.h to declare std::getenv. Changed next(...) to llvm::next(...) in many places. I only changed those instances which were actually required to avoid ambiguity. I left other calls to next() unqualified. I do not have strong feelings about how this particular situation should be fixed, but this solution seems the simplest to me. I do not anticipate a fix from the standards committee on this matter, though if anyone would like to pursue this course of action, I can certainly help with that. #include "X86MachinefunctionInfo.h" added to X86COFFMachineModuleInfo.h to make X86MachineFunctionInfo a complete class before it is used to instantiate std::map. #include <ostream> added to TargetData.cpp to bring these formatting prototypes into scope. --- -Howard -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: application/octet-stream Size: 41192 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091202/4ec9e063/attachment.obj>
On Dec 2, 2009, at 6:54 AM, Howard Hinnant wrote:> I've completed a survey of llvm for unnecessary dependencies on > libstdc++, and on conflicts with the upcoming C++0X standard, and am > recommending several changes in the enclosed patch (created with svn > diff).Thanks, applied here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091130/092102.html I fixed a few lines to stay in 80 cols. -Chris> > Here is a summary of the patch: > > --- > > #include <cstdlib> added to LinkAllVMCore.h and > LinkAllCodegenComponents.h to declare std::getenv. > > Changed next(...) to llvm::next(...) in many places. I only changed > those instances which were actually required to avoid ambiguity. I > left other calls to next() unqualified. I do not have strong > feelings about how this particular situation should be fixed, but > this solution seems the simplest to me. I do not anticipate a fix > from the standards committee on this matter, though if anyone would > like to pursue this course of action, I can certainly help with that. > > #include "X86MachinefunctionInfo.h" added to > X86COFFMachineModuleInfo.h to make X86MachineFunctionInfo a complete > class before it is used to instantiate std::map. > > #include <ostream> added to TargetData.cpp to bring these formatting > prototypes into scope. > > --- > > -Howard > <patch.patch>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sorry, always end up not replying to the list: The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. There are also two issues with rvalue references and the STL: 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions which have versions taking rvalue references. This results in a compiler error because the private constructor of ECValue is inaccessible. The easiest fix is to explicitly call the constructor of ECValue before the insert/find calls. 2. There are numerous places where there is a std::pair of pointer types and passing 0 results in the rvalue reference constructor being called. The type of 0 is deduced to be an int and an int isn't convertable to a pointer, so it fails to compile. The fix is to use nullpte (GCC doesn't seem to have this yet) or to static_cast<T*>(0) where T is the appropriate type. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091203/91fdda1b/attachment.html>