For Archer using openmp/towards_tr4 and archer/towards_tr4, we encounter segmentation fault frequently with OpenMP reduction. The segmentation fault would show up when using more than 4 OpenMP threads in the testing.

I bootstrap clang and then build archer following the instructions given at README file. The Archer building process failed to find OMP_LIB_PATH. I think the issue is related to the following:

Should FIND_PATH(OMP_LIB_PATH) include the lib directory from the bootstrapped clang?

Cmake reports missing counter.cpp in rt/CMakeLists.txt when building ROSE with llvm release_40.
Is there any restriction for that?

Suppression for libomp.so and libarcher.so is made by the function in "__tsan_default_suppressions" or through a file declared using the TSAN_OPTION. In branch manage_clock the suppression.txt has been updated but we need to update also the function redefined automatically by clang-archer at compile time. Also the suppression.txt suppress ompt_tsan.so, however the new name should be libarcher.so.

In the case of building archer along with clang/llvm as per readme.md, cloning OMPT creates
a LLVM-openmp folder rather than a openmp folder.

git clone [email protected]:OpenMPToolsInterface/LLVM-openmp.git

So, suitable corrections must me made.

And there was one more issue that I was facing which kept saying that the OMPT_INCLUDE_PATH variable was set to not found.
I saw the contents of the LLVM-openmp folder (OpenMP with OMPT support) and no ompt.h file was being generated in the build folders.
I feel there are two corrections to be made in archer/cmake/FindOmpt.cmake

