[Support] Add stream tie function and use it for errs()

[jhenderson]

Summary

errs() is now tied to outs() so that if something prints to errs(), outs() will be flushed before the printing occurs. This avoids interleaving output between the two and is consistent with standard cout and cerr behaviour.

[MaskRay]

Looks great!

llvm/include/llvm/Support/raw_ostream.h

312

There is another private specifier above. You can avoid this private.

505–509

Don’t duplicate function or class name at the beginning of the comment.

http://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments

[MaskRay]

Sorry, undo LGTM. Is it worth making tied_to an opt-in feature? i.e. for command line utilities, they can run errs().tie(outs()).

We can probably even fold the TiedTo field into raw_fd_ostream. Just a thought.

[jhenderson]

In D81156#2074078, @MaskRay wrote:

Sorry, undo LGTM. Is it worth making tied_to an opt-in feature? i.e. for command line utilities, they can run errs().tie(outs()).

The issue with that is that all tools that want it (most of them?) will have to explicitly do the work for that. One of the motivations to change errs() is to prevent the need to require code in llvm-dwarfdump (and other tools) to be used to prevent stream interleaving. @dblaikie/@JDevlieghere etc what are your opinions? Is it acceptable to require tools to specify the one-line change here?

We can probably even fold the TiedTo field into raw_fd_ostream. Just a thought.

Folding it into raw_fd_ostream would be reasonable. We could have an Optional stream as the tied-to stream for this, and it would probably simplify the required code (no need to provide a template parameter etc to identify the base stream). tie and untie could be provided to set/unset the tied-to stream.

If we went with that approach, we could always have errs() and outs() tied as proposed in the current patch, but with the ability for tools to opt-out if they don't want the behaviour. What do you think?

[labath]

In D81156#2079144, @jhenderson wrote:

In D81156#2074078, @MaskRay wrote:

Sorry, undo LGTM. Is it worth making tied_to an opt-in feature? i.e. for command line utilities, they can run errs().tie(outs()).

The issue with that is that all tools that want it (most of them?) will have to explicitly do the work for that. One of the motivations to change errs() is to prevent the need to require code in llvm-dwarfdump (and other tools) to be used to prevent stream interleaving. @dblaikie/@JDevlieghere etc what are your opinions? Is it acceptable to require tools to specify the one-line change here?

We can probably even fold the TiedTo field into raw_fd_ostream. Just a thought.

Folding it into raw_fd_ostream would be reasonable. We could have an Optional stream as the tied-to stream for this, and it would probably simplify the required code (no need to provide a template parameter etc to identify the base stream). tie and untie could be provided to set/unset the tied-to stream.

If we went with that approach, we could always have errs() and outs() tied as proposed in the current patch, but with the ability for tools to opt-out if they don't want the behaviour. What do you think?

I don't think it's necessary, but that approach makes sense to me -- though I'd go with tie(nullptr) instead of untie() for symmetry with std::basic_ios.

llvm/unittests/Support/raw_ostream_test.cpp

385

This appears to be unused.

[jhenderson]

Add tie() function to raw_ostream instead of using a new class. Also expand unit testing to cover the related areas.

[jhenderson]

llvm/unittests/Support/raw_ostream_test.cpp

385

Oops, thanks. I've removed it locally.

[JDevlieghere]

Looks good to me, but I'd like Pavel to sign off as well.

[MaskRay]

In D81156#2079144, @jhenderson wrote:

In D81156#2074078, @MaskRay wrote:

Sorry, undo LGTM. Is it worth making tied_to an opt-in feature? i.e. for command line utilities, they can run errs().tie(outs()).

The issue with that is that all tools that want it (most of them?) will have to explicitly do the work for that. One of the motivations to change errs() is to prevent the need to require code in llvm-dwarfdump (and other tools) to be used to prevent stream interleaving. @dblaikie/@JDevlieghere etc what are your opinions? Is it acceptable to require tools to specify the one-line change here?

We can probably even fold the TiedTo field into raw_fd_ostream. Just a thought.

Folding it into raw_fd_ostream would be reasonable. We could have an Optional stream as the tied-to stream for this, and it would probably simplify the required code (no need to provide a template parameter etc to identify the base stream). tie and untie could be provided to set/unset the tied-to stream.

