similar to: llvm-lit: 2>&1 and FileCheck

On Dec 18, 2009, at 6:36 PM, David Greene wrote: >>> +// Signal handlers - dump debug output on termination. >>> +static void debug_user_sig_handler(void *Cookie) >>> +{ >>> + llvm::circular_raw_ostream *logout = >>> + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); >> >> Please do not use dynamic_cast, we're

On Friday 18 December 2009 19:56, Chris Lattner wrote: > > +// -debug-buffer-size - This is a command line op0tion to set the > > size > > +// of the debug stream circular buffer. The value is the number of > > +// characters to save. > > +static cl::opt<unsigned> > > +DebugBufferSize("debug-buffer-size", > > +

On Friday 18 December 2009 12:28, Chris Lattner wrote: > This is looking a lot better, here are some more comments: > > + /// current_pos - Return the current position within the stream, > > + /// not counting the bytes currently in the buffer. > > + virtual uint64_t current_pos() { > > I didn't notice this earlier, but is there any reason for current_pos

On Friday 18 December 2009 19:47, Chris Lattner wrote: > On Dec 18, 2009, at 3:46 PM, David Greene wrote: > > + /// circular_raw_ostream - A raw_ostream that saves its output in a > > + /// circular buffer. > > A better description would be "which *can* save its data to a circular > buffer, or can pass it through directly to an underlying stream if > specified

On Friday 18 December 2009 17:27, David Greene wrote: > > Here's the updated patch. > > Well, that didn't go through right. Here it is again. Argh! Stupid bug fixed. :) Index: include/llvm/Support/circular_raw_ostream.h =================================================================== --- include/llvm/Support/circular_raw_ostream.h (revision 0) +++

On Wednesday 16 December 2009 13:35, David Greene wrote: > > Please make BufferSize an 'unsigned' and default it to 8192. Please use > > PRESERVE_STREAM instead of 'false'. Here's an updated version of the circular buffer. Ok to check in? -Dave Index: include/llvm/Support/circular_raw_ostream.h

On Dec 18, 2009, at 3:46 PM, David Greene wrote: > > + /// circular_raw_ostream - A raw_ostream that saves its output in a > + /// circular buffer. A better description would be "which *can* save its data to a circular buffer, or can pass it through directly to an underlying stream if specified with a buffer of zero." When it is buffering, what causes it to flush? Your

On Dec 17, 2009, at 3:41 PM, David Greene wrote: > On Wednesday 16 December 2009 13:35, David Greene wrote: > >>> Please make BufferSize an 'unsigned' and default it to 8192. Please use >>> PRESERVE_STREAM instead of 'false'. > > Here's an updated version of the circular buffer. Ok to check in? This is looking a lot better, here are some more

On Friday 18 December 2009 20:20, David Greene wrote: > I wanted something to signify in the output where the debug dump starts. > That's for that case where some stuff might still get output through > errs(). I anticipate that while I'll change most uses of errs() to dbgs(), > we probably don't want to change all of them. > > I agree the naming here is poor.

On Dec 21, 2009, at 8:05 AM, David Greene wrote: > On Friday 18 December 2009 20:20, David Greene wrote: > >> I wanted something to signify in the output where the debug dump starts. >> That's for that case where some stuff might still get output through >> errs(). I anticipate that while I'll change most uses of errs() to dbgs(), >> we probably don't

Here's the patch to provide dbgs(). By default it works just like errs(). When -debug-buffer-size=N (N > 0) is set, it buffers output sent to it and dumps it at program termination via a signal handler. Please review. Thanks! -Dave Index: include/llvm/Support/Debug.h =================================================================== ---

On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > Or I think I can just assume (Yikes!) that if the signal handler is > > invoked it will really be a circular_raw_ostream since the handler > > should (!) only be set up in debug mode. > > > > That scares me a bit, though. > > Why don't you just check #ifndef NDEBUG like the code that sets it up?

On 2009-12-21 18:06, David Greene wrote: > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > >>> Or I think I can just assume (Yikes!) that if the signal handler is >>> invoked it will really be a circular_raw_ostream since the handler >>> should (!) only be set up in debug mode. >>> >>> That scares me a bit, though. >>>

On Dec 17, 2009, at 4:02 PM, David Greene wrote: > Here's the patch to provide dbgs(). By default it works just like > errs(). > When -debug-buffer-size=N (N > 0) is set, it buffers output sent to > it and > dumps it at program termination via a signal handler. > > Please review. Thanks! > > -Dave > > Index:

Hi, I'm looking for some feedback on pain points people have with FileCheck in terms of missing features to help people interested in working on FileCheck to prioritize the work accordingly. I am personally interested in improving FileCheck on 2 issues whenever time permits it: * being able to test for consecutive lines in arbitrary order, i.e. something akin to CHECK-DAG blocks where

On Dec 16, 2009, at 8:12 AM, David Greene wrote: >>> >>> What, specifically, do you want reviewed before I start checking in? >>> I'll be happy to prepare a patch that shows just that. >> >> I want a patch that does one thing (e.g. implements dbgs(), > > Ok, let's start with that. Here's the patch to add the circular raw_ostream. This

On Dec 15, 2009, at 6:33 PM, David Greene wrote: > On Tuesday 15 December 2009 20:11, Chris Lattner wrote: > >> Please send complete and minimal patches to avoid wasting reviewer's >> time, > > What do you want, complete or minimal? I don't want to pre-send 50 > or so patches (one per source file) that simply change errs() to dbgs(). > Thus I thought I

Hi all- I hope this is the right place for this. Anyway, the primary usage for the utility "FileCheck" is to pattern match for specific values in a stream. This is perfectly consistent and deterministic for the most part! However, when validating clang's LLVM-IR generation, it is possible to make an invalid match against the top few generated lines (the LLVM-IR Headers), which are

Hey Nadav, I'd humbly suggest that rather than use 3 directly, you should add a shared constant between these two passes, so when one changes, the other doesn't need to be updated. It would also ensure this bit of info about what needs to be updated isn't only contained in the comments.. On Fri, Jul 26, 2013 at 4:07 PM, Nadav Rotem <nrotem at apple.com> wrote: > Author:

On Monday 21 December 2009 10:14, Török Edwin wrote: > On 2009-12-21 18:06, David Greene wrote: > > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > >>> Or I think I can just assume (Yikes!) that if the signal handler is > >>> invoked it will really be a circular_raw_ostream since the handler > >>> should (!) only be set up in debug mode. >