Remark #981

[kfsone]

The following code with -w2

[cpp]struct Foo
{
  unsigned char a, b, c, d;
  unsigned int intValue() const
  {
    return ((int)a << 24) | ((int)b << 16) | ((int)c << 8) | (int)d;
  }
  bool operator==(const Foo& rhs) const
  { // next line produces #981
    return this->intValue() == rhs.intValue();
  }
};
[/cpp]

produces #981: operands are evaluated in unspecified order

Having done a search on #981, this remark would seem to be useless ... But before I simply add -wd981, I wondered if there was some optimization or some set of flags that you were intended to take into consideration?

I'm wary of just turning this warning off but since I can't figure out what the problem is, I'm having a hard time figuring how to fix some of these 981s aside from the laborious

[cpp]operator==(const Foo& rhs)
{
  int myIntValue = this->intValue();
  int rhsIntValue = rhs.intValue();
  return myIntValue == rhsIntValue;
}[/cpp]

[kfsone]

(I'm guessing that there is some way to tell the compiler a function is entirely deterministic - that nothing is modified or changed by the calls,like the gcc 'pure' attribute, so that ordering is not relevant)

[Kittur_G_Intel]

Hi,

I checked with our other compiler experts too on this and this is what we have on icc:

ICCdoes recognize and process the "pure" attribute, much like GCC. Unfortunately, it matters only to the optimizer, and specifically, it doesn't affect the emission of #981. In C++, functions without side effects tend to be so common that our compiler developers recommend disabling #981 -- the noise-to-signal ratio is typically just too high. But for C code, #981 is more likely to be useful.

Hope the above helps. Let me know if you need any more info.

[kfsone]

Quoting - Kittur Ganesh (Intel)

Hi,

I checked with our other compiler experts too on this and this is what we have on icc:

ICCdoes recognize and process the "pure" attribute, much like GCC. Unfortunately, it matters only to the optimizer, and specifically, it doesn't affect the emission of #981. In C++, functions without side effects tend to be so common that our compiler developers recommend disabling #981 -- the noise-to-signal ratio is typically just too high. But for C code, #981 is more likely to be useful.

Hope the above helps. Let me know if you need any more info.

I kind of suspected as much, having spent a little more time with the ICC it seems like it desperately needs a "-pedantic" and this would be a good candidate for promotion to that flag.

- Oliver

[Eduardo_J__Sanchez_P]

Hi,

In C++, functions without side effects tend to be so common that our compiler developers recommend disabling #981 -- the noise-to-signal ratio is typically just too high.

How can we disable it?

Thanks.

[SergeyKostrov]

You can disable the remark with #pragma warning ( disable : 981 ) directive or in a VS project settings. Note: Take into account that some remarks can not be disabled due to some issues with Intel C++ compiler. I always try to use both ways to disable a warning or a remark.

[Eduardo_J__Sanchez_P]

Sergey, thanks for your reply:

You can disable the remark with #pragma warning ( disable : 981 ) directive

Where could it be located within, say a source file?

Thanks.

[Judith_W_Intel]

Put the #pragma at the top of your file (or anywhere before the diagnostic is emitted).

Or just use the -Qdiag-disable:981 command line option.

[Eduardo_J__Sanchez_P]

Dear Judith! Thanks! I appreciate your response!

\m/

[Judith_W_Intel]

I see you are on Linux -- in which case you can use the -diag-disable 981 command line option instead of a #pragma.