If we went with that approach, we could always have errs() and outs() tied as proposed in the current patch, but with the ability for tools to opt-out if they don't want the behaviour. What do you think?

Let's make it opt-out for now. Hopefully there aren't any tool requiring errs().tie(nullptr)

llvm/include/llvm/Support/raw_ostream.h

70

Inconsistent comment marker. // -> ///

71

* => *

303

TieTo -> TiedTo

[labath]

Yep, this is great.

llvm/unittests/Support/raw_ostream_test.cpp

385

It looks like it's still here. :)

[jhenderson]

llvm/unittests/Support/raw_ostream_test.cpp

385

Yeah, I missed it in my last update, and was too lazy to upload a new diff for just that :)

I'll triple check that it's gone before committing though!

[jhenderson]

Address review comments.

[jhenderson]

Upload correct diff.

llvm/include/llvm/Support/raw_ostream.h

303

I'm not going to make this change, since this function tells the class to tie itself to TieTo. TiedTo would imply it has already been tied to it, which would be false.

[labath]

llvm/unittests/Support/raw_ostream_test.cpp

385

Sure, no worries.:)

[MaskRay]

llvm/unittests/Support/raw_ostream_test.cpp

436

I added a pairing TiedTo.tie(nullptr);

TiedStream was destroyed before TiedTo and when flushing TiedTo, TiedStream has been destroyed => asan stack-use-after-scope failure.

Fixed in ceaee253f4f3079d2786697d099e43e9f61f897a

[sammccall]

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

[jhenderson]

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

As to why this was decided to be the default in the first place: a) it matches the default behaviour of std::cout/std::cerr, and b) in the typical case of printing an error message of some kind, it ensures we don't interleave error output in the middle of a line of other output, which seems like an almost universally good thing to me. But yet, we missed the thread-safety (or rather lack thereof) aspect of this change.

[sammccall]

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

As to why this was decided to be the default in the first place: a) it matches the default behaviour of std::cout/std::cerr, and b) in the typical case of printing an error message of some kind, it ensures we don't interleave error output in the middle of a line of other output, which seems like an almost universally good thing to me. But yet, we missed the thread-safety (or rather lack thereof) aspect of this change.

cout and cerr have been banned in every codebase I've done much IO in, so I had to look this up :-)
However they're *threadsafe*, and so synchronizing there is pretty different.
Per cppreference the specified behavior is also not the same: "synchronized C++ streams are guaranteed to be thread-safe (individual characters output from multiple threads may interleave, but no data races occur)" - this seems to apply to multiple streams too.

[jhenderson]

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

[sanjoy.google]

In D81156#2084324, @jhenderson wrote:

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

[dblaikie]

In D81156#2088609, @sanjoy.google wrote:

In D81156#2084324, @jhenderson wrote:

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

Hopefully resolved by @MaskRay 's 030897523d43e3296f69d25a71a140d9e5793c6a

[MaskRay]

In D81156#2088609, @sanjoy.google wrote:

In D81156#2084324, @jhenderson wrote:

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

Does 030897523d43e3296f69d25a71a140d9e5793c6a fix the race?

(clangd used tie now. .debug_line parsing depends on it. Reverting is more disruptive than simply disabling tie-by-default behavior)

[sanjoy.google]

In D81156#2088659, @MaskRay wrote:

In D81156#2088609, @sanjoy.google wrote:

In D81156#2084324, @jhenderson wrote:

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

Does 030897523d43e3296f69d25a71a140d9e5793c6a fix the race?

That should fix it, thanks!

(clangd used tie now. .debug_line parsing depends on it. Reverting is more disruptive than simply disabling tie-by-default behavior)

[MaskRay]

In D81156#2088666, @sanjoy.google wrote:

In D81156#2088659, @MaskRay wrote:

In D81156#2088609, @sanjoy.google wrote:

In D81156#2084324, @jhenderson wrote:

In D81156#2084273, @sammccall wrote:

In D81156#2084209, @jhenderson wrote:

In D81156#2084176, @sammccall wrote:

This is surprising and unsafe behaviour. Can we reconsider changing the default, at least until a more careful audit of the places errs() is used?
In particular, if errs is used from multiple threads (with a lock) and outs is used from a single thread (so no lock needed) then this introduces racy flushes to outs() concurrent with writes.

