Repository navigation
Error introduced by boost::core::launder #122
Description
The Boost.URL drone job for Windows (x86) broke in the last days from an old run to a more recent run. These two jobs are testing the very same commit: no code changes in Boost.URL. Also, it only fails in MSVC 14.1. MSVC 14.3 works fine.
Output
c:\drone\boost-root\libs\url\src\detail\pattern.cpp(700) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'd:\agent\_work\2\s\src\vctools\compiler\utc\src\p2\main.c', line 187)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
c:\drone\boost-root\libs\url\src\detail\pattern.cpp(700) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'd:\agent\_work\2\s\src\vctools\compiler\utc\src\common\error.c', line 835)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
call "bin.v2\standalone\msvc\msvc-14.1\adrs-mdl-32\archt-x86\msvc-setup.bat" >nul
cl /Zm800 -nologo "libs\url\src\detail\pattern.cpp" -c -Fo"bin.v2\libs\url\test\limits\limits.test\msvc-14.1\rls\adrs-mdl-32\cxstd-17-iso\thrd-mlt\detail\pattern.obj" -TP /wd4675 /EHs /std:c++17 /GR /Zc:throwingNew /O2 /Ob2 /W4 /WX /MD /Zc:forScope /Zc:wchar_t /Zc:inline /Gw /we4265 -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_DYN_LINK=1 -DBOOST_URL_MAX_SIZE=16 -DBOOST_URL_NO_LIB -DBOOST_URL_STATIC_LINK -DNDEBUG "-I." "-Ilibs\url\extra" "-Ilibs\url\test\limits"
...failed compile-c-c++ bin.v2\libs\url\test\limits\limits.test\msvc-14.1\rls\adrs-mdl-32\cxstd-17-iso\thrd-mlt\detail\pattern.obj...
The message is very unhelpful but Peter helped me track down the error. We have a pattern.cpp source file that includes Boost.Optional and the error goes away when we check out any version of Boost.Optional before e31cf6f. In particular, the error goes away if we comment out:
T const& ref() const { return * /*boost::core::launder*/(ptr_ref()); }
T & ref() { return * /*boost::core::launder*/(ptr_ref()); }Unfortunately, I can't identify why this is causing an error. We could only identify what is causing it.
This is also related to #121.
Activity
akrzemi1 commentedon Jan 3, 2024
That's unfortunate.
The only thing I can do is to revert #119.
alandefreitas commentedon Jan 3, 2024
Yes. I wish we knew why this is causing an error. We just know what is causing it.
akrzemi1 commentedon Jan 3, 2024
This should be fixed now by 8375df7.
alandefreitas commentedon Jan 3, 2024
Windows x86 is working now: https://drone.cpp.al/boostorg/url/2329/11/2
Thanks!
pdimov commentedon Jan 4, 2024
It's better to use
BOOST_WORKAROUND(BOOST_MSVC, < 1920)here because msvc-14.2 and above have no problems withlaunderand unversioned ifdefs aren't a good practice.But it might be even better to apply this workaround in
core/launder.hppinstead.akrzemi1 commentedon Jan 4, 2024
I just wonder if this is a problem with
launderor with a combination of factors.pdimov commentedon Jan 4, 2024
It's a compiler bug in VS2017 (32 bit); an internal compiler error with
toolset=msvc-14.1 cxxstd=17 variant=release address-model=32.akrzemi1 commentedon Jan 4, 2024
I mean, have other problems
std::launderbeen reported on this setup, other than the Optional use case? If not, it will be safer to fix it only in Optional.alandefreitas commentedon Jan 4, 2024
I think we only caught this bug in Boost.URL, but I think Christian has been using launder all around to eliminate
-Wmaybe-uninitializederrors. I think this bug is being propagated to other libraries. Still, the only reason we're not catching this bug in more libraries is that most people are not testing this rather unusual combination of factors.pdimov commentedon Jan 4, 2024
No, but
std::launderhasn't seen much use. I think it's fairly safe to say that using it under MSVC 14.1 is likely to run into errors with more complex expressions, and there's probably no upside because the compiler probably doesn't need it.pdimov commentedon Jan 4, 2024
Right, not many are testing msvc-14.1 in 32 bit mode.
pdimov commentedon Jan 4, 2024
boostorg/core@e4adc76 should make the workaround here unnecessary.
akrzemi1 commentedon Jan 4, 2024
Thanks. I have reverted the fix in Optional.