search for: registeredoptionlist

...flags would specify the action to take, each library having its own globally defined options. Could be some interference here from command line arguments not understood by the initial option action list, but I'm under the current impression that at least the global holding the option list (RegisteredOptionList) can be modified after the fact. I'll check further when I get there. Now if only work would get out of the way. ;-) Garrison On Dec 9, 2010, at 18:32, Chris Lattner wrote: > > On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > >> Is there a reason that RecordKeeper:: getA...

Hi, I can confirm this problem. We use clang's libtooling ToolInvocation object and the second module fails to compile even through it's a completely fresh instance. Adding -fno-vectorize explicitly seems to work around this problem, but does anyone know a real fix? ciao, Mario Am 20.06.13 15:07, schrieb Alan Garny: > My application generates some C code which I then compile using

...something similar) is called options are shown by category and then alphabetically within a category. I've taken a look at the current HEAD of LLVM source code and as far as I can tell (1) currently isn't possible because of the following line in lib/support/CommandLine.cpp static Option *RegisteredOptionList = 0; so the pointer to the underlying storage model for options is hidden from clients such as KLEE. I also don't see any code to support (2). I noticed that "clang --help-hidden" shows options categorised but I couldn't figure out how this was working. The options in other cate...

On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote: > Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation > accesses the global Records instance instead of just referencing itself? > > As far as I can tell from the usage: > > 1) Records has the linkage as extern RecordKeeper Records in Record.h > 2) Is instantiated as a global in TableGen >

Hi, My application generates some C code which I then compile using LLVM+Clang before running it. For the compilation side of things, I have a class which one of the methods (the CompilerEngine::compileCode() method in https://raw.github.com/opencor/opencor/llvm_3.3/src/plugins/misc/Compiler/sr c/compilerengine.cpp) is based on the code from the clang-interpreter example

Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation accesses the global Records instance instead of just referencing itself? As far as I can tell from the usage: 1) Records has the linkage as extern RecordKeeper Records in Record.h 2) Is instantiated as a global in TableGen 3) All llvm uses of getAllDerivedDefinitions SEEM to be manifested as a message to this

...ple does?) * a limitation of the simple clang-interpreter example * or is state being held in llvm:cl across compilation requests? >From looking at the code and debugging, it appears that the call to Clang.ExecuteAction(*Act) the second time around causes llvm::cl::RegisteredOptionList (from lib/Support/CommandLine.cpp) to contain a huge (unbounded?) number of nodes. This becomes an issue when the list is processed in GetOptionInfo(). Any ideas? Thanks for your help, Jay //============================================================================= /******* test1.c *******...

...12EnableTiming", "EnableTiming"}, {"_ZL11TheTimeInfo", "TheTimeInfo"}, {"_ZL15PassRegistryObj", "PassRegistryObj"}, {"_ZL4Lock", "Lock"}, {"_ZL8MoreHelp", "MoreHelp"}, {"_ZL20RegisteredOptionList", "RegisteredOptionList"}, {"_ZL15ProgramOverview", "ProgramOverview"}, {"_ZL13NormalPrinter", "NormalPrinter"}, {"_ZL13HiddenPrinter", "HiddenPrinter"}, {"_ZL3HOp", "HOp"}, {&quo...