I think this happens when you build Mesa with debugging enabled and LLVM without it enabled.  It's still a bug though.  For now, you could try building a debug version of both Mesa and LLVM.  I think that will fix it.

OK, I disabled mesa debug but now I get this (current git):

make[5]: *** No rule to make target `../../../../../../src/gallium/drivers/radeon/libradeon.a', needed by `libr600.a'.  Stop.

Full log at:
https://launchpadlibrarian.net/103127393/buildlog_ubuntu-precise-i386.mesa_8.1~git1204261417.a2f7ec~gd~p_FAILEDTOBUILD.txt.gz

/w llvm-1.3~rc1  same as you.

I'm changing to rc2.

I get this:
https://launchpadlibrarian.net/104275700/buildlog_ubuntu-precise-i386.mesa_8.1~git20120504.5cc4b4aa-1ubuntu0cheako2~precise_FAILEDTOBUILD.txt.gz

g++ -c -I. -I../mesa -I../mapi -I../../include  -D_FORTIFY_SOURCE=2 -Wall -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2    -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DCHAN_BITS=16 -DDEFAULT_SOFTWARE_DEPTH_BITS=31  -DFEATURE_GL=1 -fvisibility=hidden -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DCHAN_BITS=16 -DDEFAULT_SOFTWARE_DEPTH_BITS=31  -DFEATURE_GL=1 opt_swizzle_swizzle.cpp -o opt_swizzle_swizzle.o
  CC     r600_llvm.o
make[5]: *** No rule to make target `../../../../../../src/gallium/drivers/radeon/libradeon.a', needed by `libr600.a'.  Stop.
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/build/buildd/mesa-8.1~git20120504.5cc4b4aa/build/dri/src/gallium/drivers/r600'

This bug cloned to: https://bugs.freedesktop.org/show_bug.cgi?id=49567

No rule to make target libradeon.a, needed by libr600.a.

Commit c425c3823fbd475dc83211fef47f7ea58421ed17 should have fixed this, but it don't.  I've looked at the llvm headers and it looks like a number of preprocessor macros will include these, if NDEBUG is not set.

I'm now going to try and set that.

I've added 3 patches to http://llvm.org/bugs/show_bug.cgi?id=12759 and did my best to describe what/why.

I believe that mesa also needs this done for it's use of NDEBUG, especially if #if(s) are used to protect object exports in include files as was the case with llvm.  Either way, it's still possible for mesa to not directly trample over this project global define.

This is essentially what I did for llvm:
#ifdef LLVM_NDEBUG
#define NDEBUG LLVM_NDEBUG
#endif
#include <assert.h>

In the case where assert.h is included in an include file, like FLAC and alsa do, then NDEBUG should be save/restored around the assert.h include...  Not that it'll do any good as in those situations it's first come first served and projects that use assert will likely include it ~vary~ early.

Hello,
  I've concluded that there just isn't enough time until Diablo III is released and so I hope that I can get myself to halt all work on this issue.

The llvm r600g compiler isn't close enough to the horizon for me to see it being useful by May 15th.

Thank you.

This looks fixed now.

Fabio Pedretti,
  I think we should wait for "solution", testing and compliance to declare this closed.  I'm glad you got it working, but I'm unable to verify what the solution was or how this got fixed.

So I'm re-opening this bug and hopefully I can get an explanation as to why this is fixed now.

Thank you!

(In reply to comment #9)
> Fabio Pedretti,
>   I think we should wait for "solution", testing and compliance to declare this
> closed.  I'm glad you got it working, but I'm unable to verify what the
> solution was or how this got fixed.
> 
> So I'm re-opening this bug and hopefully I can get an explanation as to why
> this is fixed now.
> 
> Thank you!

The call to isCurrentDebugType was deleted from this file.

Fixed in: c425c3823fbd475dc83211fef47f7ea58421ed17