I don't think anyone on our team is set up to do iOS development to reproduce and debug this. =/

Has this workflow worked in the past? If so, can you provide a time window for the regression?

For me, it is early November.
For Javierrobles who also has the issue, it was Thursday morning.
Current hypothesis is that the trigger is the installation of macOS Mojave (at least, Javier installed it on Wednesday night, and we know it was working for him earlier this week). For me, this would also match even if I cannot be that precise.

justincohen who also confirmed the issue, also has Mojave installed.

Bisecting on is.gd/chromeclang, I get:
good: 344066
bad:  346074

There's a pretty big gap between those two.  Any ideas before I have to do further bisect?  bisecting this super time intensive since I have to build clang, then build chrome, all without goma...

Can you repro with base_unittests or even boringssl_ssl_tests? That builds somewhat quickly even without goma (the latter even more so than the former)

Yes, base_unittests.app on a device with --gtest_filter CRBProtocolObserversTest.WeakReference and set a bp at:
base_unittests`::+[CRBWeakNSProtocolSentinel containerForObject:](id) + 212 at weak_nsobject.mm:39

As I step thru the code I jump from line 47 back to 46 un expectedly.

good: 345070

Looks like 347933 is already fixed, so whenever we do the next roll, this problem should be fixed.

olivierrobin@ can you confirm this is fixed when rolling past 347933?

> olivierrobin@ can you confirm this is fixed when rolling past 347933?

You can build with that by checking out and syncing Chromium #612660 / 0bdd3c25975f763d121802a092c1ef0925049976 (it was later reverted). That works with Goma too.

Tested with suggestions in 11-12 and it works fine.

Great, thanks for verifying! Marking this blocked on the roll.

This should be better now.

OK, the bad news is that the fix in 347933 seems to have been remove and I still have the issue with the latest 349417

I tested again and 347933 still works, but 348507 is already broken.
So something must have been reverted in this range.

thakis/hans@ before I start doing local clang builds to test, do any changes in that range look suspect?  Did we ever identify that was broken and then reverted before?

I think nobody found the root cause.

I did a bissect search (on a small code portion, so there may be other issues), but it seems that 348319 works, 348320 is broken.

As 348320 is both a reland and makes changes to AArch64InstructionSelector.cpp, this may be a good candidate

Rev 348320:
[AArch64][GlobalISel] Re-enable selection of volatile loads.

We previously disabled this in r323371 because of a bug where we selected an
extending load, but didn't delete the old G_LOAD, resulting in two loads being
generated for volatile loads.

Since we now have dedicated G_SEXTLOAD/G_ZEXTLOAD operations, and that the
tablegen patterns should no longer be able to select (ext(load x)) patterns, it
should be safe to re-enable it.

The old test case should still work as expected.

It sounds like it relands something removed in r323371, which is outside the regression window in comment 6. It also feels like an unlikely candidate to me...how confident are you in the bisection?

Not 100%, I had to take some shortcuts to not have to recompile chrome every time.

I synced llvm and clang at 348319 and 348320
build clang (incrementally)

rebuild a single file in Chrome and link
and debug the app.

When you do this,
clang@348319, it works fine 
with
clang@348320, it jumps on some steps.


The bissect is

OK	KO	Next	Result
0	999999	347933	OK
347933	999999	348507	KO
347933	348507	348220	OK
348220	348507	348363	KO
348220	348363	348291	OK
348291	348363	348327	KO
348291	348327	348309	OK
348309	348327	348318	OK
348318	348327	348322	KO
348318	348322	348320	KO
348318	348320	348319	OK

(I put the breakpoints in the file I recompile every time).