> On Apr 18, 2018, at 9:11 AM, Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> Recently I committed a change (r330175) that passed all my testing, but >> failed on several bots. Namely, these are the failed ones: >> http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803 >> http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/8173 >> http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/18082 > Note what *specifically* failed: > * compare-compilers compare stage3 and stage4 compilers failed ( 0 secs ) > * compare-tablegen-inc-files compare stage3 and stage4 Tablegen inc > files failed ( 1 secs ) > > I.e. it wasn't tests that failed.Failing that tests means the compiler doesn't produce deterministic output because the stage3 and stage 4 compiler has to be the same. Not sure about LLD test. Steven> >> I reverted the change (r330180), but now I’m stuck with how to proceed with >> it, as I can’t reproduce any of these. >> >> So far I’ve tried building clang with asan and using this sanitized clang to >> build clang and lld one more time and run make check - none of these failed >> on my machine. What else could I try to catch the issue? >> >> In case you are interested in details and/or want to try to reproduce it, >> you’ll need to revert r330180 (and thus reapply r330175). The change is >> about using a new faster SSAUpdater in Jump Threading, more details are >> available in the phabricator: https://reviews.llvm.org/D44282. >> >> Thanks, >> Michael >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Michael Zolotukhin via llvm-dev
2018-Apr-19 06:14 UTC
[llvm-dev] Need help reproducing a bug
Thanks everyone! What are the best tools/techniques to expose such non-deterministic behavior? My hope is to reproduce it on a smaller test (e.g. use some sanitizer and thus make the compiler *fail* when building the test) - Currently these failures only tell me “there is some bug in your code” without any hints where to look for it. Michael> On Apr 18, 2018, at 9:18 PM, Steven Wu <stevenwu at apple.com> wrote: > > > >> On Apr 18, 2018, at 9:11 AM, Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Hi, >>> >>> Recently I committed a change (r330175) that passed all my testing, but >>> failed on several bots. Namely, these are the failed ones: >>> http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803 >>> http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/8173 >>> http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/18082 >> Note what *specifically* failed: >> * compare-compilers compare stage3 and stage4 compilers failed ( 0 secs ) >> * compare-tablegen-inc-files compare stage3 and stage4 Tablegen inc >> files failed ( 1 secs ) >> >> I.e. it wasn't tests that failed. > > Failing that tests means the compiler doesn't produce deterministic output because the stage3 and stage 4 compiler has to be the same. > > Not sure about LLD test. > > Steven > >> >>> I reverted the change (r330180), but now I’m stuck with how to proceed with >>> it, as I can’t reproduce any of these. >>> >>> So far I’ve tried building clang with asan and using this sanitized clang to >>> build clang and lld one more time and run make check - none of these failed >>> on my machine. What else could I try to catch the issue? >>> >>> In case you are interested in details and/or want to try to reproduce it, >>> you’ll need to revert r330180 (and thus reapply r330175). The change is >>> about using a new faster SSAUpdater in Jump Threading, more details are >>> available in the phabricator: https://reviews.llvm.org/D44282. >>> >>> Thanks, >>> Michael >>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180419/e62b0fe5/attachment.html>
On Thu, Apr 19, 2018 at 9:14 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote:> Thanks everyone! What are the best tools/techniques to expose such > non-deterministic behavior? My hope is to reproduce it on a smaller test > (e.g. use some sanitizer and thus make the compiler *fail* when building the > test) - Currently these failures only tell me “there is some bug in your > code” without any hints where to look for it.Hmm, have you tried -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON -DLLVM_REVERSE_ITERATION=ON (especially the last one)?> Michael > > On Apr 18, 2018, at 9:18 PM, Steven Wu <stevenwu at apple.com> wrote: > > > > On Apr 18, 2018, at 9:11 AM, Roman Lebedev via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Recently I committed a change (r330175) that passed all my testing, but > failed on several bots. Namely, these are the failed ones: > http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803 > http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/8173 > http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/18082 > > Note what *specifically* failed: > * compare-compilers compare stage3 and stage4 compilers failed ( 0 secs ) > * compare-tablegen-inc-files compare stage3 and stage4 Tablegen inc > files failed ( 1 secs ) > > I.e. it wasn't tests that failed. > > > Failing that tests means the compiler doesn't produce deterministic output > because the stage3 and stage 4 compiler has to be the same. > > Not sure about LLD test. > > Steven > > > I reverted the change (r330180), but now I’m stuck with how to proceed with > it, as I can’t reproduce any of these. > > So far I’ve tried building clang with asan and using this sanitized clang to > build clang and lld one more time and run make check - none of these failed > on my machine. What else could I try to catch the issue? > > In case you are interested in details and/or want to try to reproduce it, > you’ll need to revert r330180 (and thus reapply r330175). The change is > about using a new faster SSAUpdater in Jump Threading, more details are > available in the phabricator: https://reviews.llvm.org/D44282. > > Thanks, > Michael > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >
Martin J. O'Riordan via llvm-dev
2018-Apr-19 10:22 UTC
[llvm-dev] Need help reproducing a bug
Hi Michael,
Last year I had a problem with reproducibility that I detected in the generated
assembly for the out-of-tree target I was working on that seemed like
non-deterministic code generation. There was nothing incorrect in the
alternative code being emitted, but it was making me nervous that it was
different at all.
After some investigation it turned out to be a consequence of iterator ordering.
The scheduler was working out the prioritisation of basic blocks and there was
no issue if one BB had a different priority to another. However, if two BBs had
the same priority, the implicit ordering was based on the hash in the map that
was being iterated, and this could vary between platform (Windows vs Linux) and
between recompiles on the same platform.
Just a thought, but perhaps you might have a look at how ordering is handled in
your BB or MI iterators.
MartinO
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Michael
Zolotukhin via llvm-dev
Sent: 19 April 2018 07:15
To: Steven Wu <stevenwu at apple.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Need help reproducing a bug
Thanks everyone! What are the best tools/techniques to expose such
non-deterministic behavior? My hope is to reproduce it on a smaller test (e.g.
use some sanitizer and thus make the compiler *fail* when building the test) -
Currently these failures only tell me “there is some bug in your code” without
any hints where to look for it.
Michael
On Apr 18, 2018, at 9:18 PM, Steven Wu <stevenwu at apple.com
<mailto:stevenwu at apple.com> > wrote:
On Apr 18, 2018, at 9:11 AM, Roman Lebedev via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:
On Wed, Apr 18, 2018 at 5:45 PM, Michael Zolotukhin via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >
wrote:
Hi,
Recently I committed a change (r330175) that passed all my testing, but
failed on several bots. Namely, these are the failed ones:
http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/9803
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/8173
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/18082
Note what *specifically* failed:
* compare-compilers compare stage3 and stage4 compilers failed ( 0 secs )
* compare-tablegen-inc-files compare stage3 and stage4 Tablegen inc
files failed ( 1 secs )
I.e. it wasn't tests that failed.
Failing that tests means the compiler doesn't produce deterministic output
because the stage3 and stage 4 compiler has to be the same.
Not sure about LLD test.
Steven
I reverted the change (r330180), but now I’m stuck with how to proceed with
it, as I can’t reproduce any of these.
So far I’ve tried building clang with asan and using this sanitized clang to
build clang and lld one more time and run make check - none of these failed
on my machine. What else could I try to catch the issue?
In case you are interested in details and/or want to try to reproduce it,
you’ll need to revert r330180 (and thus reapply r330175). The change is
about using a new faster SSAUpdater in Jump Threading, more details are
available in the phabricator: https://reviews.llvm.org/D44282.
Thanks,
Michael
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180419/76b057f8/attachment-0001.html>