Thanks for highlighting this, it's been brought up on D81525 as well, so rather than discuss it in two places, we'll look at it there, if that's okay?

Happy to discuss there. It's a separate issue though, the discussion there is about initialization being racy,

Yeah, I realised that after posting that previous post, sorry! Still, probably best to keep the discussion in one place for now.

Did we resolve this? In an internal XLA build tsan complains about this being racy, and I'm not sure if the problem is with how we are using llvm::dbgs() or with this patch. If the latter, please rollback while we figure out a non-racy way to achieve the same thing.

Does 030897523d43e3296f69d25a71a140d9e5793c6a fix the race?

That should fix it, thanks!

(clangd used tie now. .debug_line parsing depends on it. Reverting is more disruptive than simply disabling tie-by-default behavior)

Note, printing via dbgs() << "a" or errs() << "a" concurrently was racy even (in both NDEBUG and !NDEBUG builds) before this patch.

This patch introduced additional problems that (1) calling errs() concurrently would be racy (due to S.tie(&outs())) (2) printing to errs() in one thread and printing to outs() in another thread would be racy.

Anyway, you may want to investigate whether there are existing problems due to concurrent dbgs() or errs() uses, even if TSAN did not catch it before this patch.

llvm/include/llvm/Support/raw_ostream.h

private:
   /// managed by the subclass.
   ///
   /// If a subclass installs an external buffer using SetBuffer then it can wait
   /// for a \see write_impl() call to handle the data which has been put into
   /// this buffer.
   char *OutBufStart, *OutBufEnd, *OutBufCur;
   bool ColorEnabled = false;
 
+  /// Optional stream this stream is tied to. If this stream is written to, the
+  /// tied-to stream will be flushed first.
+  raw_ostream *TiedStream = nullptr;
+
   enum class BufferKind {
     Unbuffered = 0,
     InternalBuffer,
     ExternalBuffer
   } BufferMode;
 
 public:
   // color order matches ANSI escape sequence, don't change
public:
   /// This function determines if this stream is displayed and supports colors.
   /// The result is unaffected by calls to enable_color().
   virtual bool has_colors() const { return is_displayed(); }
 
   // Enable or disable colors. Once enable_colors(false) is called,
   // changeColor() has no effect until enable_colors(true) is called.
   virtual void enable_colors(bool enable) { ColorEnabled = enable; }
 
+  /// Tie this stream to the specified stream. Replaces any existing tied-to
+  /// stream. Specifying a nullptr unties the stream.
+  void tie(raw_ostream *TieTo) { TiedStream = TieTo; }
+
   //===--------------------------------------------------------------------===//
   // Subclass Interface
   //===--------------------------------------------------------------------===//
 
 private:
   /// The is the piece of the class that is implemented by subclasses.  This
   /// writes the \p Size bytes starting at
   /// \p Ptr to the underlying stream.
   ///
   /// This function is guaranteed to only be called at a point at which it is
   /// safe for the subclass to install a new buffer via SetBuffer.
   ///
   /// \param Ptr The start of the data to be written. For buffered streams this
   /// is guaranteed to be the start of the buffer.
   ///
   /// \param Size The number of bytes to be written.
private:
   /// Copy data into the buffer. Size must not be greater than the number of
   /// unused bytes in the buffer.
   void copy_to_buffer(const char *Ptr, size_t Size);
 
   /// Compute whether colors should be used and do the necessary work such as
   /// flushing. The result is affected by calls to enable_color().
   bool prepare_colors();
 
+  /// Flush the tied-to stream (if present) and then write the required data.
+  void flush_tied_then_write(const char *Ptr, size_t Size);
+
   virtual void anchor();
 };
 
 /// Call the appropriate insertion operator, given an rvalue reference to a
 /// raw_ostream object and return a stream of the same type as the argument.
 template <typename OStream, typename T>
 std::enable_if_t<!std::is_reference<OStream>::value &&
                      std::is_base_of<raw_ostream, OStream>::value,
public:
   ///
   void clear_error() { EC = std::error_code(); }
 };
 
 /// This returns a reference to a raw_fd_ostream for standard output. Use it
 /// like: outs() << "foo" << "bar";
 raw_fd_ostream &outs();
 
