In D21856#1338687, @thakis wrote:

Sorry about the years-later question, but what's the motivation for shelling out to an external command here? In general, LLVM tries to use a library-based approach, and LLVM went e.g. through great lengths do use an integrated assembler so clang doesn't have to shell out to one. Concretely, why isn't there a clang/lib/OffloadBundle library that clang and clang-offload-bundler both use? Does the bundling have to happen out-of-process? And if so, why isn't the process something like clang -cc1bundle instead of a separate executable? It seems weird to make clang depend on another executable next to it.

I apologize for the clueless question.

Hi Doru,

In a discussion off-list I proposed adding constructor functions to all object files and handle them like shared libraries are already handled today (ie register separately and let the runtime figure out how to relocate symbols in different translation units). I don't have an implementation of that approach so I can't claim that it works and doesn't have a huge performance impact (which we don't want either), but it should be agnostic of the offloading target so it may be worth investigating.

Just to clarify one thing in my last comment:

@gtbercea, thanks for the patch.

Why do we need ii)? i) will use the just-built compiler to test the openmp runtime AFAIK

Hi Jonas

• Privatize Order, Flags and Kind of the offload entry.

Thanks for the patch. Here are few comments following Jonas review.

Hi Jonas,

Hi Justin,

Hi Michael,

Hi Jonas,

A PR was generated as requested by Hal explaining why we do not generate jobs for NVPTX targets yet.

• Rebase.

• Add comment explaing that the bundler tool can detect if the input file is a bundle or not.

• Capitalize Clang in the regression test too.

• Capitalize Clang in linker script comment and explain that the linker script dump option is required to test the driver with -###.

In D18172#580276, @jlebar wrote:

Hi, Samuel.

This change introduced a new crash / assertion failure in the driver.

$ echo | llvm-run clang -emit-llvm -c -x cuda - -o /dev/null
 

Before this patch, we get an error (perhaps not as helpful as we might want, but still):

clang-3.8: error: cannot specify -o when generating multiple output files

After this patch, we get an assertion failure:

clang: ../clang/lib/Driver/Driver.cpp:1610: virtual (anonymous namespace)::OffloadingActionBuilder::DeviceActionBuilder::ActionBuilderReturnCode (anonymous namespace)::OffloadingActionBuilder::CudaActionBuilder::getDeviceDepences(OffloadAction::DeviceDependences &, phases::ID, phases::ID, PhasesTy &): Assertion `CurPhase < phases::Backend && "Generating single CUDA " "instructions should only occur " "before the backend phase!"' failed.
#0 0x0000000001b07e28 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x1b07e28)
#1 0x0000000001b08566 SignalHandler(int) (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x1b08566)
#2 0x00007f4bb7f89330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x00007f4bb6b7cc37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x00007f4bb6b80028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#5 0x00007f4bb6b75bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#6 0x00007f4bb6b75ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x0000000001fa809b (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x1fa809b)
#8 0x0000000001f99981 clang::driver::Driver::BuildActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, llvm::SmallVector<std::pair<clang::driver::types::ID, llvm::opt::Arg const*>, 16u> const&, llvm::SmallVector<clang::driver::Action*, 3u>&) const (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x1f99981)
#9 0x0000000001f9431c clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x1f9431c)
#10 0x00000000007c0254 main (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x7c0254)
#11 0x00007f4bb6b67f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0
#12 0x00000000007bd9a2 _start (/usr/local/google/home/jlebar/llvm/release/bin/clang+0x7bd9a2)
Stack dump:
0.	Program arguments: /usr/local/google/home/jlebar/llvm/release/bin/clang -emit-llvm -c -x cuda - -o /dev/null 
1.	Compilation construction
2.	Building compilation actions
Aborted (core dumped)

This was reported two weeks ago by Gurunath Kadam on cfe-dev, but I just got around to bisecting it.

Would you mind spinning a fix for this?

Hi Justin

• Fix typos and use StringRef() instead of const char * to follow what the Driver does today when it comes to specify the bound architectures.

Hi Hal,

Hi Hal,

• Fix typos and check -dynamic when it comes to translating arguments for offloading gcc toolchains.

Hi Hal,

• Address Hal Finkel comments - fix comments/fix linker script comment.

Hi Hal,

• Fix typos and add test tht checks phases when OpenMP and CUDA are used simultaneously.

Hi Hal,

• Address Hal Finkel comments - make diagnostic message more informative.

Hi Hal,

• Address Hal Finkel suggestions - rename functions/reorder code/fix comments.

Hi Jonas,

• Use string format used before.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

• Rebase.

Hi Eugene,

Hi Eugene,

Oh, I see, thanks for the fix, it looks good.