search for: sanctity

...ts()/errs() just as they do now. Nothing would really change in the way LLVM operates by default In fact, before we had raw_ostream, we had a dbgs() sort of stream, which was intended to be used in debug statements. I'm not strongly opposed to this (it would be much better than violating the sanctity of outs() :), but I'm still unclear why you care so much about DEBUG output. If we had a dbgs() again, it should *only* be used from within DEBUG macros (for example, the linker shouldn't use it). Would that be enough to achieve your goal? -Chris -------------- next part -------------- A...

...ow. > Nothing would really change in the way LLVM operates by default > > > In fact, before we had raw_ostream, we had a dbgs() sort of stream, which > was intended to be used in debug statements. I'm not strongly opposed to > this (it would be much better than violating the sanctity of outs() :), but > I'm still unclear why you care so much about DEBUG output. If we had a > dbgs() again, it should *only* be used from within DEBUG macros (for > example, the linker shouldn't use it). Would that be enough to achieve > your goal? > It's not so much DE...

This is not, strictly speaking, an LLVM issue, but it is an implementation matter that a compiler using LLVM needs to handle. I've got resolutions for other platforms, but I'm not seeing how to get this done for PowerPC, and I'ld appreciate suggestions or pointers. For BitC procedures that require an environment pointer, our general approach has been to construct a heap-allocated

On Fri, Jun 1, 2012 at 10:17 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 1, 2012, at 7:41 PM, Justin Holewinski wrote: > > > >> > Unfortunately, the use of outs() and (especially) errs() is rampant - a >> simple grep of the 3.1 source tree shows about 1,500 instances. One of the >> first things we had to implement in order to make LLVM

...uld really change in the way LLVM operates by default >> >> >> In fact, before we had raw_ostream, we had a dbgs() sort of stream, which >> was intended to be used in debug statements. I'm not strongly opposed to >> this (it would be much better than violating the sanctity of outs() :), but >> I'm still unclear why you care so much about DEBUG output. If we had a >> dbgs() again, it should *only* be used from within DEBUG macros (for >> example, the linker shouldn't use it). Would that be enough to achieve >> your goal? >> >...

On Jun 1, 2012, at 7:41 PM, Justin Holewinski wrote: > > > > Unfortunately, the use of outs() and (especially) errs() is rampant - a simple grep of the 3.1 source tree shows about 1,500 instances. One of the first things we had to implement in order to make LLVM usable is something very similar to what Justin has proposed. Centralizing control of the output in outs()/errs() would

notice: /subject.sol1.net/virtual_mail_server/File[/etc/postfix]/checksum: checksum changed ''{time}Thu Jan 25 16:31:08 EST 2007'' to ''{time}Thu Jan 25 16:36:39 EST 2007'' I know there''s something weird in the directory modification detection that causes the next run after things actually change to suffer from this problem, but I''m getting it

Hey We have a static analyzer setup for Xen called Coverity. It allows the code to be inspected for bugs and such. Originally I setup this so that we could make sure that there are no bugs that cause security issues - and as such invited only folks on the security Xen mailing list. But there are other folks who I am sure would like to contribute and as Coverity is pretty amazing at analyzing