-/// This returns a reference to a raw_fd_ostream for standard error. Use it
-/// like: errs() << "foo" << "bar";
+/// This returns a reference to a raw_ostream for standard error.
+/// Use it like: errs() << "foo" << "bar";
+/// By default, the stream is tied to stdout to ensure stdout is flushed before
+/// stderr is written, to ensure the error messages are written in their
+/// expected place.
 raw_fd_ostream &errs();
 
 /// This returns a reference to a raw_ostream which simply discards output.
 raw_ostream &nulls();
 
 //===----------------------------------------------------------------------===//
 // Output Stream Adaptors
 //===----------------------------------------------------------------------===//

llvm/lib/Support/raw_ostream.cpp

raw_ostream &raw_ostream::operator<<(double N) {
   llvm::write_double(*this, N, FloatStyle::Exponent);
   return *this;
 }
 
 void raw_ostream::flush_nonempty() {
   assert(OutBufCur > OutBufStart && "Invalid call to flush_nonempty.");
   size_t Length = OutBufCur - OutBufStart;
   OutBufCur = OutBufStart;
-  write_impl(OutBufStart, Length);
+  flush_tied_then_write(OutBufStart, Length);
 }
 
 raw_ostream &raw_ostream::write(unsigned char C) {
   // Group exceptional cases into a single branch.
   if (LLVM_UNLIKELY(OutBufCur >= OutBufEnd)) {
     if (LLVM_UNLIKELY(!OutBufStart)) {
       if (BufferMode == BufferKind::Unbuffered) {
-        write_impl(reinterpret_cast<char*>(&C), 1);
+        flush_tied_then_write(reinterpret_cast<char *>(&C), 1);
         return *this;
       }
       // Set up a buffer and start over.
       SetBuffered();
       return write(C);
     }
 
     flush_nonempty();
   }
 
   *OutBufCur++ = C;
   return *this;
 }
 
 raw_ostream &raw_ostream::write(const char *Ptr, size_t Size) {
   // Group exceptional cases into a single branch.
   if (LLVM_UNLIKELY(size_t(OutBufEnd - OutBufCur) < Size)) {
     if (LLVM_UNLIKELY(!OutBufStart)) {
       if (BufferMode == BufferKind::Unbuffered) {
-        write_impl(Ptr, Size);
+        flush_tied_then_write(Ptr, Size);
         return *this;
       }
       // Set up a buffer and start over.
       SetBuffered();
       return write(Ptr, Size);
     }
 
     size_t NumBytes = OutBufEnd - OutBufCur;
 
     // If the buffer is empty at this point we have a string that is larger
     // than the buffer. Directly write the chunk that is a multiple of the
     // preferred buffer size and put the remainder in the buffer.
     if (LLVM_UNLIKELY(OutBufCur == OutBufStart)) {
       assert(NumBytes != 0 && "undefined behavior");
       size_t BytesToWrite = Size - (Size % NumBytes);
-      write_impl(Ptr, BytesToWrite);
+      flush_tied_then_write(Ptr, BytesToWrite);
       size_t BytesRemaining = Size - BytesToWrite;
       if (BytesRemaining > size_t(OutBufEnd - OutBufCur)) {
         // Too much left over to copy into our buffer.
         return write(Ptr + BytesToWrite, BytesRemaining);
       }
       copy_to_buffer(Ptr + BytesToWrite, BytesRemaining);
       return *this;
     }
void raw_ostream::copy_to_buffer(const char *Ptr, size_t Size) {
   default:
     memcpy(OutBufCur, Ptr, Size);
     break;
   }
 
   OutBufCur += Size;
 }
 
+void raw_ostream::flush_tied_then_write(const char *Ptr, size_t Size) {
+  if (TiedStream)
+    TiedStream->flush();
+  write_impl(Ptr, Size);
+}
+
 // Formatted output.
 raw_ostream &raw_ostream::operator<<(const format_object_base &Fmt) {
   // If we have more than a few bytes left in our output buffer, try
   // formatting directly onto its end.
   size_t NextBufferSize = 127;
   size_t BufferBytesLeft = OutBufEnd - OutBufCur;
   if (BufferBytesLeft > 3) {
     size_t BytesUsed = Fmt.print(OutBufCur, BufferBytesLeft);
raw_fd_ostream &llvm::outs() {
   // Set buffer settings to model stdout behavior.
   std::error_code EC;
   static raw_fd_ostream S("-", EC, sys::fs::OF_None);
   assert(!EC);
   return S;
 }
 
 raw_fd_ostream &llvm::errs() {
-  // Set standard error to be unbuffered by default.
+  // Set standard error to be unbuffered and tied to outs() by default.
   static raw_fd_ostream S(STDERR_FILENO, false, true);
+  S.tie(&outs());
   return S;
 }
 
 /// nulls() - This returns a reference to a raw_ostream which discards output.
 raw_ostream &llvm::nulls() {
   static raw_null_ostream S;
   return S;
 }

llvm/unittests/Support/raw_ostream_test.cpp

 #endif
 
 TEST(raw_fd_ostreamTest, multiple_raw_fd_ostream_to_stdout) {
   std::error_code EC;
 
   { raw_fd_ostream("-", EC, sys::fs::OpenFlags::OF_None); }
   { raw_fd_ostream("-", EC, sys::fs::OpenFlags::OF_None); }
 }
+
+TEST(raw_ostreamTest, flush_tied_to_stream_on_write) {
+  std::string TiedToBuffer;
+  raw_string_ostream TiedTo(TiedToBuffer);
+  TiedTo.SetBuffered();
+  TiedTo << "a";
+
+  std::string Buffer;
+  raw_string_ostream TiedStream(Buffer);
+  TiedStream.tie(&TiedTo);
+  // Sanity check that the stream hasn't already been flushed.
+  EXPECT_EQ("", TiedToBuffer);
+
+  // Empty string doesn't cause a flush of TiedTo.
+  TiedStream << "";
+  EXPECT_EQ("", TiedToBuffer);
+
+  // Non-empty strings trigger flush of TiedTo.
+  TiedStream << "abc";
+  EXPECT_EQ("a", TiedToBuffer);
+
+  // Single char write flushes TiedTo.
+  TiedTo << "c";
+  TiedStream << 'd';
+  EXPECT_EQ("ac", TiedToBuffer);
+
+  // Write to buffered stream without flush does not flush TiedTo.
+  TiedStream.SetBuffered();
+  TiedStream.SetBufferSize(2);
+  TiedTo << "e";
+  TiedStream << "f";
+  EXPECT_EQ("ac", TiedToBuffer);
+
+  // Explicit flush of buffered stream flushes TiedTo.
+  TiedStream.flush();
+  EXPECT_EQ("ace", TiedToBuffer);
+
+  // Explicit flush of buffered stream with empty buffer does not flush TiedTo.
+  TiedTo << "g";
+  TiedStream.flush();
+  EXPECT_EQ("ace", TiedToBuffer);
+
+  // Write of data to empty buffer that is greater than buffer size flushes
+  // TiedTo.
+  TiedStream << "hijklm";
+  EXPECT_EQ("aceg", TiedToBuffer);
+
+  // Write of data that overflows buffer size also flushes TiedTo.
+  TiedStream.flush();
+  TiedStream << "n";
+  TiedTo << "o";
+  TiedStream << "pq";
+  EXPECT_EQ("acego", TiedToBuffer);
+
+  // Streams can be tied to each other safely.
+  TiedStream.flush();
+  Buffer = "";
+  TiedTo.tie(&TiedStream);
+  TiedTo.SetBufferSize(2);
+  TiedStream << "r";
+  TiedTo << "s";
+  EXPECT_EQ("", Buffer);
+  EXPECT_EQ("acego", TiedToBuffer);
+  TiedTo << "tuv";
+  EXPECT_EQ("r", Buffer);
+  TiedStream << "wxy";
+  EXPECT_EQ("acegostuv", TiedToBuffer);
+  // The x remains in the buffer, since it was written after the flush of
+  // TiedTo.
+  EXPECT_EQ("rwx", Buffer);
+
+  // Calling tie with nullptr unties stream.
+  TiedStream.SetUnbuffered();
+  TiedStream.tie(nullptr);
+  TiedTo << "y";
+  TiedStream << "0";
+  EXPECT_EQ("acegostuv", TiedToBuffer);
+}
 }