search for: namespacification

Displaying 5 results from an estimated 5 matches for "namespacification".

Did you mean: namespac'ification
2013 Sep 18
0
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...se to me, and having tool options use toolopt<> (or something) also makes perfect sense. If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/9f083950/attachment.html>
2013 Sep 17
3
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style > appending section? I think we can make this work for all toolchains we > support. > Andy and I talked about this, but I don't think its worth it. My opinion is: 1. For tool options (the top-level llc, opt, llvm-as
2013 Sep 19
3
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...and having tool options use toolopt<> (or something) also makes perfect sense. > > If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow? Obviously, based on the 18 responses I've gotten, the tone of my first email was misleading. I don’t want to stifle discussion, but to be clear, the only thing I propose to tackle immediately is the removal of stati...
2013 Sep 19
0
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...l options use toolopt<> (or something) also makes perfect > sense. > > If you're going to go and tackle pass-specific options, I think that we > should consider changing the syntax and overall design of the command line > options. We already have some manual name mangling/namespacification of > options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow? > > > Obviously, based on the 18 responses I've gotten, the tone of my first > email was misleading. > > I don’t want to stifle discussion, but to be clear, the only thing I > propose to tack...
2003 Nov 18
0
LLVM Status Update
...VM interpreter work. In particular, he implemented exception handling and variable argument handling support. 5. Bugpoint no longer crashes while performing "final cleanups". This allowed removing the -disable-final-cleanups option (yaay). 6. Reid Spencer contributed the LLVM Namespacification patch, which allows LLVM to interoperate with other people's source bases better: http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000554.html 7. Misha is on a quest to clean up our web pages, and make them really be HTML 4.0 compliant. In the process he's converting the...