[LLVMbugs] LICM Test Failure?

[Reid Spencer]

On Mon, 2007-05-21 at 15:08 +0200, Duncan Sands wrote:
> Hi Bill,
> 
> > Anyone seeing this failure in a fresh tree?
> 
> > Running /Users/wendling/llvm/test/Transforms/LICM/dg.exp ...
> > FAIL: /Users/wendling/llvm/test/Transforms/LICM/scalar_promote.ll
> > Failed with signal(SIGPIPE) at line 1
> > while running: llvm-upgrade < /Users/wendling/llvm/test/Transforms/ 
> > LICM/scalar_promote.ll | llvm-as | opt  -licm -stats |&  grep {memory  
> > locations promoted to register}
> > Binary file (standard input) matches
> > child killed: write on pipe with no readers
> 
> I've been seen failures like this from time to time (not sure if it
> was for this test).  I couldn't work out what was going on.  It smells
> to me like one of the commands in the pipeline has exited before the
> preceding command finished writing into the pipe, meaning it gets hit
> with SIGPIPE.  

That's exactly what's going on. The new Tcl-based interpreter of the
RUN: lines does not tolerate any bad exit codes or signals from any of
the commands in the pipeline. 

> The fact that this doesn't always happens makes me
> suspect a race condition, for example when you do a fork does the
> parent or child run first? 

Tcl should be handling this correctly.

>  Answer: either, depending on the whim of
> the OS.  On linux, I think it almost always used to be the child that
> ran first, but in fact this was never reliable; that didn't stop some
> programs (eg bash) relying on it anyway - though I understand this was
> fixed in bash some time ago.  

Bash isn't involved here. 

> I wouldn't be surprised if something like
> this was causing the problem you see.

The only thing I can think of is that the new BitcodeReader is somehow
sensitive to "no input" and exits early causing the following command in
the pipeline to SIGPIPE. I don't know how that could happen without a
(very short) I/O timeout, however.

> 
> Ciao,
> 
> Duncan.
> _______________________________________________
> LLVMbugs mailing list
> LLVMbugs at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs