I get EXCEPTION_FLT_STACK_CHECK with Composer 2013 update 1

[Mordy_S_]

I have a compliacted C and C++ code with heavy mathematics calculations. I use intel C++ - the latest update to compile. I use optimizatons and the application does not give the expected answer. After a long time I managed to reduce the problem to getting EXCEPTION_FLT_STACK_CHECK
0xc0000092. If I compile without optimization - The program work as expected.

It's a single threaded code on Winxp64 (the application is 32-bit).

MSVC 2010 gives the same results with Debug or Release builds. (I mean Good=Expected results)

Can someone help me where to look? Currently I suspect a compiler bug - since I have no asmsembly code of my own, Only compiler-generated code. I looked at the assembler and it's SSE/x87 mixed code.

I'm looking for directions to look for. Since I'm on trial version (of the intel compiler) I don't have much time for investigations.

I will try to use /Qfp-stack-check tommorow to see if i can find something wrong with my code.

mordy.

[SergeyKostrov]

>>...Currently I suspect a compiler bug... This is a question Intel C++ software engineers will ask you: Could you provide a test-case to reproduce it? >>...MSVC 2010 gives the same results with Debug or Release builds... Did you mean you have the same exception EXCEPTION_FLT_STACK_CHECK when you execute the same piece of codes? >>... I will try to use /Qfp-stack-check... EXCEPTION_FLT_STACK_CHECK = STATUS_FLOAT_STACK_CHECK and this is a Floating-point Stack Check exception. Do you use any pieces of heavily recursive codes with floating-point calculations?

[Georg_Z_Intel]

Hello Mordy, as Sergey pointed out, w/o a reproducer we're less likely able to confirm which kind of problem this is. You might be interested in the following paper regarding consistent FP results with our compilers (different FP results are kind of expected with default options!): http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler Best regards, Georg Zitzlsberger

[SergeyKostrov]

It possible ( still not proven ) that the problem could be related to 80x87 stack overflow ( FPE_STACKFAULT ) or, less likely, to 80x87 arithmetic overflow ( FPE_OVERFLOW ). Please try to provide more technical details.

[Mordy_S_]