FIND_PATH(OMPT_INCLUDE_PATH ompt.h

The ompt.h should be changed to omp.h as that is the file being generated in the build folders.

PATHS ${LLVM_ROOT}/include ${CMAKE_BINARY_DIR}/projects/openmp/runtime/src

openmp should be changed to LLVM-openmp. This can be avoided if the there are corrections made to the first point itself.

Is development tested on macOS X?

For copyprivate-orig-no.c, threadprivate-orig-no.c, threadprivate2-orig-no.c, static-data-member-orig-yes.cpp and static-data-member2-orig-yes.cpp.

Code: https://github.com/LLNL/dataracebench/blob/develop/micro-benchmarks/

We found it useful in more extensive projects to adopt a branching model to follow, and in particular I like this one: http://nvie.com/posts/a-successful-git-branching-model/
In short, all the action is happening in the develop branch, and you only merge into master before doing a release. Just a thought.

The following commands create a binary, that is instrumented with TSan, has the Clang-TSan, LLVM-openmp and archer runtime library linked:

gfortran -fopenmp -sanitize=thread -c code.f
clang -fopenmp -sanitize=thread -lgfortran -larcher code.o

I'm not sure, how to modify the compiler wrapper, to split the compilation into this two steps.

I was able to use the Archer in tr4 branch with clang 4.0.1 to find race in this benchmark:
https://github.com/LLNL/dataracebench/blob/master/micro-benchmarks/taskdependmissing-orig-yes.c
But a later version of Archer with clang 3.9.1 (installed on LLNL LC system) does not find race in this same benchmark. Is that caused by different clang version or some other issue?

I am looking into ways to extend Archer to support detection of other concurrency errors and/or new OpenMP pragmas. I had a little chat with Ganesh at POPL this year, it seems Archer is a right tool for this.

I have been playing around with the tool. I first used the automated script to install it and later installed a stand-alone version with the standard OpenMP runtime. I have not tried the stand-alone version with OMPT runtime yet.

For hacking Archer -- adding more passes, extending the available passes or changing the race detection algorithm -- which installation would you recommend among the three options available, for convenience?

@jprotze Not sure if you saw it but your new branch is failing the tests, if you join to Salck (https://pruners.slack.com/messages/archer-travisci/) you'll see the TravisCI channel for Archer, anyway here's the link: https://travis-ci.org/PRUNERS/archer/builds/203203366.

@jprotze: I was taking a look to this reduction test case:

https://github.com/PRUNERS/archer/blob/master/test/reduction/parallel-reduction.c#L13

At line 13 there is only an assignment but it's not doing any reduction, shouldn't it be a race?

Thanks!

@jprotze what do you think about removing the OMPT tests from archer tests now that OMPT is officially integrated in the OpenMP runtime?
I finished porting archer to clang 6.0 and I am ready to commit, but I get some OMPT test fails because most likely they need to be updated.
We don't really need to test OMPT in archer, do you agree?

Can we detect in the initialization of the OMPT-tool, whether the application is built with TSan or not?
If that would be possible, we could avoid to register the callbacks and remove the potential overhead. This would be a good step for pushing Archer upstream in the long run.

@jprotze pointed out that we have always to manually add -larcher when linking a program compiled with Archer. It is necessary to modify the Archer wrapper to add the libarcher libarary when using the OMPT support version.

Failing tests:

The task_schedule event returns status=task_completed when it should be task_other, since the explicit task has not been scheduled yet

test/OMPT/parallel/parallel_if0.c
test/OMPT/parallel/serialized.c

It seems this is due to a bug in the OMPT in LOMP

The explicit task is not scheduled

test/OMPT/tasks/explicit_task.c
test/OMPT/tasks/task_in_joinbarrier.c

It seems this is due to how these test cases are written

The parent task (implicit) is NULL

task/task-taskgroup-nested.c
task/task-taskgroup.c

It seems this is due to a bug in the OMPT in LOMP

With Archer (dc4e363) build with out of source with LLVM 4.0 and OMP-TR4. Running GROMACS unit tests:

git init gromacs && cd gromacs
git fetch https://gerrit.gromacs.org/gromacs refs/changes/48/6648/1 && git checkout FETCH_HEAD
mkdir build && cd build
CC=clang-archer CXX=clang-archer++ cmake -GNinja -DGMX_OPENMP_MAX_THREADS=256 -DGMX_BUILD_HELP=OFF -DBUILD_SHARED_LIBS=yes -DCMAKE_BUILD_TYPE=RelWithDebInfo -DGMX_HWLOC=no .. -DGMX_SIMD=None -DTMPI_ATOMICS_DISABLED=yes -DGMX_MPI=on
ninja check

Produces:

The following tests FAILED:
          7 - EwaldUnitTests (Failed)
         12 - MdrunUtilityMpiUnitTests (Failed)
         23 - CorrelationsTest (Failed)

Compiling and running with clang 4.0 without archer (with or without using OMP-TR4) all tests pass. All unit tests also pass with VS2015, ICC 16&17, GCC 4.8-7.1 and a few other compilers we check less regularly. Thus it is highly unlikely that the unit tests failures are GROMACS source code problems.

Sometimes I get the following kind of error:

15:     #0 pthread_create ??:? (sph-traversals+0x45154b)

15:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
// some more stack trace
One of the following ignores was not ended (in order of probability)

15:   Ignore was enabled at:

It just suddenly appears and is followed be nothing. Only a stack trace is shown.
I am running the executable with TSAN_OPTIONS=ignore_noninstrumented_modules=1 as discussed in #87. So maybe the stack traces of the underlying problems are not shown because of the ignore statement.
The error seems to stem from:
https://github.com/llvm-mirror/compiler-rt/blob/release_60/lib/tsan/rtl/tsan_rtl_thread.cc l.187

full log can be found here: http://vmbungartz10.informatik.tu-muenchen.de/mardyn/blue/organizations/jenkins/AutoPas-Multibranch/detail/gpu-extensions/20/pipeline

Identifying duplicates in data race reports is quite expensive regarding time.
It should be possible to reduce this cost by applying only logging, but no analysis for memory accesses, that were identified as racy code.

The idea would be:

• implement a variant of the Tsan-rtl entrypoints as tsan_read(), that only logs, but skips race analysis and call it something like tsan_read_log(). Important is a symetric function signature.
• when a data race is detected, binary patch the originating tsan_read call to call tsan_read_log instead

This will reduce analysis cost to detect duplicates and reduce output about races between other threads.

A potential issue of this approach is, that TSan potentially will not report races that this memory access has with other code regions. That means, more iterations of fixing code and running TSan might be needed.

Hi,

here is a minimal example

#include <iostream>
#include <string>

int main()
{
  int a = 2222;
#pragma omp parallel for
  for (int i = 0; i < 10000; i++) {
    std::cout << a << std::endl;
    std::cout << std::to_string(a) << std::endl;
  }
}

without archer it prints 2222 all the time with archer to_string prints 4986765

Version:

clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu

Compilation error is generated in ompt-tsan.cpp. 'ompt_frame_t' is no longer used and is replaced with omp_frame_t.

I am moving this issue from #3:

This has been common feedback from our early adopters. Instead of seeing individual data race instances, they want to be able to see "unique data races." This runs in multiple dimensions. E.g., they want to be able to aggregate and reduce races from many reports gathered from running a regression test suite; they want to be able to aggregate and reduce races across multiple processes from a single MPI application run.

So far, the suggestion was to look at the current reporting routine within ThreadSanitizer and see if we can open up its protocol to add custom reduction engine.

Related to: OpenMPToolsInterface/LLVM-openmp#44
For https://github.com/LLNL/dataracebench/blob/develop/micro-benchmarks/target-teams-distribute-orig-no.c the tool is called with an uninitialized value for a barrier. Accessing an element in the expected datastructure leeds to a segmentation fault.
The Archer runtime should make sure to check all incoming pointers, before accessing the data structure. Unexpected NULL pointers should still be logged with the suggestion to create an issue here.

Hi, I followed the instructions for a Stand-alone building, and upon running CMake I get the following error

$ cmake -G Ninja  -D CMAKE_C_COMPILER=clang  -D CMAKE_CXX_COMPILER=clang++  -D CMAKE_BUILD_TYPE=Release  -D CMAKE_INSTALL_PREFIX:PATH=$OPENMP_INSTALL  -D LIBOMP_OMPT_SUPPORT=on  -D LIBOMP_OMPT_BLAME=on  -D LIBOMP_OMPT_TRACE=on ..
-- The C compiler identification is Clang 5.0.1
-- The CXX compiler identification is Clang 5.0.1
-- Check for working C compiler: /usr/lib/llvm/5/bin/clang
-- Check for working C compiler: /usr/lib/llvm/5/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/llvm/5/bin/clang++
-- Check for working CXX compiler: /usr/lib/llvm/5/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:13 (message):
  Direct configuration not supported, please use parent directory!


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.9)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "XXX/ArcherBuild/openmp/runtime/build/CMakeFiles/CMakeOutput.log".

I am using cmake 3.9.6, clang 5.0.1.

Running in the following error:

llvm_src/tools/archer/lib/Transforms/Instrumentation/InstrumentParallel.cpp:58:15: error: virtual function 'getPassName' has a different return type ('const char *') than the function it overrides (which has return type 'llvm::StringRef')
  const char *getPassName() const override;
        ~~~~~~^
/nfs/casc/verification/tools/Archer/workspace/development/llvm_src/include/llvm/Pass.h:100:21: note: overridden virtual function is here
  virtual StringRef getPassName() const;
          ~~~~~~~~~ ^
1 error generated.

The following in tools/archer/CMakeLists.txt is only executed if ${ARCHER_STANDALONE_BUILD} is true:

string(SUBSTRING ${CMAKE_CXX_COMPILER_VERSION} 0 3 LLVM_VERSION)
string(REPLACE "." "" LLVM_VERSION ${LLVM_VERSION})
add_definitions(-DLLVM_VERSION=${LLVM_VERSION})

It should also be done if Archer is built as part of LLVM.

Two tests (task-two and parallel-reduction-nowait) are failing because of:

OMP: Error #13: Assertion failure at kmp_sched.cpp(85).

I know my way around LLVM and also have written a few passes. I also once worked on a paper which dealt with detecting deadlock detection. Please let me know how can I get started?

I'm trying to manually build archer with the instructions in the runtime under the "Stand-alone building with LLVM OpenMP Runtime and ThreadSanitizer OMPT Support" heading.

OS is Ubuntu 16.04.

Everything was going hunky-dory until I ran this command:

cmake -G Ninja \
 -D CMAKE_C_COMPILER=clang-3.9 \
 -D CMAKE_CXX_COMPILER=clang++-3.9 \
 -D OMP_PREFIX:PATH=$OPENMP_INSTALL \
 -D CMAKE_INSTALL_PREFIX:PATH=${ARCHER_INSTALL} \
 ..

That command gave me this output:

-- LLVM llvm-config found at: /usr/bin/llvm-config
CMake Error at CMakeLists.txt:102 (include):
  include could not find load file:

    LLVMConfig


CMake Error at CMakeLists.txt:103 (include):
  include could not find load file:

    HandleLLVMOptions


CMake Error at CMakeLists.txt:104 (include):
  include could not find load file:

    AddLLVM


-- Found OpenMP: /home/lincoln/usr/include  
-- Found OpenMP: /home/lincoln/usr/lib  
CMake Error at lib/CMakeLists.txt:69 (add_llvm_loadable_module):
  Unknown CMake command "add_llvm_loadable_module".

I'm afraid I'm not well-versed in LLVM and have no clue what this means.

On Mac OSX "runOnTsan" is always initialized to 0 which consequently does not initialize the OMPT runtime. The races in the test suite are correctly reported but it reports false positives in the test with no races. On the other end if we force runOnTsan=1 no false positive is reported but Archer does not detect any race in the racy tests.

I have trouble viewing -- https://pruners.github.io/archer

It may have something to do with moving the organization name to PRUNERS from PRUNER?

Context

we are currently using Archer to develop a library for particle simulations:
https://github.com/AutoPas/AutoPas

With archer v1.0.0 no warnings were printed and tests showed that archer worked as it should (it only reported real errors)

We recently tried upgrading from archer v1.0.0 and clang v4.0 to archer v2.0.0 and clang v6.0 and were confronted with a lot of warnings:

Bug

With archer v2.0.0 we get a lot of warnings, mostly in pthread's mutex locking/unlocking see
archerlog.txt

They have the forms:
a) (clearly from the mutexes)

