Compilation Failure

Hi all,

Did someone forget to check-in a patch? I'm getting this error during
compilation on PPC:

/Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp:
In function 'void dumpToDOUT(llvm::SparseBitVector<128u>*)':
/Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp:1189:
error: no matching function for call to
'dump(llvm::SparseBitVector<128u>&, llvm::OStream)'
/Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp:
In function 'void dumpToDOUT(llvm::SparseBitVector<128u>*)':
/Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp:1189:
error: no matching function for call to
'dump(llvm::SparseBitVector<128u>&, llvm::OStream)'

-bw

Hi all,

Did someone forget to check-in a patch? I'm getting this error during
compilation on PPC:

A recent checkout compiled fine for me (on x86).

A debug or release build?

-bw

A debug or release build?

-bw

Both, actually.

Weird. I see a potential problem, though. The code is like this:

void dumpToDOUT(SparseBitVector<> *bitmap) {
   dump(*bitmap, DOUT);
}

where dump expects an llvm::OStream& for the second argument. However, when NDEBUG is #defined, DOUT is "llvm::OStream(0)", so it can't be passed by reference.

-bw

What compiler are you compiling with?
I build release and debug builds on darwin (and run the testsuite)
before i check in my changes :).

You can feel free to remove the function, it is simply a GDB helper :slight_smile:

>
> Weird. I see a potential problem, though. The code is like this:
>
> void dumpToDOUT(SparseBitVector<> *bitmap) {
> dump(*bitmap, DOUT);
> }
>
> where dump expects an llvm::OStream& for the second argument.
> However, when NDEBUG is #defined, DOUT is "llvm::OStream(0)", so it
> can't be passed by reference.
What compiler are you compiling with?
I build release and debug builds on darwin (and run the testsuite)
before i check in my changes :).

I'm just using GCC, though it's on Leopard. I'm not sure if they have
a fix to catch this type of code.

You can feel free to remove the function, it is simply a GDB helper :slight_smile:

I just put it inside #ifdef's, so it now works. :slight_smile:

-bw

We ran into a similar problem in our custom code here. To work around
it I modified Debug.h like this:

#ifdef NDEBUG
static llvm::OStream NullStream(0);
#define DOUT llvm::NullStream
#else
#define DOUT llvm::getErrorOutputStream(DEBUG_TYPE)
#endif

                                             -Dave

Hi Dave,

We ran into a similar problem in our custom code here. To work around
it I modified Debug.h like this:

#ifdef NDEBUG
static llvm::OStream NullStream(0);
#define DOUT llvm::NullStream
#else
#define DOUT llvm::getErrorOutputStream(DEBUG_TYPE)
#endif

I thought about doing this, but there's the potential for naming
conflicts that won't be caught until a release build is done. :frowning: I
wonder, though. Would it make sense to put the stream decls in their
own namespace (say "namespace stream")? That way we could prevent
naming conflicts and also this bad "gotcha"...

-bw

I thought about doing this, but there's the potential for naming
conflicts that won't be caught until a release build is done. :frowning: I

I considered this and figured that it was extremely unlikely in our code.
Certainly it's not a bullet-proof solution.

wonder, though. Would it make sense to put the stream decls in their
own namespace (say "namespace stream")? That way we could prevent
naming conflicts and also this bad "gotcha"...

The problem is that you can't use "cerr" so conveniently unless you put
a "using stream::cerr" in Streams.h. Maybe that's ok, though. I'd be willing
to go this route.

                                          -Dave

I am also compiling on leopard, 9a559 :slight_smile:

Okay. :slight_smile: I'm not sure what I'm doing differently. It could just be an
artifact of how the Apple-style builds are done (it's a bit of a
black-box to me). Anyway, It's actually more of a problem with the
LLVM streams in general.

-bw

> I thought about doing this, but there's the potential for naming
> conflicts that won't be caught until a release build is done. :frowning: I

I considered this and figured that it was extremely unlikely in our code.
Certainly it's not a bullet-proof solution.

I'd think it unlikely as well. :slight_smile:

> wonder, though. Would it make sense to put the stream decls in their
> own namespace (say "namespace stream")? That way we could prevent
> naming conflicts and also this bad "gotcha"...

The problem is that you can't use "cerr" so conveniently unless you put
a "using stream::cerr" in Streams.h. Maybe that's ok, though. I'd be willing
to go this route.

Yeah. It's a bit more verbose, but could be worth it. I'll see what I can do.

-bw