I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler. My only hypothesis is some sort of memory corruption. I will keep you posted. On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote:> Also, when are you planing to "reapply the changes or help debug"? > > On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: >> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>> Hi Kostya, >>> >>> Thanks for the heads-up on this. I haven’t had a chance to look into the >>> details yet, but it looks like these patches may be breaking our >>> bootstrapped LTO build. Our buildbots have been failing all day, and we’re >>> still trying to figure out the problem. I’m going to speculatively revert >>> those changes, since they were the only patches on the buildbot blame list. >>> I will either reapply the changes or help debug the problem. >> >> How could this possibly affect your LTO build? >> The option is off by default. >> Do you have any details, logs, etc? >> >>> >>> —Bob >>> >>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>> >>> Bob, Justin, >>> >>> I've just committed a poor man's coverage implementation that works with >>> asan. >>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>> It provides only function-level boolean coverage (i.e. no counters, just >>> "visited or not"), >>> but is very fast and very simple (no extra sections to the binary file, etc) >>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>> overhead >>> is negligible at both run-time and shutdown-time. >>> >>> We'll be evaluating this implementation and collecting usage stats. >>> Maybe we want to implement something simple like this in the Clang coverage. >>> >>> --kcc >>> >>>
What are the symptoms? On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote:> I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. > > I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler. My only hypothesis is some sort of memory corruption. > > I will keep you posted. > > On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: > >> Also, when are you planing to "reapply the changes or help debug"? >> >> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: >>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>>> Hi Kostya, >>>> >>>> Thanks for the heads-up on this. I haven’t had a chance to look into the >>>> details yet, but it looks like these patches may be breaking our >>>> bootstrapped LTO build. Our buildbots have been failing all day, and we’re >>>> still trying to figure out the problem. I’m going to speculatively revert >>>> those changes, since they were the only patches on the buildbot blame list. >>>> I will either reapply the changes or help debug the problem. >>> >>> How could this possibly affect your LTO build? >>> The option is off by default. >>> Do you have any details, logs, etc? >>> >>>> >>>> —Bob >>>> >>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>> >>>> Bob, Justin, >>>> >>>> I've just committed a poor man's coverage implementation that works with >>>> asan. >>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>> It provides only function-level boolean coverage (i.e. no counters, just >>>> "visited or not"), >>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>> overhead >>>> is negligible at both run-time and shutdown-time. >>>> >>>> We'll be evaluating this implementation and collecting usage stats. >>>> Maybe we want to implement something simple like this in the Clang coverage. >>>> >>>> --kcc >>>> >>>> >
The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> wrote:> What are the symptoms? > > On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. >> >> I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler. My only hypothesis is some sort of memory corruption. >> >> I will keep you posted. >> >> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: >> >>> Also, when are you planing to "reapply the changes or help debug"? >>> >>> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: >>>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >>>>> Hi Kostya, >>>>> >>>>> Thanks for the heads-up on this. I haven’t had a chance to look into the >>>>> details yet, but it looks like these patches may be breaking our >>>>> bootstrapped LTO build. Our buildbots have been failing all day, and we’re >>>>> still trying to figure out the problem. I’m going to speculatively revert >>>>> those changes, since they were the only patches on the buildbot blame list. >>>>> I will either reapply the changes or help debug the problem. >>>> >>>> How could this possibly affect your LTO build? >>>> The option is off by default. >>>> Do you have any details, logs, etc? >>>> >>>>> >>>>> —Bob >>>>> >>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>> >>>>> Bob, Justin, >>>>> >>>>> I've just committed a poor man's coverage implementation that works with >>>>> asan. >>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>>> It provides only function-level boolean coverage (i.e. no counters, just >>>>> "visited or not"), >>>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>>> overhead >>>>> is negligible at both run-time and shutdown-time. >>>>> >>>>> We'll be evaluating this implementation and collecting usage stats. >>>>> Maybe we want to implement something simple like this in the Clang coverage. >>>>> >>>>> --kcc >>>>> >>>>> >>