[llvm-commits] [llvm] r173509 - /llvm/trunk/test/Other/close-stderr.ll

[Reid Kleckner]

I don't follow.  I don't think this problem is coming from Cygwin's
bash.exe.

The reason I don't want to use Cygwin's bash is because I'm running lit.py
with native win32 python.  It produces script files with CRLF line endings,
which Cygwin bash chokes on.  I'd rather just avoid that along with all the
extra fork emulation overhead of bash and use lit's shell script executor.

Coming back to this particular test, won't native Windows opt fail to open
/dev/null because that file doesn't exist, regardless of whether bash is
used?


On Sat, Jan 26, 2013 at 10:18 AM, NAKAMURA Takumi <geek4civic at gmail.com>wrote:

> Reid,
>
> I didn't expect that Lit would find insane bash.exe in $PATH. In this
> context, Cygwin's bash.exe is insane, (unless it were not executed on
> Cygwin's python.)
>
> ; RUN: sh -c 'opt --reject-this-option 2>&-; echo $?; opt -o /dev/null
> /dev/null 2>&-; echo $?;'
>
> On msys bash, entire the line 'quoted' should run on bash.exe. In this
> case, msys' bash.exe behaves expectedly.
> As you know, without bash.exe, whole the test would not be executed
> lacks of the feature "shell".
>
> For now, "XFAIL:win32" would not affect most environments, AFAIK. That
> said, I think it would be incomplete.
> Consider you are running not msvc binaries but mingw binaries.
> ("win32" does not cover mingw32 here)
>
> Should we detect insane bash.exe anyways?
>
> ...Takumi
>
> 2013/1/26 Reid Kleckner <rnk at google.com>:
> > I happen to have Cygwin bash on my PATH, so shell is true, but I've found
> > that manually setting 'execute_external = False' in lit.cfg lets me run
> far
> > more of the test suite.  Perhaps I should remove the shell feature in
> that
> > case.
> >
> > However, I don't think this test can work at all on Windows, unless
> > TestRunner.py tries harder to replace /dev/null.  The command line is
> 'opt
> > -o /dev/null /dev/null 2>&-', and opt knows nothing about /dev/null,
> right?
> > For me that file does not exist and I get a non-zero return code for the
> > second opt invocation.
> >
> >
> > On Fri, Jan 25, 2013 at 6:47 PM, NAKAMURA Takumi <geek4civic at gmail.com>
> > wrote:
> >>
> >> Reid, I suppose it has been disabled with "REQUIRES:shell" on win32
> >> (includes msvc).
> >> What is your motivation on this commit?
> >>
> >> FYI, it has been working with mingw32 msys bash.
> >>
> >> ...Takumi
> >>
> >> 2013/1/26 Reid Kleckner <reid at kleckner.net>:
> >> > Author: rnk
> >> > Date: Fri Jan 25 16:12:54 2013
> >> > New Revision: 173509
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=173509&view=rev
> >> > Log:
> >> > XFAIL close-stderr on win32
> >> >
> >> > The test runner does not rewrite instances of /dev/null inside the
> >> > quoted sh command.  /dev/null does not exist, so opt will fail to open
> >> > it, and return a non-zero exit code.
> >> >
> >> > Modified:
> >> >     llvm/trunk/test/Other/close-stderr.ll
> >> >
> >> > Modified: llvm/trunk/test/Other/close-stderr.ll
> >> > URL:
> >> >
> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Other/close-stderr.ll?rev=173509&r1=173508&r2=173509&view=diff
> >> >
> >> >
> ==============================================================================
> >> > --- llvm/trunk/test/Other/close-stderr.ll (original)
> >> > +++ llvm/trunk/test/Other/close-stderr.ll Fri Jan 25 16:12:54 2013
> >> > @@ -9,5 +9,8 @@
> >> >  ; XFAIL: vg_leak
> >> >  ; REQUIRES: shell
> >> >
> >> > +; opt will fail to open /dev/null on native win32.
> >> > +; XFAIL: win32
> >> > +
> >> >  ; Test that the error handling when writing to stderr fails exits the
> >> >  ; program cleanly rather than aborting.
> >> >
> >> >
> >> > _______________________________________________
> >> > llvm-commits mailing list
> >> > llvm-commits at cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130126/fa03e342/attachment.html>