- User Since
- Jan 10 2013, 2:43 PM (418 w, 4 d)
Fri, Jan 15
Didn't look at the diff, but there's already code in the tree that requires python3 (eg subprocess.DEVNULL in compiler-rt/test/lit.common.cfg.py). So that part is fine.
Thu, Jan 14
Wed, Jan 13
We're looking into bumping libc++ in chromium, and this is a problem for us. We statically link libc++, and we still support 10.11. (We _just_ dropped support for 10.10 in our last release iirc.) What do you recommend as path forward?
Do we emit a warning if we see -gsplit-dwarf alone? Should we?
I'll revert this for now to unbreak the bot since figuring out a way forward will likely take a few hours.
This breaks hwasan tests on my bot: http://184.108.40.206/linux/37054/step_10.txt
Tue, Jan 12
Looks like this breaks tests on windows even after all the fix attempts: http://220.127.116.11/win/31260/step_11.txt
Mon, Jan 11
Hi, this broke check-clang everywhere as far as I can tell. Please run tests before committing. I've reverted this for now in 419ef38a50293c58078f830517f5e305068dbee6.
Sun, Jan 10
Sat, Jan 9
As far as I can tell, ld64 only accepts -undefined warning and -undefined suppress with -flat_namespace (which lld/MachO doesn't yet implement). That makes sense since with a flat namespace the undefineds can be found at dynamic link time, but with two-level lookup they can't since they containing framework isn't known (…right?).
Fri, Jan 8
Thu, Jan 7
Wed, Jan 6
It turned out to be UB in our code as far as I can tell, see https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c36 and the follow-on.
We bisected a test failure to this (https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c17). Can you expand a bit on what this patch means in practice? I'm guessing it makes UB in C++ code have bad effects more often? If so, what type of UB?
Mon, Jan 4
Looks good, thanks for the quick fix :)
Looks like this breaks tests on arm macs: http://18.104.22.168/macm1/1057/step_10.txt
Sun, Jan 3
Looks like this worked :)
I don't have a win machine at hand either, but let's land this and see what the win bot on http://22.214.171.124/ thinks about this. It should take at most 15 min to cycle.
Sat, Jan 2
Reverted in fe9976c02c09f105751f787ec998abeb3414a235 for now. If you could wait with relanding during working hours, that'd be super appreciated. Thanks!
Fri, Jan 1
Wed, Dec 30
Tue, Dec 29
Looks like this breaks tests on mac: http://126.96.36.199/macm1/897/step_10.txt
Thu, Dec 24
Looks like this breaks tests on arm64-apple-macos: http://188.8.131.52/macm1/761/step_10.txt
Wed, Dec 23
Heads up: Breaks a test for us: https://bugs.chromium.org/p/chromium/issues/detail?id=1161542
...and two more in 1876a2914fe0bedf50f7be6a305f5bf35493e496. Sorry for the churn!
I reverted this (and a bunch of stuff that landed on top of it) in 7ad666798f12456d9e663e763e17e29007c3728d for now.
I verified it's due to this change. https://bugs.chromium.org/p/chromium/issues/detail?id=1161230#c15 has a stand-alone repro.
Heads-up: Looks like one of these changes, likely this one for CodeGen, made sanitizer output way larger: https://bugs.chromium.org/p/chromium/issues/detail?id=1161230
(nit: Consider checking in obviously-behavior-preserving changes like stripping namespace prefixes without pre-commit review, and only send out the behavior-changing bits.)
Tue, Dec 22
Looks like this breaks tests on windows: http://184.108.40.206/win/30322/step_8.txt
tweak -v help text
I just found this and realized I missed it for a very long time. I tried adding a test case, but while doing so I think this change doesn't actually change behavior: StringMapImpl::swap is only used by StringMap<T>::operator=, which guarantees that lhs and rhs have the same T and the underlying StringMapImpls the same ItemSize for that reason.
reverted in 00065d5cbd02b0f3fccb34881b58bcd0852b3970
Also, rnk's comment above wasn't addressed as far as I can tell.
This seems to break all tests on all platforms: http://220.127.116.11/linux/35854/step_7.txt
Mon, Dec 21
Actual bench.py / ministat before/after data: