similar to: Pass is not initialized

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

It looks like this broke green dragon: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173: note: Adding environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',

> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at google.com> wrote: > > I checked in a fix for that already, sorry for the trouble. I’m waiting for it to cycle awesome. Thanks! -- adrian > On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > It looks like this broke green dragon: > >

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when

> On Dec 6, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote: > > Adrian, Mike, Chris? Any update on this? I've temporarily switched to working on something different, but I plan to be back on this in a couple of weeks. It's been a month since my first revert of this CL, which seems like a reasonable amount of lead-time to deal with issues surrounding

> On Dec 6, 2017, at 10:21 AM, Zachary Turner <zturner at google.com> wrote: > > Can I have some assurance that if it fails again, someone will look into who has access to the builders so I don't have to keep doing speculative commits? Sure. I did this last time and I promise to also do it this time. -- adrian > > On Wed, Dec 6, 2017 at 10:13 AM Adrian Prantl

On Tue, Feb 21, 2012 at 2:51 AM, Jay Foad <jay.foad at gmail.com> wrote: > All, > > This buildbot is getting lots of assertion failures in the test suite. > They were probably caused by my commit: > > ------------------------------------------------------------------------ > r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines > Changed paths: >

Hi Owen, I'm seeing this failure on one of my machines -- PPC G5: $ # APPLE LOCAL use -mlongcall for large text support /Volumes/SandBox/Clean/bug/llvm-gcc.obj/./gcc/xgcc -B/Volumes/SandBox/Clean/bug/llvm-gcc.obj/./gcc/ -B/Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/bin/ -B/Volumes/SandBox/Clean/bug/llvm-gcc.install/powerpc-apple-darwin9.1.0/lib/ -isystem

Has anyone succeded ? I got the following error message ------------- /project//g/cslp/llvm_sparc/front_end/obj/./gcc/xgcc -B/project//g/cslp/llvm_sparc/front_end/obj/./gcc/ -B/project//cslp/llvm_sparc/front_end/obj/../install/sparc-sun-solaris2.10/bin/ -B/project//cslp/llvm_sparc/front_end/obj/../install/sparc-sun-solaris2.10/lib/ -isystem

Hello all, I am trying to install the llvm-gcc front end to use it in one of my projects, but I got stuck.. I am working on a Sun workstation: SunOS xxx 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V240 and I have gcc version 3.4.6: Reading specs from /sw/gcc-3.4.6/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: /.scratch/andjo/lsw/src/gcc/gcc-3.4.6/configure

All, This buildbot is getting lots of assertion failures in the test suite. They were probably caused by my commit: ------------------------------------------------------------------------ r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines Changed paths: M /llvm/trunk/lib/VMCore/LLVMContextImpl.h M /llvm/trunk/lib/VMCore/Type.cpp PR1210: make uniquing of struct and

On Jan 10, 2008, at 12:52 PM, Thomas Jablin wrote: >> > Based on your response I've removed the #undef DBX_DEBUGGING_INFO in > gcc/config/ia64/sysv4.h. I don't need stabs debugging so if it is > broken > in my final build, I won't care. After doing so, my llvm-gcc build > runs > for a much longer time before finally dying while running xgcc. Here > is

/home/ang/build/llvm-gcc-coff/./gcc/xgcc -B/home/ang/build/llvm-gcc-coff/./gcc/ -B/home/ang/llvm-gcc/i686-pc-cygwin/bin/ -B/home/ang/llvm-gcc/i686-pc-cygwin/lib / -isystem /home/ang/llvm-gcc/i686-pc-cygwin/include -isystem /home/ang/llvm-gcc /i686-pc-cygwin/sys-include -O2 -I/home/ang/svn/llvm-gcc-coff/gcc/../winsup/w32 api/include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings