Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Windows] -fdelayed-template-parsing does not support parsing templates before end of TU, breaks constexpr #16023

Closed
juj opened this issue Apr 2, 2013 · 4 comments
Closed

[Windows] -fdelayed-template-parsing does not support parsing templates before end of TU, breaks constexpr #16023

juj opened this issue Apr 2, 2013 · 4 comments
Labels
bugzilla Issues migrated from bugzilla c++11

Comments

@juj
Copy link

juj commented Apr 2, 2013

Bugzilla Link 15651
Resolution FIXED
Resolved on Jun 17, 2014 13:13
Version trunk
OS Windows NT
Blocks #15837
Attachments -E -generated test case.
CC @DougGregor,@zygoloid,@rnk

Extended Description

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: emscripten-core/emscripten#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?
@zygoloid
Copy link
Mannequin

zygoloid mannequin commented Apr 2, 2013

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.

@juj
Copy link
Author

juj commented Apr 3, 2013

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.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 17, 2014

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.

@rnk
Copy link
Collaborator

rnk commented Jun 17, 2014

More than that, I believe the actual problem with -fdelayed-template-parsing was covered by llvm/llvm-bugzilla-archive#17661 and fixed by David Majnemer in r193274.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 4, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla c++11
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rnk @juj @llvmbot