[llvm] r306529 - [X86] Correct dwarf unwind information in function epilogue

[Daniel Jasper via llvm-commits]

The buildbot is not quite done with the revision, but the checks that
failed before are now green again:
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/3125

On Thu, Jun 29, 2017 at 3:58 PM, Daniel Jasper <djasper at google.com> wrote:

> I have done some more checks and am convinced that this patch is breaking
> the buildbot. Reverted in r306676.
>
> On Thu, Jun 29, 2017 at 3:19 PM, Daniel Jasper <djasper at google.com> wrote:
>
>> Ah, and in case that helps, the internal test we also fails for the
>> combination of ASAN and PPC only.
>>
>> On Thu, Jun 29, 2017 at 3:18 PM, Daniel Jasper <djasper at google.com>
>> wrote:
>>
>>> So you mean this failure one PPC:
>>> http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/bu
>>> ilds/3112/steps/64-bit%20check-asan/logs/stdio
>>>
>>> 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?
>>>
>>>
>>> On Thu, Jun 29, 2017 at 12:55 PM, Peter Smith via llvm-commits <
>>> llvm-commits at lists.llvm.org> wrote:
>>>
>>>> I've taken a look to see what affect this would have on CFI
>>>> instructions for AArch64.
>>>>
>>>> My understanding concurs with Petar's explanation; that no extra CFI
>>>> instructions will be added if the default values in MachineBasicBlock
>>>> are used. I have a small concern that this assumption isn't really
>>>> obvious from the comments in initializeCFIInfo which leaves open the
>>>> possibility that someone else might inadvertently break this in the
>>>> future, although I guess the tests should pick this up fairly quickly
>>>> if it does.
>>>>
>>>> Peter
>>>>
>>>> On 29 June 2017 at 11:26, Petar Jovanovic via llvm-commits
>>>> <llvm-commits at lists.llvm.org> wrote:
>>>> > + Violeta
>>>> >
>>>> >> So, this says "[X86]", but is it really X86-specific? there is a
>>>> pretty
>>>> >> huge set of changes to common CFI infrastructure that is used by PPC
>>>> and
>>>> >> AArch64 at least.
>>>> >
>>>> > It is x86-specific in the way that improvements made in this patch
>>>> should
>>>> > affect/improve x86 target only. Other arches can benefit if they make
>>>> > similar changes.
>>>> >
>>>> >> It seems like these late passes (that run on all targets from what I
>>>> can
>>>> >> tell) *require* the new information to be set up in the basic
>>>> block...
>>>> >
>>>> > Yes, but if the new information is not set (i.e. has default values),
>>>> the
>>>> > passes would not make any changes. An alternative is to run these
>>>> passes for
>>>> > selected target(s) only.
>>>> >
>>>> >> How does this work? Is this not a (serious) bug?
>>>> >
>>>> > Violeta has more description in https://reviews.llvm.org/D18046
>>>> > It should not be a bug, more like a place where things can be
>>>> improved for
>>>> > other architectures too.
>>>> >
>>>> > So the passes should not be the problem. The only thing I am
>>>> concerned is
>>>> > that other common code changes may have side effects elsewhere. There
>>>> is
>>>> > a failure on PPC64 sanitizer buildbot and this change is on the blame
>>>> list,
>>>> > so that is being investigated along with the case Eli has reported.
>>>> > _______________________________________________
>>>> > llvm-commits mailing list
>>>> > llvm-commits at lists.llvm.org
>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170629/ec8e497e/attachment.html>