This is an archive of the discontinued LLVM Phabricator instance.

[CUDA] Support <complex> and std::min/max on the device.
ClosedPublic

Authored by jlebar on Sep 27 2016, 11:44 AM.

Details

Summary

We do this by wrapping <complex> and <algorithm>.

Tests are in the test-suite. <complex.h> support to come separately.

Diff Detail

Event Timeline

jlebar updated this revision to Diff 72686.Sep 27 2016, 11:44 AM
jlebar retitled this revision from to [CUDA] Support <complex> and std::min/max on the device..
jlebar updated this object.
jlebar added a reviewer: tra.
jlebar added subscribers: cfe-commits, jhen.
tra edited edge metadata.Sep 27 2016, 1:22 PM
tra added a subscriber: echristo.

This looks like fix-includes and it may be somewhat shaky if users start messing with include paths. You may want to get @echristo's input on that. I' personally would prefer to force-include these files. I suspect it will not change things much as we already include a lot.

clang/lib/Driver/ToolChains.cpp
4704

path::append accepts multiple path parts so you can construct path in one call.

jlebar added a comment.EditedSep 27 2016, 1:28 PM

I' personally would prefer to force-include these files. I suspect it will not change things much as we already include a lot.

We have already had bugs filed by users whose root cause was that we #included more things than nvcc #includes. I know exact compatibility with nvcc is not our goal, but unless we have a good reason I don't think we should break compatibility with nvcc *and* the C++ standard by force-including additional system headers.

This looks like fix-includes and it may be somewhat shaky if users start messing with include paths.

We add this include path first, so I think it should be OK? What do you think, @echristo?

echristo accepted this revision.Sep 27 2016, 1:33 PM
echristo edited edge metadata.

I' personally would prefer to force-include these files. I suspect it will not change things much as we already include a lot.

We have already had bugs filed by users whose root cause was that we #included more things than nvcc #includes. I know exact compatibility with nvcc is not our goal, but unless we have a good reason I don't think we should break compatibility with nvcc *and* the C++ standard by force-including additional system headers.

This looks like fix-includes and it may be somewhat shaky if users start messing with include paths.

We add this include path first, so I think it should be OK? What do you think, @echristo?

It is very similar to fixincludes, but in this case I think it's probably the right thing.

If nothing else it's very easy to change our minds later.

One small wording change requested.

Thanks!

-eric

clang/lib/Headers/__clang_cuda_complex_builtins.h
2

Would swap libgcc for "runtime"

This revision is now accepted and ready to land.Sep 27 2016, 1:33 PM
jlebar updated this revision to Diff 72719.Sep 27 2016, 3:02 PM
jlebar edited edge metadata.

s/libgcc/runtime/

jlebar added a subscriber: rryan.Sep 28 2016, 4:13 PM
This revision was automatically updated to reflect the committed changes.