Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Remarks #383 and #981

Hi everybody,
we always try to compile with -Wall on any compiler we use. Because of some bad experiences with gcc, we recently switched to icc as our main platform (Linux ICC 11.1). Some of the remarks beingemittedare a bit mysterious, though. I'd reallyappreciatea bit of guidance on the following remarks:
Remark #383: This would be great to get a warning when anunintentionaltemporary is generated. However, it also gets emitted for the code below:
[bash]../../src/utils/UnitTestUtils.h(94): remark #383: value copied to temporary, reference to temporary used
                  throw std::runtime_error("unit test failure");

../../src/utils/UnitTestUtils.h(108): remark #383: value copied to temporary, reference to temporary used
          pass_fail( bool p_arg, std::string p_message, std::size_t const & p_length = 120 ) {
I fully agree that the constants get copied to a temporary in these cases. There is no way to avoid that. I don't think the compiler should emit a remark for it. Is there a way of rewriting the code to avoid the remark while keeping it enabled?
Remark #981: Again has a potential to be useful, but produces (seemingly) unnecessary chatter. The following lines of code appear in an initialization list (i.e. they are constructor calls):
[bash]../../src/utils/data_structures/BiIndex.h(402): remark #981: operands are evaluated in unspecified order
              , m_forward_bounds( std::make_pair( forward_index_type( -1 ), forward_index_type( 0 ) ) )

../../src/utils/data_structures/BiIndex.h(402): remark #981: operands are evaluated in unspecified order
              , m_forward_bounds( std::make_pair( forward_index_type( -1 ), forward_index_type( 0 ) ) )
What does it complain about here? I don't have a copy of the C++ standard handy, but the only possible ambiguity that I can see is the evaluation order of the two forward_index_type() constructors. If the order of those two constructor calls makes a difference in my program, I'd better be looking at a career change... ;-)
Here is another example:
[bash]../../src/utils/data_structures/BiIndex.h(511): remark #981: operands are evaluated in unspecified order
                  if ( c_r_index < m_forward.size() ) { erase( c_r_index ); }

../../src/utils/data_structures/BiIndex.h(532): remark #981: operands are evaluated in unspecified order
                  m_forward[ p_f_index ] = reverse_index_type( -1 );
Again, I would love to know how one could possibly avoid those. Basically almost any comparison operator produces it and the insertion operator (into cout) also sometimes causes them.
Thanks a lot in advance,
0 Kudos
1 Reply

Hi JJ,

First, in release 12.0 we have decided to not emit most of our remarks under
the -Wall option since we want to be more compatible with Gnu and our users
have complained that our -Wall emits many more remarks than Gnu.

We have instead invented another level of warning (-w2) which will cause
remarks to be emitted. So you will only see these remarks in 12.0 if
you used -w2. You will not see them under -Wall.

As far as the specific remarks mentioned in the note above:

(1) remark 383

Please read:

A workaround is not to create a temporary, i.e. create an explicit
string object:

#ifdef OK
std::string s = "unit test failure";
throw std::runtime_error(s);
throw std::runtime_error("unit test failure");

(2) remark 981

This is emitted when two operands (with possible side effects)
like function calls are going to be evaluated in an unspecified order.

For example in your code there are two function calls in an argument
list. It may seem obvious to you and me but the compiler can't
determine whether or not a particularconstructor call has side effects
or not, the function call definitionmay not even be available for analysis in the
current translation unit.

A possible workaround would be:

#ifdef OK
int firstarg = forward_index_type( -1 );
int secondarg = forward_index_type( 0 );
std::make_pair( firstarg, secondarg);
std::make_pair( forward_index_type( -1 ), forward_index_type( 0 ) );

Another (at least theoretical) workaround would be to declare
the functionforward_index_typewith __attribute__((const)) to tell the compiler
this function does not contain any side effects. Unfortunately this doesn't
seem to work currently -- I'll file a bug report...

Just another suggestion. If you know a remark is not helpful or
not indicative of any real problem you can disable it either by a command
line option (-diag-disable number) for the whole translation unit or you can use
#pragma warning (disable:number) ... #pragma warning (enable:number)
surrounding a specific section of code.

I hope this helps. We appreciate your feedback!


0 Kudos