WARNING: ThreadSanitizer: data race (pid=811)
10:   Atomic read of size 1 at 0x7b6800005f40 by main thread:
10:     #0 pthread_mutex_lock ??:? (runTests+0x5a64a7)
...
10:   Previous write of size 1 at 0x7b6800005f40 by thread T8:
10:     #0 pthread_mutex_init ??:? (runTests+0x58f96a)
...
10:   Location is heap block of size 1504 at 0x7b6800005a00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T8 (tid=820, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_pthread_mutex_lock

or b)

10: WARNING: ThreadSanitizer: data race (pid=811)
10:   Write of size 8 at 0x7b6800005100 by thread T4:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10:   Previous read of size 8 at 0x7b6800005100 by thread T7:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10: 
10:   Location is heap block of size 1504 at 0x7b6800004e00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T4 (tid=816, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in memcpy

Steps to reproduce:

1. Download autopas:

git clone https://github.com/AutoPas/AutoPas.git AutoPas

2. Use our docker image to reproduce the warnings:

cd AutoPas
mkdir build
cd build
docker run -v `pwd`/..:/autopas/ -w /autopas/build/ -it autopas/autopas-build-archer:latest bash -i -c "CXXFLAGS=-Wno-pass-failed CC=clang-archer CXX=clang-archer++ cmake -G Ninja -DCMAKE_BUILD_TYPE=DEBUG -DUSE_VECTORIZATION=OFF .. && ninja -j 4 && ctest --verbose"

Further information

I have tested it with the clang/llvm 6.0 version in ubuntu 16.04 (clang 6.0.0), as well as the latest official release from http://apt.llvm.org/ (also ubuntu 16.04, xenial).

The openmp reposity versions I tested are:

1. release_60 (d5aa29c)
2. latest properly working version from master (b1a95ef, from May 25, 2018), mainly before they started renaming a few things, e.g., ompt_frame_t to omp_frame_t

I only tested the archer master, as the v2.0.0 tag is actually identical to it.

All configurations I tested produced the same warnings.

The dockerfile can be found here:
for v2.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/blob/master/buildenv/archer/Dockerfile

for v1.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/tree/master/buildenv/archer-v1.0.0

Closing words

I did not yet find the time to just test archer 2.0.0 on an example, so sorry for that.
Help would be appreciated :)

