Compiler option -C in the 7.1/8.0 Compiler gives different results !?!

[tb1]

Hallo folks,

i have a program whos was compiled with the ifc 7.1 compiler which works fine, but the i compiled it with the new 8.0 compiler an it works too but the results are wrong ! But when i use the -C option the results are right, but the compiler does not give an error code or so !? The same thing occurs when i compiled the program VLUG3R, but now the 7.1 compliler gives wrong results and only with the -C option it works fine. The problem is that i suggested that when i used the -C option the compiler tell me if a runtime error occurs, but it doesn't ! Does everyone know exacly what the -C option doing or had anyone the same problems !?

Best regards !

Thorsten

[pedro_gonnet]

As far as I know, -C disables optimisations. Is the "wrong result" a numerical error? Does compiling with -O0 and without -C give the same result? If the problem is optimizations wrecking numerics, you should try compiling with -mp.

Cheers
Pedro

[ryofurue]

Hi,

I don't know whether the problem I had is the same as yours, but here you go.

My problem occurred with the 7.1 compiler. When I compiled part of my program without -C and other part with it, and linked them together, the result was wrong. Something like
$ ifc -c sub.o
$ ifc -C -c main.o
$ ifc main.o sub.o
If you use -C, you must use them for all the compilation units
linked together.

I reported this to Intel, who acknowledged that it is a problem but who said they don't have a plan to fix it for ifc 7.1 because the problem doesn't exist with ifort 8.0.

I haven't tested this with ifort 8.0.

Cheers,
Ryo
===============
-C implies -CA -CB -CS -CU -CV and the -CU part of it was causing the problem. Also, my problem was that you couldn't get the correct values of module variables in a module compiled without -C.

[tb1]

Hello !

Before of all, thanks for your help !

I had compiled the code with the -O0 and the -mp ,mp1 option and the it seems that the code works. so I assume that there ist a problem with the floation-point accuracy but i don't know and/or want to know what code parts this error provoke.

Best regards
Thorsten

[TimP]

I too would like more precise documentation of the switches -mp/-mp1/-fltconsistency. Maybe 50% of the customers may find it too technical, but at least it introduces the issues in an accessible place and lets people decide whether they really want an answer.

Some of the implications of -mp/-fltconsistency don't apply when you use an SSE2 code generation option, which I would recommend for cases where you have these concerns. Many applications used to be built with -mp1 -fp_port, in order to get predictable behavior, without the slowness of -mp. -fp_port, like g77 -ffloat-store, is not needed with SSE2 code generation.

According to my understanding, -mp1 requires the use of IEEE accurate instructions, where there is a choice between those and the use of the reciprocal approximations, followed by iterative improvement. By default, vectorized code uses the iterative method, as this improves throughput in many situations.

Using SSE2 code, -mp/-fltconsistency appear to be the closest you can come to the behavior which gnu compilers have without the use of -ffast-math. I have seen -mp prevent "vectorization" of sum and dot product reduction. -mp also stops some optimizations which break code which depends on the order of operations being as specified by parentheses.