News - I found what it was. I didn't have time to create a reproduce but I saw the and avoided the problem. I have a function that returned a double via ST(0). the function pushed the result and most places poped it. One function didn't - so the stack got overflawed. Since I don't write assembler code - the faulty assembler code is the compiler failure so It is a bug. It was a function A that called a function B that called function C from inside an if. function B does not need the return value of C (C returns more results via pointers alst). A,B and C are C function and inlined and optimized by the compiler and after C returns B didn't pop the value from C ( perhaps the call inside an if confused the compiler? B didn't use the Return Value of C but someone still needs to pop the value. After I changed B to return what ever C returns or 0.0 (if the If was false) it worked and the Stack was balanced again and every thins is amazing the results are excactly (numerically as microsoft and as the debug version reported). So, It's an optimizer bug - since compile without optimization gave correct results. The code mixed sse2 and fpu (I guess since i had sin, cos and more...) It was with the last update of the compiler. The main results that it take 35% of the performance merely by compiling the code with your compiler - the competitor was VS2010 - I will try VS 2012 when we will upgrade to Windows 7 - IT are not ready yet after 3-4 years of testing :-( Thanks, mordy.

[SergeyKostrov]

>>... >>I have a function that returned a double via ST(0). the function pushed the result and most places poped it. >>One function didn't ... You've just confirmed that you have a coding error in your codes. Please explain how a C++ compiler ( any! ) could verify that in some function a value in ST(0) register wasn't poped up because a software developer forgot to add that line of code? Once again, you need to provide a proof that there is some error / bug in Intel C++ compiler. That is, a piece of C/C++ codes or two examples ( right that pops ST(0) and wrong that doesn't pop ST(0) ) in assembler from a disassembler window.

[Mordy_S_]

I'll try to explain. That C function is written in C. My code is C. it returns a double and change an argument that is passed by pointer. The compiler generates the assembler that pushes the value to the stack. No compalins here. The same compiler also generates the assembler code for the other functions. In one of those function I (as the C programmer) don't look at the return value - this is allowed by the language (Again - C not assembler). But the compiler must generate assembly to pop the answer even if the C code don't need it. Thats where the floating point stack gets unbalanced. Since the compiler in that function (called B in prev comment) didn't generate the correct assemby code. I will try to create a small example - but I don't have much time to dedicate and the problem might arose only with many variables and calculations and inlines etc. Again - I don't write assembly so I fail to see how it can be my code fault. thanks for commenting. mordy.

[SergeyKostrov]

Hi Mordy, >>...I will try to create a small example - but I don't have much time to dedicate and the problem might arose only with many variables and >>calculations and inlines etc. If you like & love Intel C++ compiler please try to find some time and nobody is asking to do this by 4am tomorrow morning :) . Your detailed report with C++ compiler options (!) will help to understand what is wrong. >>Again - I don't write assembly so I fail to see how it can be my code fault. I understood this. Everybody will be glad to hearing from you! Thanks a lot for your time. Best regards, Sergey

[TimP]

In my own experience, such errors with floating point stack were produced by incorrect inline asm (which might come from use of mathinline.h provided by some 32-bit linux distros). The distros tended to substitute their own mathinline.h rather than one from upstream glibc. icc itself should not use the mathinline.h without explicit specification by the programmer, but it might come in with a mixture of gcc and icc, particularly (for 32-bit gcc) if x87 compilation is specified.

[TimP]

In my own experience, such errors with floating point stack were produced by incorrect inline asm (which might come from use of mathinline.h provided by some 32-bit linux distros). The distros tended to substitute their own mathinline.h rather than one from upstream glibc. icc itself should not use the mathinline.h without explicit specification by the programmer, but it might come in with a mixture of gcc and icc, particularly (for 32-bit gcc) if x87 compilation is specified.

[Georg_Z_Intel]

Hello Mordy, a reproducer would quickly put any speculation to an end. A small check you can do: Build with /Od (no optimizations) If the problem vanishes it's high likely a compiler bug. If it's still there it's mostly related to the environment (e.g. different headers pulled in). Best regards, Georg Zitzlsberger

[SergeyKostrov]

>>...Build with /Od (no optimizations) >>If the problem vanishes it's high likely a compiler bug. This is a statement from the 1st post: '...If I compile without optimization - The program work as expected...'. It is still not clear what optimizations were used which caused the exception.

[SergeyKostrov]

>>...In my own experience, such errors with floating point stack were produced by incorrect inline asm (which might come from use of >>mathinline.h provided by some 32-bit linux distros)... How is it possible? The exception happens on a 64-bit WIndows platform in a 32-bit application.

[TimP]

"The exception happens on a 64-bit Windows platform in a 32-bit application." That's important background information. A 64-bit Windows application would not normally support inline ASM or x87 code. Even with a 32-bit application, if you set /arch:SSE2 (the default for recent ICL versions), you should not be generating x87 code (although the earlier suggestion of /Od might produce x87 by default). This points up the importance of being more specific about the compilers and build options in use.

[Mordy_S_]

As Sergey noticed - without optimization - every thing works. With /O3 or /O2 it's not. TImP : I think I tried various arch SSE3 and SSE2 - The compiler emit x87 mixed with SSE in the same function. P.S.: I don't do inline assembly. I don't write assembly myself at all. I just read the produced code. I will try to install it at home and try to reproduce soon. The best hints I have is that the function that didn't poped the stack was calling the internal function inside an if statement AND not using the return value. There were lots of variables mixed with sin/cos (perhaps perhaps thats why the FPU was used?) Thanks, mordy.

[TimP]

Intel compilers will use simd library functions to support sin/cos when simd architecture switch is set, including the default /arch:SSE2, with the possible exception of /Od. Other compilers may use the x87 intrinsics, not having available a simd library.