Given

#include <thread>
void f() {
    #pragma omp parallel
    {
    }
}
int main() {
    std::thread t1(f);
    std::thread t2(f);
    t1.join();
    t2.join();
}

And Archer (dc4e363) build with out of source with LLVM 4.0 and OMP-TR4 I get a runtime SegFault:

#0  0x00007ffff73a1bd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000043979f in __interceptor_pthread_mutex_lock ()
    at /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:3672
#2  0x00007ffff7bccd43 in __gthread_mutex_lock(pthread_mutex_t*) () from /home/schulzro/tools/archer/lib/libarcher.so
#3  0x00007ffff7bccbe5 in std::mutex::lock() () from /home/schulzro/tools/archer/lib/libarcher.so
#4  0x00007ffff7bccb69 in DataPool<ParallelData, 4>::getData() () from /home/schulzro/tools/archer/lib/libarcher.so

For some reason, https://martine.github.io/ninja reference used in README.md is broken. Didn't know what should be the alternative so I couldn't do a PR.

Given:

#include <x86intrin.h>
int main() {
    __m256 x = _mm256_set1_ps(1);
    return 0;
}

And Archer (dc4e363) build with out of source with LLVM 4.0 and OMP-TR4 I get:

1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'InstrumentParallel' on function '@_mm256_set1_ps'
clang-4.0: error: unable to execute command: Segmentation fault (core dumped)

@jprotze I made a branch mac_osx, I tried to deal with the weak symbols and currently, it passes most of the tests except does not catch some races. One thing that I noticed is that these tests sometimes randomly passes most of the time they don't.
If you take a look to ompt-tsan.cpp, you can see how I dealt with the weak symbols, if that's ok I am not sure what could other problems be.

@jprotze without suppressions I am getting two false positives:

