[llvm] r198926 - llvm/test/ExecutionEngine/MCJIT/load-object-a.ll: Fix not to use %t.cachedir/%p.

[dblaikie at gmail.com]

Takumi - can you confirm/deny/describe why the rm was necessary? Do you
know off-hand if %t<foo> was replaced by %T/foo if this would be a
non-issue?

(Lang any quick examples of %t<foo> without deletions you were using as
reference? (in case we need to fix a bunch?))
On Fri Jan 10 2014 at 12:48:43 PM, Lang Hames <lhames at gmail.com> wrote:

> I had assumed that %t<foo> is also nuked, since that pattern is used
> in several places. In that case the 'rm' line would be redundant. I
> haven't confirmed that though.
>
> - Lang.
>
> On Fri, Jan 10, 2014 at 10:27 AM, dblaikie at gmail.com <dblaikie at gmail.com>
> wrote:
> >
> >
> > On Fri Jan 10 2014 at 2:44:36 AM, NAKAMURA Takumi <geek4civic at gmail.com>
> > wrote:
> >>
> >> Author: chapuni
> >> Date: Fri Jan 10 04:38:23 2014
> >> New Revision: 198926
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=198926&view=rev
> >> Log:
> >> llvm/test/ExecutionEngine/MCJIT/load-object-a.ll: Fix not to use
> >> %t.cachedir/%p.
> >>
> >> %p is like X:\foo\bar.
> >>
> >> Modified:
> >>     llvm/trunk/test/ExecutionEngine/MCJIT/load-object-a.ll
> >>
> >> Modified: llvm/trunk/test/ExecutionEngine/MCJIT/load-object-a.ll
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/
> ExecutionEngine/MCJIT/load-object-a.ll?rev=198926&r1=
> 198925&r2=198926&view=diff
> >>
> >> ============================================================
> ==================
> >> --- llvm/trunk/test/ExecutionEngine/MCJIT/load-object-a.ll (original)
> >> +++ llvm/trunk/test/ExecutionEngine/MCJIT/load-object-a.ll Fri Jan 10
> >> 04:38:23 2014
> >> @@ -1,18 +1,27 @@
> >>  ; REQUIRES: shell
> >>
> >>  ; This first line will generate the .o files for the next run line
> >> +; RUN: rm -rf %t.cachedir
> >
> >
> > Lang/Takumi:
> >
> > Do we need to do this? Most other test cases seem to just use %T to get a
> > temporary directory which I assume is nuked by the test framework
> > appropriately without the test having to handle it explicitly. (& I
> assume
> > %t, a single temporary file, is nuked by the test framework too)
> >
> > So perhaps it should just be %T rather than %t.cachedir? Or maybe
> > %T/cachedir?
> >
> >>
> >>  ; RUN: mkdir -p %t.cachedir
> >>  ; RUN: %lli_mcjit -extra-module=%p/Inputs/multi-module-b.ll
> >> -extra-module=%p/Inputs/multi-module-c.ll -enable-cache-manager
> >> -object-cache-dir=%t.cachedir %s
> >>
> >> +; Collect generated objects.
> >> +; RUN: rm -rf %t.cachedir2
> >> +; RUN: mkdir -p %t.cachedir2
> >> +; RUN: find %t.cachedir -type f -name 'multi-module-?.o' -exec mv -v
> '{}'
> >> %t.cachedir2 ';'
> >> +
> >>  ; This line tests MCJIT object loading
> >> -; RUN: %lli_mcjit -extra-object=%t.cachedir/%p/Inputs/multi-module-b.o
> >> -extra-object=%t.cachedir/%p/Inputs/multi-module-c.o %s
> >> +; RUN: %lli_mcjit -extra-object=%t.cachedir2/multi-module-b.o
> >> -extra-object=%t.cachedir2/multi-module-c.o %s
> >> +
> >> +; RUN: rm -rf %t.cachedir3
> >> +; RUN: mkdir -p %t.cachedir3
> >>
> >>  ; These lines put the object files into an archive
> >> -; RUN: llvm-ar r %t.cachedir/%p/Inputs/load-object.a
> >> %t.cachedir/%p/Inputs/multi-module-b.o
> >> -; RUN: llvm-ar r %t.cachedir/%p/Inputs/load-object.a
> >> %t.cachedir/%p/Inputs/multi-module-c.o
> >> +; RUN: llvm-ar r %t.cachedir3/load-object.a
> %t.cachedir2/multi-module-b.o
> >> +; RUN: llvm-ar r %t.cachedir3/load-object.a
> %t.cachedir2/multi-module-c.o
> >>
> >>  ; This line test MCJIT archive loading
> >> -; RUN: %lli_mcjit -extra-archive=%t.cachedir/%p/Inputs/load-object.a
> %s
> >> +; RUN: %lli_mcjit -extra-archive=%t.cachedir3/load-object.a %s
> >>
> >>  declare i32 @FB()
> >>
> >>
> >>
> >> _______________________________________________
> >> 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/20140111/9d0e0d85/attachment.html>