Bug 49110

Summary: debug build: AMDILCFGStructurizer.cpp:1751:3: error: 'isCurrentDebugType' was not declared in this scope
Product: Mesa Reporter: Fabio Pedretti <pedretti.fabio>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: low CC: cheako+bugs_freedesktop_org
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=49567
http://llvm.org/bugs/show_bug.cgi?id=12759
Whiteboard:
i915 platform: i915 features:

Description Fabio Pedretti 2012-04-24 07:03:37 UTC
I get this compile error when building the new LLVM compiler:

AMDILCFGStructurizer.cpp:1751:3: error: 'isCurrentDebugType' was not declared in this scope

Full log is available here:
https://launchpadlibrarian.net/102973365/buildlog_ubuntu-precise-amd64.mesa_8.1~git1204241446.587c22~gd~p_FAILEDTOBUILD.txt.gz
Comment 1 Tom Stellard 2012-04-24 16:04:18 UTC
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.
Comment 2 Fabio Pedretti 2012-04-26 06:14:49 UTC
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
Comment 3 Mike Mestnik 2012-05-04 21:07:05 UTC
/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'
Comment 4 Mike Mestnik 2012-05-06 20:44:15 UTC
This bug cloned to: https://bugs.freedesktop.org/show_bug.cgi?id=49567

No rule to make target libradeon.a, needed by libr600.a.
Comment 5 Mike Mestnik 2012-05-07 16:50:36 UTC
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.
Comment 6 Mike Mestnik 2012-05-08 20:25:23 UTC
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.
Comment 7 Mike Mestnik 2012-05-10 14:43:40 UTC
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.
Comment 8 Fabio Pedretti 2012-09-01 19:09:34 UTC
This looks fixed now.
Comment 9 Mike Mestnik 2012-09-02 15:45:51 UTC
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!
Comment 10 Tom Stellard 2012-09-02 19:23:56 UTC
(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.
Comment 11 Mike Mestnik 2012-09-02 20:52:10 UTC
Fixed in: c425c3823fbd475dc83211fef47f7ea58421ed17

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.