<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 23, 2017 at 10:48 AM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@<wbr>lists.llvm.org</a>] On Behalf Of<br>
> Michael Kruse via llvm-dev<br>
> Sent: Thursday, February 23, 2017 6:53 AM<br>
> To: llvm-dev<br>
> Subject: [llvm-dev] llvm-lit: 2>&1 and FileCheck<br>
><br>
> Hi all,<br>
><br>
> quite a few tests use the pattern "2>&1 | FileCheck %s". AFAIK how<br>
> stdout and stderr are merged into a single character stream is<br>
> undefined and depends e.g. on whether stdout is buffered. I think we<br>
> are often saved by the fact that standard output is written only at<br>
> the end of the program and stderr is unbuffered, i.e. always written<br>
> before stdout.<br>
><br>
> A lot of tests disable stdout using either "-o /dev/null" or<br>
> "-disable-output", but not all. For instance,<br>
> test/Transforms/SLPVectorizer/<wbr>X86/reduction_unrolled.ll does not. It<br>
> checks for output from stdout and stderr using the same FileCheck. The<br>
> stderr it is checking even comes from -debug, which has an additional<br>
> buffering layer (circular_raw_ostream).<br>
><br>
> The testing guide [1] does not mention how to test stderr.<br>
><br>
><br>
> My questions:<br>
><br>
> 1. Are these tests, e.g. reduction_unrolled.ll fragile? Maybe I am<br>
> missing something that says that interleaving stdout and stderr (and<br>
> llvm::dbgs()) is well-defined in llvm-lit.<br>
<br>
</span>I'd consider them fragile, but obviously their behavior has been<br>
consistent across a variety of bots for some time.  So the fragility<br>
is a bit pedantic/theoretical.  "The behavior is undefined but I know<br>
what I'm doing!"<br>
<br>
There are times running a test when I've seen interleaved stdout/stderr<br>
text, but not the text that a CHECK was looking for; so I think people<br>
are getting lucky in at least some cases.<br>
<span class=""><br>
><br>
> 2. Can -debug (or -debug-only) be used in regression tests at all? I<br>
> understood them as debugging aids only. I would not like if<br>
> adding/changing DEBUG(dbgs() << ...); lines causing regression tests<br>
> to fail.<br>
<br>
</span>The line between "debugging aid" and "event logging" is not clear, but<br>
I have written tests relying on logging-style output; I think that's ok.<br>
As always you want your CHECKs to be specific enough to avoid false<br>
matches but not so specific that they become too fragile.<br></blockquote><div><br></div><div>Right.</div><div>Where we can, we prefer to have separate printing passes, but that only really works well for analysis and preparation transformations.</div><div><br></div></div></div></div>