Re: [boost] [review] Outcome: internal compiler error
On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost
GitHub: *- https://github.com/ned14/boost-outcome
Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review:
I have put together the following sample program to test integration
of Outcome into Boost.Beast:
#include
I have put together the following sample program to test integration of Outcome into Boost.Beast:
#include
int main(int argc, char** argv) { } The result of compilation for this translation unit is shown here:
1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507)
Compiler used: MSVC Part of: Microsoft Visual Studio Community 2017 Version 15.5.1
Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit:
1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507)
Is this a supported configuration?
It certainly is. Microsoft itself runs Outcome as part of the Visual Studio compiler validation suite! Can I confirm that you are running Boost 1.66 and that the ICE causing file solely consists of including boost/outcome.hpp, and an empty main() function? (BTW, did you try having main() return 0?) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit:
1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507)
Is this a supported configuration?
It certainly is. Microsoft itself runs Outcome as part of the Visual Studio compiler validation suite!
I have confirmed this ICE in MSVC (15.5.4). It also occurs in Microsoft's C2 clang edition. Shame on Microsoft, an empty source file instantiating nothing should never, *ever* ICE the compiler, no matter the headers included. CC Stephan and Andrew, because this is *bad*. Vinnie if you choose the LLVM clang toolset, all will work correctly. I suggest a minimum of clang 6.0, it actually somewhat works on Windows when targeting the MSVC ABI, even produces usable debug info in the Visual Studio debugger. The standalone edition of Outcome is not affected. So something in Boost + Outcome is causing this ICE. Seeing as LLVM clang works correctly with proposed Boost.Outcome, I am going to assert - not claim - that this problem is 100% on Microsoft, and nothing to do with Boost or Outcome or proposed Boost.Outcome. For the record, my main development platform for Outcome and AFIO is Windows with MSVC. Outcome has received almost all its testing on MSVC. Whatever is tripping this MSVC ICE is not something I have seen to date (the non-trivial value_storage implementation). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
[Niall Douglas]
I have confirmed this ICE in MSVC (15.5.4). It also occurs in Microsoft's C2 clang edition.
Clang/C2 3.8 is no longer supported for C++ and will be removed. Our STL is now tested with Clang/LLVM 5.0.1. In VS 2017 15.6, the STL will emit an error if it detects an unexpectedly old compiler being used; that release will accept Clang 5 and newer, and reject Clang 4 and older.
Shame on Microsoft, an empty source file instantiating nothing should never, *ever* ICE the compiler, no matter the headers included. CC Stephan and Andrew, because this is *bad*.
What you call "an empty source file" is actually a translation unit presumably dragging in a megabyte or more of (template and non-template) class definitions, and (template and non-template) function implementations. This asks the compiler to do a lot of work, even before considering what two-phase name lookup demands. This is also why PCHes help, by saving the result of that work to be reloaded later. (None of this is an excuse, just an explanation.) That said, ICEs are compiler bugs by definition. Please submit a preprocessed repro for us to investigate. The proper form of a preprocessed repro is: cl OPTIONS meow.cpp (triggers ICE) cl OPTIONS /P meow.cpp (preprocesses) cl OPTIONS /TP meow.i (verifies that compiling the preprocessed file triggers the same ICE) Please submit meow.i and the corresponding command line. (I suspect that this is a backend ICE, if Clang/C2 reproed it too, but a preprocessed file will let us figure out the root cause.) STL
(I suspect that this is a backend ICE, if Clang/C2 reproed it too, but a preprocessed file will let us figure out the root cause.)
Precisely why (i.e. backend) a source file with an empty main function instantiating nothing should never, *ever*, ICE a compiler. I mean, I'd get why a frontend might ICE. But if you don't instantiate anything apart from an empty main function, then the backend ought to not be doing anything. Ever. I'll get to submitting a repro sometime between tomorrow and Wednesday, depending on workload. Outcome review takes precedence. Thanks for the quick reply Stephan, and apologies for the ribbing. I recently ran clang-tidy on AFIO which is only a three year old codebase, and I was fairly shocked at how awful - as in, clearly hard "segfault me now" UB - the code I had written. It happens to us all. (And well done on whomever added to clang-tidy the "you are copy slicing an object with multiple inheritance" lint check) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (3)
-
Niall Douglas -
Stephan T. Lavavej -
Vinnie Falco