- User Since
- Apr 15 2014, 12:19 PM (300 w, 3 d)
Aha, which version of clang-cl are you using? With the released version of clang-cl 9.0.1, I get a warning instead of an error:
Eh, no it does not crash clang, at least not here? Instead it gives you a compile error, as it should:
Thu, Jan 9
Wed, Jan 8
Dec 15 2019
We should abandon this, for e.g. 9.0.1 the whole Base_url variable has become unused. :)
Nov 18 2019
Adding a few people who might know a bit more about CUDA specific things. Please take a look if this review makes any sense, thanks. :)
- Add cuda options test, copied from cuda-options.cu.
Nov 17 2019
I'll work on a test.
Nov 13 2019
Now opt supports -disable-builtin, move the test to llvm/test/Transforms/InstCombine.
I submitted D70193 for adding a -disable-builtin option to opt. Once that is committed, this review can continue.
Nov 12 2019
Nov 8 2019
Another attempt to grab your attention :)
Oct 29 2019
Hm, I would really say that __isnan and the other __ prefixed functions are Linuxisms, or more accurately, glibc-isms. They also don't exist on e.g. macOS:
Oct 21 2019
N.B., EOWNERDEAD and ENOTRECOVERABLE are already defined on lines 158 and line 170, respectively.
Get rid of the ELAST trickery, which is hard to maintain, and does not
appear to serve any purpose. There is no mention of ELAST in the C or
C++ standards, as far as I know.
Now that I'm reading this header again, why do we even bother to define ELAST at all? On Linux, there is no such thing, while on BSDs and macOS, it is already provided by the regular errno.h.
Oct 19 2019
Oct 18 2019
Rewrite the __FreeBSD_version condition to be more straightforward.
Oct 10 2019
Convert m_(monitor|operation)_thread to llvm::Optional<>.
Oct 9 2019
@devnexen this appears to cause https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137, where simply launching a process in lldb triggers a failure:
Oct 8 2019
For some reason this didn't get closed by Phabricator. Committed in rCRT374070.
@spatel, you mentioned this should be in 9.0.1, with "A noticeable perf regression for x86 vector code made it into the 9.0 release". Does it have a lot of influence on compile-time performance, or run-time performance? (I'd like to pull this one into FreeBSD's clang 9.0.)
Oct 2 2019
Sep 26 2019
LGTM from a FreeBSD point of view. :)
Sep 25 2019
This works for me, and also for the original test case from https://bugs.freebsd.org/240764.
Sep 18 2019
Sep 10 2019
Third time's the charm.
Sep 7 2019
Add _LIBCPP_C_HAS_NO_GETS macro to <__config>, and use that in <cstdio>.
Sep 4 2019
Still OK with me :)
Sep 3 2019
Aug 30 2019
Aug 28 2019
Aug 22 2019
LGTM. Maybe nice to merge it to 9.0 after a day or two.
Aug 10 2019
Aug 5 2019
Jul 28 2019
Jul 24 2019
Jul 9 2019
Jun 23 2019
FWIW, the original test case with pre-increment is fixed by this, e.g.:
Jun 15 2019
No longer needed after rC362328 and follow-ups.
Jun 4 2019
May 13 2019
In fact, it is probably better to turn the OS check around, e.g. *only* increase the alignment for Linux, and nowhere else.
Please also exclude FreeBSD from these changes, since we care a lot about backwards compatibility, and specifically about alignment requirements. (We have run into many issues in our ports collection where upstream assumes everything is 16-byte aligned on i386, which is *NOT* ABI compliant.)
May 6 2019
@efriedma any more work to be done on this? :)
May 4 2019
So does this look better now?
May 1 2019
Address review comments:
- Assign zero to pointed-to value in __kmp_store_mxcsr()
- Use SSE specific stuff in KMP_OS_UNIX part only