[LLVMdev] AArch64 bot unstable

Teresa Johnson
Wed, 29 Apr 2015 18:31:39 -0000

On Wed, Apr 29, 2015 at 11:19 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Wed, Apr 29, 2015 at 10:55 AM, Teresa Johnson <tejohnson at
google.com>
> wrote:
>>
>> On Wed, Apr 29, 2015 at 10:05 AM, David Blaikie <dblaikie at
gmail.com>
>> wrote:
>> >
>> >
>> > On Wed, Apr 29, 2015 at 9:48 AM, Teresa Johnson <tejohnson at
google.com>
>> > wrote:
>> >>
>> >> Ok, thanks for the suggestion. I will rework the tests to do
that.
>> >
>> >
>> > In case you haven't found it already, %T in the lit syntax
gives you a
>> > uniquely named directory for the test
>>
>> Actually %T is just the base directory where all the
>> compiler-rt/profile tests are run, not unique per .c test.
>
>
> Ah, sorry for the misleading advice - thanks for the correction.
>
>>
>> I fixed the
>> tests by creating a "%t.d" directory and cd'ing into it
and generating
>> all output locally in that directory.
>
>
> A quick "grep -r "RUN.*mkdir" certainly shows a few tests
doing quite
> similar things (most use -p, which I see you've done too).
>
> You'll probably also need REQUIRES: shell in this test to ensure it
doesn't
> run in environments that don't have a full bash-like shell available
(such
> as Windows). Check the other tests that use mkdir to see that sort of
thing.

Some have the "REQUIRES: shell" (e.g.
tools/clang/test/VFS/include-virtual-from-real.c) and some don't (e.g.
./tools/clang/test/Analysis/html-diags.c). I looked around for
documentation on when "REQUIRES: shell" is needed but couldn't
find
anything specific. The latter test (html-diags.c), which doesn't have
the REQUIRES also does mkdir -p, cd, rm -rf", which are the same
shell-like operations my tests are doing. The former
(include-virtual-from-real.c) is doing some additional shell-like
operations such as sed and echo, which I am not doing. Is there a list
of operations safe to do without adding the "REQUIRES: shell"?

Thanks,
Teresa

>
>>
>>
>> Patch uploaded here, PTAL:
>> http://reviews.llvm.org/D9349
>>
>> Thanks,
>> Teresa
>>
>> >
>> >>
>> >> Teresa
>> >>
>> >> On Wed, Apr 29, 2015 at 9:47 AM, Eric Christopher <echristo
at gmail.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Apr 29, 2015 at 9:36 AM Justin Bogner <mail at
justinbogner.com>
>> >> > wrote:
>> >> >>
>> >> >> Teresa Johnson <tejohnson at google.com>
writes:
>> >> >> > On Wed, Apr 29, 2015 at 6:27 AM, Renato Golin
>> >> >> > <renato.golin at linaro.org>
>> >> >> > wrote:
>> >> >> >> On 29 April 2015 at 14:16, Teresa Johnson
<tejohnson at google.com>
>> >> >> >> wrote:
>> >> >> >>> Two of the compiler-rt/profile tests I
added are checking for
>> >> >> >>> similar
>> >> >> >>> behavior with resetting the filename to
the default. I wonder if
>> >> >> >>> they
>> >> >> >>> are running in parallel and clobbering
each other since the
>> >> >> >>> profile
>> >> >> >>> output names are not unique after the
reset.
>> >> >> >>
>> >> >> >> Hi Teresa,
>> >> >> >>
>> >> >> >> This would explain the intermittent
failures. Maybe making the
>> >> >> >> names
>> >> >> >> unique would fix the issues, would that be
an easy change?
>> >> >> >
>> >> >> > After thinking about it I believe this is what
is most likely
>> >> >> > happening, and that these two new tests I added
will need to be
>> >> >> > reverted:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
compiler-rt/trunk/test/profile/instrprof-override-filename-then-reset-default.c
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
compiler-rt/trunk/test/profile/instrprof-set-filename-then-reset-default.c
>> >> >> >
>> >> >> > since they aren't writing to unique output
names. These are 2 of
>> >> >> > the
>> >> >> > 4
>> >> >> > tests added in r236056 (the other two are fine).
>> >> >> >
>> >> >> > They can't be changed to write to a unique
name since those tests
>> >> >> > were
>> >> >> > specifically testing that the profile output
name gets reset to
>> >> >> > the
>> >> >> > default when null is passed to the profile
filename setting
>> >> >> > interfaces. The other profile tests use unique
names.
>> >> >>
>> >> >> Could we have these tests `cd` into a uniquely named
directory or
>> >> >> something? Maybe that's more complicated than its
worth.
>> >> >>
>> >> >
>> >> > That's what we've done in the past and seems a
reasonable idea.
>> >> >
>> >> > -eric
>> >> >
>> >> >>
>> >> >> > Since I don't have write access yet, can
someone revert those two
>> >> >> > files for me?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Teresa
>> >> >> >>
>> >> >> >> cheers,
>> >> >> >> --renato
>> >> >> _______________________________________________
>> >> >> LLVM Developers mailing list
>> >> >> LLVMdev at cs.uiuc.edu
http://llvm.cs.uiuc.edu
>> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>
>> >>
>> >>
>> >> --
>> >> Teresa Johnson | Software Engineer | tejohnson at google.com |
>> >> 408-460-2413
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>> >
>>
>>
>>
>> --
>> Teresa Johnson | Software Engineer | tejohnson at google.com |
408-460-2413
>
>



--
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413