- User Since
- Jan 10 2013, 2:43 PM (395 w, 5 d)
Mon, Aug 10
I reverted this since it broke building obj2yaml on all bots, and the fix wasn't immediately clear to me. (We need to pass some warning handler, but I don't know which one's appropriate in obj2yaml.)
Thu, Aug 6
Wed, Aug 5
Fair enough, an assert seems ok then.
This probably breaks the build on systems where uint64_t and size_t are different types, such as apparently on macOS:
This breaks tests on windows: http://22.214.171.124/win/21396/step_10.txt
Tue, Aug 4
Sun, Aug 2
If the fix is quick (< 15 min), you can fix too.
Fri, Jul 31
Wed, Jul 29
That did the trick, thanks!
Looks like it's still failing with that change: http://126.96.36.199/win/20885/step_7.txt
This breaks check-clang on Windows: http://188.8.131.52/win/20850/step_7.txt
Tue, Jul 28
Looks like this breaks tests on win: http://184.108.40.206/win/20771/step_10.txt
Mon, Jul 27
Fri, Jul 24
Thu, Jul 23
It's maybe a bit surprising that we have both llvm-extract and extract that are unrelated binaries?
I wouldn't worry about the Windows header. It's some pre-existing thing and nobody seems to care.
Wed, Jul 22
Tue, Jul 21
Looks like this breaks tests on Windows: http://220.127.116.11/win/20315/step_7.txt
Looks like this breaks tests on macOS (and probably with non-gnu greps): http://18.104.22.168/mac/17611/step_9.txt
Thanks for the patch!
We're seeing some build warnings in ffmpeg due to this not being in yet. Could you try to land it soon?
Fri, Jul 17
Thu, Jul 16
Wed, Jul 15
Tue, Jul 14
Jul 13 2020
It puts the C++ code in C++ files :)
Jul 11 2020
Great, thanks :)
As discussed a while ago in D81736. It's about half as much code.
…oh, njames said that already 5h ago :) I guess I'll wait another hour or two, and then I'll revert.
This breaks check-clang on macOS: http://22.214.171.124/mac/17053/step_7.txt
Jul 9 2020
Jul 8 2020
Cool. Could you check this in, please?
Jul 7 2020
Thanks! Should the release notes grow an entry mentioning the behavior change and this flag?
Jul 6 2020
Hello, this seems to increase runtime of some dwarf processing tools for us by several orders of magnitude (from "terminate in a few minutes" to "don't know how long they terminate; not before our timeouts"). https://bugs.chromium.org/p/chromium/issues/detail?id=1102223#c5 has repro steps.
This seems to break tests everywhere, eg http://126.96.36.199/linux/22152/step_7.txt or
Jul 4 2020
Jul 2 2020
Jul 1 2020
That's not enough, you also need to add an rm to remove the stale .LL file still on disk, see my comment on your original change.
I think being compatible with ml64 by default is good, and making progress here seems better than holding this up for even longer.
This (or a follow-up) broke tests on windows: http://188.8.131.52/win/18877/step_7.txt