- User Since
- Jan 10 2013, 2:43 PM (402 w, 5 d)
Mon, Sep 28
Sat, Sep 26
Thu, Sep 24
All devs do incremental builds. Of course incremental builds should work.
Sounds like that puts it in the "takes a while to figure out" category, so revert for now?
Wed, Sep 23
This seems to break tests everywhere, eg http://188.8.131.52/linux/28628/step_11.txt
I believe I used this (by hacking up the gn files) locally on mac a while ago, but I'm not sure. LG, I'll try asan on mac and relax the assert if it works.
Sat, Sep 19
Fri, Sep 18
I agree, it does look pretty complicated :)
Which header do you think is missing? It built fine on several machines over here.
lg assuming we have tests for float literals containing an e in them somewhere already.
Thu, Sep 17
Wed, Sep 16
Looks like this doesn't build: http://184.108.40.206/linux/27982/step_4.txt
This seems to break tests on most bots, e.g. http://220.127.116.11/linux/27972/step_12.txt
Tue, Sep 15
Looks like this breaks tests: http://18.104.22.168/linux/27942/step_12.txt
Looks like this breaks tests on mac: http://22.214.171.124/mac/20491/step_11.txt
It's not blocking us because we added an explicit flag to force this off to our build config for "normal" builds. (We still get the default-on behavior on our bots that build with trunk clang.) But if others are seeing problems with this too, I think it makes sense to revert so others don't spend time tracking down miscompiles to this commit.
Mon, Sep 14
(marking this "request changes" to get it off my dashboard. please ping if you do add a test :) )
Maybe have a test covering the parse error case too.
Sun, Sep 13
Heads-up: We're seeing fairly widespread test failures with this in Chromium that go away when we force this flag off. It's possible that it's due to only a small number of issues and they might be previously-benign UB (no idea), but I figured I'd give an early note. We'll send an update once we've reduced a failing test.
Sat, Sep 12
The fix-up breaks tests: http://126.96.36.199/linux/27687/step_12.txt
Fri, Sep 11
Thu, Sep 10
Looks like this broke check-llvm: http://188.8.131.52/linux/27555/step_12.txt
Wed, Sep 9
Tue, Sep 8
Fri, Sep 4
Reverted this (and some follow-ups that caused conflicts during the revert) in rGdbf04aaade235a0d76c6ad549c091c9fd0ada0e8 to unbreak the Windows build.
(I fixed this in the GN build in rGc88a77620436ee475d54d3b5ced30286101e0dc9 and don't care all that much about what happens in the cmake build, so if y'all are happy with what currently happens, it's fine to not change anything here, but it looks strange to me.)
(ps: No need to touch files in llvm/utils/gn at all, keeping that code updates is up to folks using the gn build.)
This puts #!/usr/bin/python3.8 instead of #!/usr/bin/env python3.8 in llvm-bulid/bin/llvm-lit (in a cmake build). That seems undesirable?
Thu, Sep 3
rG82f3c5d4a66 cross-ref so i can find this faster next time
Generally seems fine, nits below:
I don't think this should become the default.
Wed, Sep 2
Looks like this broke tests on windows: http://184.108.40.206/win/23171/step_7.txt
Tue, Sep 1
Thanks for updating the GN files! I just wanted to point out that updating them is completely optional.
Aug 27 2020
One of the N patches that landed 9:45 pm eastern yesterday seems to break check-lld on mac: http://220.127.116.11/mac/19510/step_10.txt
Aug 25 2020
Aug 24 2020
(I'm guessing it was failing under cmd previously and fails in msys/gig bash now?)
This breaks check-llvm on windows: http://18.104.22.168/win/22625/step_11.txt
Aug 21 2020
Aug 18 2020
Aug 14 2020
(I made the crbug public again)