SUMMARY: ThreadSanitizer: data race /home/simone/pruners/LLVM-openmp/runtime/build/../src/z_Linux_util.cpp:1721:14 in void __kmp_resume_template<kmp_flag_64>(int, kmp_flag_64*)
SUMMARY: ThreadSanitizer: data race /home/simone/pruners/LLVM-openmp/runtime/build/../src/kmp.h:1681:10 in copy_icvs(kmp_internal_control*, kmp_internal_control*)

I won't change the pass for now.

This should be endif()

It looks like Archer fails to build with LLVM 9:

[ 26%] Building CXX object lib/CMakeFiles/LLVMArcher.dir/Transforms/Instrumentation/InstrumentParallel.cpp.o
/usr/workspace/lee218/delete/spack-ulna-openmpi/ArcherBuild/archer/lib/Transforms/Instrumentation/InstrumentParallel.cpp:188:45: error: no matching function for call to 'cast'
    Function* __tsan_default_suppressions = cast<Function>(M->getOrInsertFunction("__tsan_default_suppressions",
                                            ^~~~~~~~~~~~~~
/usr/workspace/lee218/delete/spack-ulna-openmpi/opt/spack/linux-rhel7-broadwell/gcc-8.1.0/llvm-9.0.0-7onw4vzicjqun2vojttomwc7egcfmsu4/include/llvm/Support/Casting.h:256:44: note: candidate function [with X = llvm::Function, Y = llvm::FunctionCallee] not viable: expects an l-value for 1st argument
inline typename cast_retty<X, Y>::ret_type cast(Y &Val) {
                                           ^
/usr/workspace/lee218/delete/spack-ulna-openmpi/opt/spack/linux-rhel7-broadwell/gcc-8.1.0/llvm-9.0.0-7onw4vzicjqun2vojttomwc7egcfmsu4/include/llvm/Support/Casting.h:249:1: note: candidate template ignored: requirement '!is_simple_type<llvm::FunctionCallee>::value' was not satisfied [with X = llvm::Function, Y = llvm::FunctionCallee]
cast(const Y &Val) {
^
/usr/workspace/lee218/delete/spack-ulna-openmpi/opt/spack/linux-rhel7-broadwell/gcc-8.1.0/llvm-9.0.0-7onw4vzicjqun2vojttomwc7egcfmsu4/include/llvm/Support/Casting.h:263:46: note: candidate template ignored: could not match 'Y *' against 'llvm::FunctionCallee'
inline typename cast_retty<X, Y *>::ret_type cast(Y *Val) {
                                             ^
/usr/workspace/lee218/delete/spack-ulna-openmpi/opt/spack/linux-rhel7-broadwell/gcc-8.1.0/llvm-9.0.0-7onw4vzicjqun2vojttomwc7egcfmsu4/include/llvm/Support/Casting.h:271:1: note: candidate template ignored: could not match 'unique_ptr<type-parameter-0-1, default_delete<type-parameter-0-1> >' against 'llvm::FunctionCallee'
cast(std::unique_ptr<Y> &&Val) {
^
/usr/workspace/lee218/delete/spack-ulna-openmpi/ArcherBuild/archer/lib/Transforms/Instrumentation/InstrumentParallel.cpp:204:15: error: no viable conversion from 'llvm::FunctionCallee' to 'llvm::Constant *'
    Constant* constant = M->getOrInsertFunction("__archer_get_omp_status",
              ^          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
make[2]: *** [lib/CMakeFiles/LLVMArcher.dir/Transforms/Instrumentation/InstrumentParallel.cpp.o] Error 1
make[1]: *** [lib/CMakeFiles/LLVMArcher.dir/all] Error 2
make: *** [all] Error 2

This appears to be related to https://bugs.freedesktop.org/show_bug.cgi?id=109540. A proper fix may look something like the commit pointed to in the previous link: llvm-mirror/llvm@9ec60d7#diff-295d2c56655729b2bd6dc1dfca7c2f0e.

@lee218llnl Hey Greg, in the clang-archer wrapper the configuration allows to insert the correct rpath, etc. However when we use the wrapper to compile a file the .o we get the warning:

clang-3.9: warning: -Wl,-rpath=/home/simone/usr/lib: 'linker' input unused
clang-3.9: warning: argument unused during compilation: '-L/home/simone/usr/lib'

because we are not linking yet. Do you know a way how to avoid this? Checking for the -c flag and put an if-then-else inside the wrapper would be enough?

Thanks!

Just noticed that the logo of our Travis CI test show an error. Didn't have the time to look at this with any details.