Error compiling concurrent_vector.h with Clang

Error compiling concurrent_vector.h with Clang

Trying to upgrade from TBB 4.1 Update 1 to Update 4, I ran into this error compiling for Linux with Clang:

.../tbb/concurrent_vector.h:667:38: error: conditional expression is ambiguous; 'size_type' (aka 'unsigned long') can be converted to 'atomic<size_type>' and vice versa
        return iterator(*this, delta ? internal_grow_by( delta, sizeof(T), &initialize_array, NULL ) : my_early_size);

The solution is simple -- use an expicit cast to size_type on my_early_size to resolve the ambiguity.  I don't care whether Clang++ is correct in claiming the ambiguity; I just want to be able to compile TBB with the version of Clang I downloaded a few months ago.

Can someone add this cast to TBB code for the next update?  I found similar expressions in 3 other places in the same header and fixed all 4 in my copy.

10 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Raf Schietekat

You mention TBB's version, but not Clang's: I don't see this problem on an up-to-date OS X, using the Xcode Command Line Tools, probably because I don't have __TBB_CONSTEXPR_PRESENT, nor __TBB_DEFAULTED_AND_DELETED_FUNC_PRESENT, and therefore also not __TBB_ATOMIC_CTORS, which protects me from the... non-explicit one-argument constructors.

Please verify what happens if the __TBB_ATOMIC_CTORS-specific one-argument atomic constructors are made explicit.

(Note that any perceived simplicity of a workaround does not automatically qualify it as "the solution".)

It was a version of Clang downloaded via svn on Dec. 11, 2012.  I am building the released 3.3 version now, and I'll try out the unmodified TBB 4.1.4 next week.

Can you point me to the constructors that I should make explicit?  The templates and macros in atomic.h make it less than obvious which ones you mean.  Is it just line 416 in atomic.h?

Portrait de Raf Schietekat

Mine is "based on LLVM 3.2svn".

As indicated, the constructors are all specific to __TBB_ATOMIC_CTORS, so look for that. Note that there are several specialisations.

I had time to try out the suggestion to make the constructors explicit (lines 416 and 429), and that solved the problem.  There are probably some other lines that would need to be made explicit, but the change in line 429 was sufficient for my application.  I will also try out the unmodified atomic.h next week, after I have installed the new Clang.

However, someone still must decide whether it is desirable to make those constructors explicit.  It seems fine to me, but if some other TBB code expects them to be used for implicit conversions, that would have to be changed as well.  Next week I will rebuild TBB with explicit atomic constructors to make sure they are acceptable to TBB's internal uses.

Portrait de Raf Schietekat

I don't think that Clang can be blamed here (I'll assume it was a development snapshot for 3.3?), and I don't expect an official version 3.3 to provide a different outcome (I'm also curious what compiler was used to test this!), but otherwise I would love to hear an explanation (the specification for the conditional operator seems to support the diagnostic).

TBB didn't have implicit conversions before, and I don't see how they could be useful.

I tried it again with the released Clang 3.3, and it gives the same result.

Unless you suggest otherwise, I'll add 'explicit' to the conversion constructors in atomic.h and hope that the next update includes a fix.

Thanks for your help.

Portrait de Raf Schietekat

An acknowledgement by somebody from Intel's TBB development team would be nice?

Portrait de Vladimir Polin (Intel)

we will try to get the answer later this week.

--Vladimir

Portrait de Vladimir Polin (Intel)

The issue was fixed and the fix should be available in one of coming updates.

--Vladimir

Connectez-vous pour laisser un commentaire.