[PATCH] Allow for the use of StringRef command line options instead of cl::opt<std::string>

Puyan Lotfi plotfi at apple.com
Wed Aug 14 16:06:14 PDT 2013


Oh wow. I see that.

I am not completely sure how the char* arrays would get handled this way.
I did not make any clang modifications in this patch (although since clang is using the cl library it is affected) but I noticed that the use of cl:: in the llvm source tree made use of global cl::opt variables that specify the opt type.
I don’t see that in the files handling the -mllvm options; I’ll have to look at the CommandLine.cpp code a little more closely to be sure in this case that the char*’s aren’t being implicitly put into StringRefs that might have their data pointers deallocated after cl::ParseCommandLineOptions() is called. 

Thanks

-Puyan



On Aug 14, 2013, at 11:41 AM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Aug 13, 2013, at 9:55 AM, Puyan Lotfi <plotfi at apple.com> wrote:
> 
>> Oops, forgot to reattach the patch file.
> 
> I like this a lot, this seems like clearly the right way to go.  One concern: "ParseCommandLineOptions" is most commonly called on argc/argv coming into main, but that isn't always the case.  Clang for example, turns the -mllvm options into an an array and parses them (see clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp and clang/lib/CodeGen/BackendUtil.cpp).
> 
> In this case, what keeps the memory from being deallocated underneath the StringRefs?
> 
> -Chris
> 





More information about the llvm-commits mailing list