search for: oneormore

...urn it off again. That's not different from before. > That is, unless there is some way to do it other than by passing > command line options to cl::ParseCommandLineOptions. The last > time I looked the problem was that DebugOnly was defined as > cl::ValueRequired rather than cl::OneOrMore, so the CLI would > reject any subsequent setting. > > If there is some way around this, I'd be delighted to know. This will require modifying code. Patches welcome. Evan > > Andrew. > > _______________________________________________ > LLVM Developers mailing list &g...

...e was changed. You can turn it on once, but you can never turn it off again. That is, unless there is some way to do it other than by passing command line options to cl::ParseCommandLineOptions. The last time I looked the problem was that DebugOnly was defined as cl::ValueRequired rather than cl::OneOrMore, so the CLI would reject any subsequent setting. If there is some way around this, I'd be delighted to know. Andrew.

On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote: > Chris Lattner wrote: >> On Apr 30, 2009, at 9:38 AM, David Greene wrote: >>> On Wednesday 29 April 2009 19:22, Chris Lattner wrote: >>>> On Apr 29, 2009, at 8:39 AM, David Greene wrote: >>>>> This patch changes the LLVM API. We should have a process for >>>>> deprecating

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached