[libcxx-commits] [PATCH] D72160: Optimize / partially inline basic_string copy constructor

[Eric Fiselier via libcxx-commits]

Do you know where the stage2 clang "wrappers" that are being used come
from? They don't appear to be checked in or generated from checked in code.

/Eric

On Mon, Jan 20, 2020 at 4:50 AM Michał Górny <mgorny at gentoo.org> wrote:

> On Mon, 2020-01-20 at 04:31 -0500, Eric Fiselier wrote:
> > I don't see why you think the given error maps to this change.
> >
> > This change isn't in the set of changes in the build you point to:
> > http://lab.llvm.org:8014/builders/netbsd-amd64/builds/834/
> >
> > And the build before it doesn't fail.
> > http://lab.llvm.org:8014/builders/netbsd-amd64/builds/833/
> >
> > Can you elucidate why this change is responsible?
> >
>
> I'm not sure how you infer that.
>
> Build 834 has got_revision a93aa5347641159aa0d2d48dda9e1a51b2273462.
>
> a93aa534764 [lldb/Docs] Fix formatting for the variable formatting page
> 64c4dcb5eef [mlir][Linalg] Extend linalg vectorization to MatmulOp
> a8a9c8e0a11 [libc++] Optimize / partially inline basic_string copy
> constructor
> cd40bd0a32e hwasan: Move .note.hwasan.globals note to hwasan.module_ctor
> comdat.
>
> So your commit is two commits before that build.  Build 833 has
> cd40bd0a32e29fb62c89b120adbc89a847443da3 which confirms the given range.
>
> I've further bisected this and it confirms a8a9c8e0a11 being
> the culprit.
>
> To be honest, I have no clue what the scheduler is doing there and why
> it's running things out of order.
>
> --
> Best regards,
> Michał Górny
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20200120/f8fc2a16/attachment.html>