Created attachment 10275 [details] -E -generated test case. I have built Clang 3.2 on Windows following these instructions: https://github.com/kripken/emscripten/wiki/Using-Emscripten-from-Visual-Studio-2010 (step 4 on that page) Using that to build libcxx on Windows for emscripten, I am bit by an issue where a constexpr inside a template class is not working. The same code builds ok on Clang 3.2 built on Linux or OSX (following instructions at https://github.com/kripken/emscripten/wiki/Getting-started-on-Mac-OS-X and https://github.com/kripken/emscripten/wiki/Getting-Started-on-Ubuntu-12.10 ) A large test case is available at https://dl.dropbox.com/u/40949268/emcc/bugs/preprocessed.cpp Compiling on Windows with "clang++ -std=c++11 -m32 -U__i386__ -U__x86_64__ -U__i386 -U__x86_64 -Ui386 -Ux86_64 -U__SSE__ -U__SSE2__ -U__MMX__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87 -DEMSCRIPTEN -U__STRICT_ANSI__ -U__CYGWIN__ -D__STDC__ -Xclang -triple=i386-pc-linux-gnu -D__IEEE_LITTLE_ENDIAN -fno-math-errno -fno-ms-compatibility -nostdinc -nostdinc++ -Xclang -nobuiltininc -Xclang -nostdsysteminc -U__APPLE__ -U__linux__ -emit-llvm -c preprocessed.cpp" gives the error clang++: warning: argument unused during compilation: '-nostdinc++' G:\Inttel-slave\win-emcc-incoming-tests\build\system\lib\libcxx\condition_variable.cpp:59:30: error: constexpr variable 'ts_sec_max' must be initialized by a constant expression _LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max(); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ G:\Inttel-slave\win-emcc-incoming-tests\build\system\lib\libcxx\condition_variable.cpp:59:43: note: undefined function 'max' cannot be used in a constant expression _LIBCPP_CONSTEXPR ts_sec ts_sec_max = numeric_limits::max(); ^ G:\Inttel-slave\win-emcc-incoming-tests\build\system\include\libcxx\limits:443:61: note: declared here _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT {return __base::max();} ^ 1 error generated. A minimal failing example that exhibits the same problem is available at https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail.cpp which fails as follows: https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail.txt The same problem is tracked in the emscripten issue tracker here: https://github.com/kripken/emscripten/issues/1019 I also tried with the Clang trunk on Windows, which also fails in the same way: https://dl.dropbox.com/u/40949268/emcc/bugs/constexpr_fail_clang33trunk.txt Any ideas what could cause this kind of thing to work on linux and OSX builds of Clang, but not on Windows builds of Clang?
You can work around this with -fno-delayed-template-parsing. The problem is that in MS compatibility mode (which enables -fdelayed-template-parsing), we don't parse any function templates until we get to the end of the translation unit, so constexpr evaluation can't see the bodies of functions it needs to call.
Awesome! That works like a charm! I have been asking time and time again in the #llvm IRC channel to get to know the set of command line flags required to make Clang behave identically on each platform. I'm very happy to learn about a new flag to make things more consistent. I am already running with -fno-ms-compatibility. Should -fno-ms-compatibility imply -fno-delayed-template-parsing? This is currently not the case. Is the set of MS compatibility -related command line flags documented somewhere? So that I could be sure to factor out and disable all MS compatibility for emscripten purposes. We use Clang for cross-compiling, so it's very important that it behaves identically on Windows, Linux and OSX.
MS compatibility is on when you target windows platform. This is usually done by building clang with Visual Studio but you can do it manually by passing -target i686-pc-win32 to clang driver.
More than that, I believe the actual problem with -fdelayed-template-parsing was covered by PR17661 and fixed by David Majnemer in r193274.