Details
Diff Detail
- Repository
- rCRT Compiler Runtime
Event Timeline
I've only tested with clang. In general I would think that GCC mostly supports most of the same things with -fms-extensions, but I haven't tried (I don't know what the state is of actually instrumenting for asan for windows targets in gcc either). But the thing that most certainly won't work, are the /include: and /alternatename: options in embedded linker directives, if attempting to link with ld.bfd.
I should add more reviewers, since adding a mingw port is not a small matter. I *think* that some of the sanitizer_common code already builds with mingw gcc for tsan-go, right? So, adding support for building with gcc on Windows should not be too onerous for the project as a whole. At least, that's what I think. Other folks can chime in.
It turns out that GCC actually doesn't support this syntax at all (at least not in a 5.x version). So without that, building with GCC would require much more invasive changes.
Additionally, Clang provides __debugbreak() as a builtin when building with -fms-extensions, but GCC doesn't (mingw provides it as an inline function in a header unless the compiler has got it as a builtin).
cmake/config-ix.cmake | ||
---|---|---|
530–531 | I guess this should be extended into something that allows building it with mingw+clang, but not with mingw+gcc, in case there are existing cases where this is project is built in that configuration, since this would otherwise break it by trying to build something that isn't supported? |
Updated the check, to only allow building for mingw if the compiler is clang. This should make sure not to break existing mingw builds with gcc/binutils, if that's something that people do. It won't catch the case of building with clang but linking with binutils though...
@kcc is here at CppCon. I think we should go forward with this. As you've explained, we're mostly adding support for the mingw headers and libs, not a new compiler, and that lowers the cost.
Great, thanks! Yes, it's just a minor tweak of the existing windows support, so it shouldn't require any larger commitment. There were two other patches still unapproved in the same series; I bumped one at the same time as this, I'll bump the other one as well.
I guess this should be extended into something that allows building it with mingw+clang, but not with mingw+gcc, in case there are existing cases where this is project is built in that configuration, since this would otherwise break it by trying to build something that isn't supported?