Workaround for depending on NVPTX symbols: initialize all available targets instead. If NVPTX is not available, it will complain when we try to actually execute anything in CUDA mode.
Rebased and fixed conflicts on recent value printing related patches.

Added some std::move fixes for Error -> Expected conversions

Update the filenames

Remove the copy of CodeGenOpts in CodeGeneratorImpl

Add some CUDA basic functionality tests.
Disallow undo-ing of the initial PTU. This should fix the undo command test.

Added a check to run CUDA tests only on systems with CUDA. We need some ideas for the actual tests.
Rename Offload.cpp to DeviceOffload.cpp
Other syntax/style fixes

extern "C" and enable PS4/5

I made patch with both precompiled library and without cstdio. D148992

Use virtual file system to store CUDA fatbinaries in memory
Adapted Interpreter tests to use the CompilerBuilder

We should probably also address the lack of linker issue as well. Should we go for a precompiled dynamic library file? There seems to be some "precedent" of this in other tests.

Combined IncrementalCompilerBuilder and IncrementalCudaCompilerBuilder
Added --cuda-path support
Use sys::fs::createTemporaryFile() instead of hardcoding the path
Other minor refactoring

In D146389#4243900, @tra wrote:

Initial interactive CUDA support for clang-repl

What should a user expect to be supported, functionality wise? I assume it should cover parsing and compilation. I'm not so sure about the execution. Should it be expected to actually launch kernels, or will that come in a future patch?

Just to confirm, UNSUPPORTED: target=x86_64-scei-ps4 should be enough, right?

Hi, @dyung ! It seems the dynamic library generation is failing from the lack of a linker. We need a test library to load at runtime in clang-repl. Do you have any idea how we can create one without a linker? Otherwise we can disable the test on PS4 as it is probably an unlikely use case.

Changed test to use a separate Input file for the dynamic library generation

Added a simple test and removed the automatic OS specific library filenames

Thanks!

Thanks! I forgot about this.

Properly base everything hopefully

Properly rebase everything

In D132313#3737642, @lhames wrote:

By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fail. Instead at this point only shared memory regions
can be unmapped safely.

I think that you can assert that there are no remaining allocations in the destructor -- these should all have been destroyed by a call to endSession(), which should happen before the allocator is destroyed.

Addressed the above issues

We are resetting permissions to read/write in InProcessMapper::deinitialize(). It may make sense to set them to read/write in InProcessMapper::prepare() instead. But in that case extra syscalls are made during startup instead of shutdown.

This should fix https://reviews.llvm.org/D128544#3710127 but I think we may not even need the lock at all since this is called only at shutdown.

Remove address space size check and improve comments

Thanks for the fix.

That was a mistake, Thanks.

Something like LLVM_ORC_SHARED_MAPPER_SUPPORTED would be nice and maybe we can even define it from the build system. In any case it should be a follow up patch I guess.

Added support for new SharedMemoryMapper

Use new SharedMemorySegFinalizeRequest instead of SegFinalizeRequest

Link with librt if available

Hi! I am not very familiar with powerpc but it seems like POSIX shared memory APIs should be available.
From this page I suspect shm_ family of functions could be in librt instead of libc.

Skip the test on unimplemented operating systems

Replaced some llvm_unreachable() with llvm::Error

Added explicit cast from size_t to uint64_t