<div dir="ltr">I have done some more checks and am convinced that this patch is breaking the buildbot. Reverted in r306676.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 3:19 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah, and in case that helps, the internal test we also fails for the combination of ASAN and PPC only.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 3:18 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So you mean this failure one PPC:<div><a href="http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3112/steps/64-bit%20check-asan/logs/stdio" target="_blank">http://lab.llvm.org:8011/build<wbr>ers/sanitizer-ppc64be-linux/<wbr>builds/3112/steps/64-bit%<wbr>20check-asan/logs/stdio</a><br></div><div><br></div><div>FWIW, I think this is the same failure that we see on an internal test we have. Would you be open to revert the patch until we can investigate the exact cause?</div><div><br></div></div><div class="m_3340962185858067387HOEnZb"><div class="m_3340962185858067387h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 12:55 PM, Peter Smith via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've taken a look to see what affect this would have on CFI<br>
instructions for AArch64.<br>
<br>
My understanding concurs with Petar's explanation; that no extra CFI<br>
instructions will be added if the default values in MachineBasicBlock<br>
are used. I have a small concern that this assumption isn't really<br>
obvious from the comments in initializeCFIInfo which leaves open the<br>
possibility that someone else might inadvertently break this in the<br>
future, although I guess the tests should pick this up fairly quickly<br>
if it does.<br>
<br>
Peter<br>
<br>
On 29 June 2017 at 11:26, Petar Jovanovic via llvm-commits<br>
<div class="m_3340962185858067387m_-8566860053132086727HOEnZb"><div class="m_3340962185858067387m_-8566860053132086727h5"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> + Violeta<br>
><br>
>> So, this says "[X86]", but is it really X86-specific? there is a pretty<br>
>> huge set of changes to common CFI infrastructure that is used by PPC and<br>
>> AArch64 at least.<br>
><br>
> It is x86-specific in the way that improvements made in this patch should<br>
> affect/improve x86 target only. Other arches can benefit if they make<br>
> similar changes.<br>
><br>
>> It seems like these late passes (that run on all targets from what I can<br>
>> tell) *require* the new information to be set up in the basic block...<br>
><br>
> Yes, but if the new information is not set (i.e. has default values), the<br>
> passes would not make any changes. An alternative is to run these passes for<br>
> selected target(s) only.<br>
><br>
>> How does this work? Is this not a (serious) bug?<br>
><br>
> Violeta has more description in <a href="https://reviews.llvm.org/D18046" rel="noreferrer" target="_blank">https://reviews.llvm.org/D1804<wbr>6</a><br>
> It should not be a bug, more like a place where things can be improved for<br>
> other architectures too.<br>
><br>
> So the passes should not be the problem. The only thing I am concerned is<br>
> that other common code changes may have side effects elsewhere. There is<br>
> a failure on PPC64 sanitizer buildbot and this change is on the blame list,<br>
> so that is being investigated along with the case Eli has reported.<br>
> ______________________________<wbr>_________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>