Compiler bug with Intel C++ (WIndows Version 14.0.3.202 Build 20140422)

[wayne-wooten]

To demonstrate a bug in icc Version 14.0.3.202 Build 20140422

to build:

From the command line icc tools cmd.exe run:

C:\iccbug> make.bat 

C:\iccbug> .\bug.exe

If code runs as expected bug.exe prints no output. If the bad

behavior is exhibited it prints:

bug! fullybuffered requested "int" got "fullybuffered"

There are several ways to get 14.0.3.202 to compile this correctly:

1. remove -Qrestrict from the OPTS in make.bat

2. remove -O3 from OPTS in make.bat

3. in optionv.c change the "#if 0" to "#if 1". This inserts one extra

fprintf call that should not functionally change the code.

I have tried this code and it runs correctly with icc 11.1 and 12.1, vc11, and vc10. 

They all generate the expected result.

(Reported by James Burgess)

--Wayne

[TimP]

I get "Page not Found" for that URL on IDZ.

Not having seen the source, it seems strange that /Qrestrict could cause a case to compile and link but fail at run time, unless restrict has been used as an identifier which presumably is permitted in C89 or C++.

Recent Intel compilers seem to have been taking advantage sometimes (at -O3) of the standard on typed aliasing (and not reporting violations of it, some of which might be detectable).  Earlier Intel compilers required /Qansi-alias to perform such optimizations, and Microsoft compilers don't optimize except with use of __restrict qualifier.  For use of __restrict, /Qrestrict doesn't need to be set.  The documentation has confused people on that point.

The change in Intel compilers was announced as applying only on linux, and only to 15.0 series, but I haven't been able to show that this restriction was observed.

[Shenghong_G_Intel]

Hi Wayne,

I can download the attached code, and reproduce the issue.

I think it is a bug of course, as you even do not use 'restrict' keyword in your code at all (correct me if I am wrong).

@Tim,

In the attached code, Wayne does not use "restrict" keyword at all, so, it looks like nothing related to aliasing. It is very strange and looks like compiler is just going crazy (adding /Qrestrict should not affect anything int this case as 'restrict' is not used)...

Thanks,

Shenghong

[TimP]

That download has become available.

It's a little strange to set the compile options after the source file name.

/Qrestrict doesn't have the reported effect with my compiler, but -O3 does.

[Shenghong_G_Intel · Accepted solution]

I can reproduce the issue with both 14.0 and 15.0 beta compiler, and get same effect as Wayne mentioned. The issue exists when O2 or O3 and /Qrestrict are used together.

I've submitted the issue to developer team to fix.

Thanks,

Shenghong

[wayne-wooten]

Thanks for looking into it and reproducing it. It certainly seemed like a compiler issue.

--Wayne

[TimP]

I'm not satisfied that the issue has been satisfactorily isolated.

For example, I don't get any differences in .asm files generated with -O2 and -O3, even though the run-time result changes.  It's annoying that the windows compiler generated .asm isn't accepted by the microsoft assembler ml64.

[wayne-wooten]

Not sure what -O2 vs -O3 have to do with problem. The problem exists with both -O2 or -O3 AND Qrestrict are used. Remove Qrestrict and the bug goes away. Not surprising to me that O2 and O3 generate same .asm with such a simple test case. :)

--Wayne

[James_Burgess]

Just wondered if there was any progress on this bug? 

Thanks,

- James

[OTorg]

James Burgess wrote:
Just wondered if there was any progress on this bug? 

And with similar bug described at https://software.intel.com/en-us/forums/topic/532164 ?

[Shenghong_G_Intel]

James Burgess wrote:

Just wondered if there was any progress on this bug? 

Thanks,

- James

I did not get progress update from developer, I will ask to provide a estimation if possible. Thank you.

Shenghong

[Shenghong_G_Intel]

dj_alek wrote:

Quote:

jrb1 wrote:

Just wondered if there was any progress on this bug? 

And with similar bug described at https://software.intel.com/en-us/forums/topic/532164 ?

Hmm, looks like that issue is not replied by anyone? I have replied just now, let's continue there. :)

Thanks,

Shenghong

[Shenghong_G_Intel]

shenghong-geng (Intel) wrote:

Quote:

James Burgess wrote:

Just wondered if there was any progress on this bug? 

Thanks,

- James

I did not get progress update from developer, I will ask to provide a estimation if possible. Thank you.

Shenghong

Hello James,

Developer told me ”This bug is because the return value of strrchr() is not seen to alias its parameters (it actually does point to its parameter). The -Qrestrict causes this to happen." And he says he will take a look this week to fix it.

Thanks,

Shenghong