Using -fopenmp breaks LibTooling

[viroulep]

Hi, We've been working on updating our tool to the last clang-omp version, and we encountered a weird bug. It's reproducible with the simple example provided by clang's documentation :

// Declares clang::SyntaxOnlyAction.
#include "clang/Frontend/FrontendActions.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
// Declares llvm::cl::extrahelp.
#include "llvm/Support/CommandLine.h"

using namespace clang::tooling;
using namespace llvm;

// Apply a custom category to all command-line options so that they are the
// only ones displayed.
static cl::OptionCategory MyToolCategory("my-tool options");

// CommonOptionsParser declares HelpMessage with a description of the common
// command-line options related to the compilation database and input files.
// It's nice to have this help message in all tools.
static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);

// A help message for this specific tool can be added afterwards.
static cl::extrahelp MoreHelp("\nMore help text...");

int main(int argc, const char **argv) {
  CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
  ClangTool Tool(OptionsParser.getCompilations(),
                 OptionsParser.getSourcePathList());
  return Tool.run(newFrontendActionFactory<clang::SyntaxOnlyAction>().get());
}

Compilation can be done with no particular compiler since the bug occurs at runtime, eg you can use :

g++ simple_tool.cpp -std=c++11 -lclangFrontendTool -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangStaticAnalyzerFrontend -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangAnalysis -lclangARCMigrate -lclangRewriteFrontend -lclangRewriteCore -lclangEdit -lclangAST -lclangLex -lclangBasic -lclangTooling `llvm-config --cxxflags --ldflags --libs all --system-libs` -fno-rtti

Given this very simple file

int main()
{
    return 0;
}

I assume the execution should not fail with or without the -fopenmp, however this is what I get :

$ ./a.out foo.c --
$ echo $?
0
$ ./a.out foo.c -- -fopenmp
Unable to create unique ID to input file - invalid input file status??
UNREACHABLE executed at /home/fifi/inria/compilateur/openmpclang/llvm/tools/clang/lib/Driver/Tools.cpp:2597!
zsh: abort      ./a.out foo.c -- -fopenmp

I've looked a bit into it, CommonOptionsParser is actually trying to open "placeholder.cpp", which is a dummy file added by the CompilationDatabase stuff to the compiler arguments. I don't know why adding this particular flag leads to this error, but it's definitely a regression since it did work before the merge of 3.5.

[sfantao]

Hi Philippe,

Thanks for reporting this!

The OpenMP offloading support relies on the file Id in the file system to generate an unique ID for the target regions that is going to be offloaded. This patch was committed last week, that is why you are getting this problem now. I'll have to look closely into this, but my recollection is that the file existence is supposed to be tested by the clang driver before reaching that point. So, I'm not sure exactly what mechanism should have prevented you from getting this error. I'll look into this and post my conclusions here.

Thanks again, Samuel

Philippe Virouleau notifications@github.com wrote on 10/13/2014 09:42:02 AM:

From: Philippe Virouleau notifications@github.com To: clang-omp/clang clang@noreply.github.com Date: 10/13/2014 09:42 AM Subject: [clang] Using -fopenmp breaks LibTooling (#47)

Hi, We've been working on updating our tool to the last clang-omp version, and we encountered a weird bug. It's reproducible with the simple example provided by clang's documentation : // Declares clang::SyntaxOnlyAction.

include "clang/Frontend/FrontendActions.h"

include "clang/Tooling/CommonOptionsParser.h"

include "clang/Tooling/Tooling.h"

// Declares llvm::cl::extrahelp.

include "llvm/Support/CommandLine.h"

using namespace clang::tooling; using namespace llvm;

// Apply a custom category to all command-line options so that they are the // only ones displayed. static cl::OptionCategory MyToolCategory("my-tool options");

// CommonOptionsParser declares HelpMessage with a description of the common // command-line options related to the compilation database and input files. // It's nice to have this help message in all tools. static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);

// A help message for this specific tool can be added afterwards. static cl::extrahelp MoreHelp("\nMore help text...");

int main(int argc, const char **argv) { CommonOptionsParser OptionsParser(argc, argv, MyToolCategory); ClangTool Tool(OptionsParser.getCompilations(), OptionsParser.getSourcePathList()); return Tool.run(newFrontendActionFactoryclang::SyntaxOnlyAction().get ()); }

Compilation can be done with no particular compiler since the bug occurs at runtime, eg you can use : g++ simple_tool.cpp -std=c++11 -lclangFrontendTool -lclangFrontend - lclangDriver -lclangSerialization -lclangCodeGen -lclangParse - lclangSema -lclangStaticAnalyzerFrontend - lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore - lclangAnalysis -lclangARCMigrate -lclangRewriteFrontend - lclangRewriteCore -lclangEdit -lclangAST -lclangLex -lclangBasic - lclangTooling llvm-config --cxxflags --ldflags --libs all --system- libs -fno-rtti

Given this very simple file int main() { return 0; }

I assume the execution should not fail with or without the -fopenmp, however this is what I get : $ ./a.out foo.c -- $ echo $? 0 $ ./a.out foo.c -- -fopenmp Unable to create unique ID to input file - invalid input file status?? UNREACHABLE executed at /home/fifi/inria/compilateur/openmpclang/ llvm/tools/clang/lib/Driver/Tools.cpp:2597! zsh: abort ./a.out foo.c -- -fopenmp

I've looked a bit into it, CommonOptionsParser is actually trying to open "placeholder.cpp", which is a dummy file added by the CompilationDatabase stuff to the compiler arguments. I don't know why adding this particular flag leads to this error, but it's definitely a regression since it did work before the merge of 3.5. — Reply to this email directly or view it on GitHub.[image removed]

[viroulep]

Ok, cool ! FYI our current dirty workaround is to simply not push the dummy file in clang, and duplicate the input file on command line like this :

./tool file.c [...] -- file.c [...]

This probably breaks something elsewhere, but works just fine for us.

[sfantao]

Hi Phillippe,

This issue should now be fixed in commit bf475046fda9b3d9984fabebd3bcbfcf54c2d907.

Thanks for reporting the problem! Samuel

Philippe Virouleau notifications@github.com wrote on 10/13/2014 01:38:50 PM:

From: Philippe Virouleau notifications@github.com To: clang-omp/clang clang@noreply.github.com Cc: Samuel F Antao/Watson/IBM@IBMUS Date: 10/13/2014 01:38 PM Subject: Re: [clang] Using -fopenmp breaks LibTooling (#47)

Ok, cool ! FYI our current dirty workaround is to simply not push the dummy file in clang, and duplicate the input file on command line like this : ./tool file.c [...] -- file.c [...]

This probably breaks something elsewhere, but works just fine for us. — Reply to this email directly or view it on GitHub.[image removed]

[viroulep]

Great, thanks !