signed 32 bit integer warning

[rahzan]

Re CVF6.6b

After reporting this warning on

Warning: Case selection values must fit within a signed 32 bit integer. Value truncated.

one the line

case(STATUS_STACK_OVERFLOW)

where in dfwinty

STATUS_STACK_OVERFLOW = (#C00000FD)

Jugoslav indicated that Ibestspoonfeed the signed decimal value of the constant in DFWINTY and recompile it. So the project compiles and works fine for the most part.

However, on some real stack overflows (eg. write a big array), I get runtime error code #C00000FD which is the original entry in dfwinty.f90 for stack-overflow.

So this has become a catch22. If I use the original value I can't compile if I don't use the original value I get a runtime error.

Any ideas?

Thanks,

Tim

[Steven_L_Intel1]

I don't understand. The value should be the same either way.

This bug is fixed in IVF.

[g_f_thomas]

In CVF/IVF,

STATUS_STACK_OVERFLOW = (#C00000FD),

just as in VC++. In all cases you can

RaiseException(STATUS_STACK_OVERFLOW,...)

and handle it in CVF/IVF via VC++'s SEH. So what was the 'bug' corrected in IVF or was that related to Case Select and why on earth would one want to

Case(STATUS_STACK_OVERFLOW)

in Fortran anyways?

Just wondering,
Gerry T.

[Steven_L_Intel1]

The bug was that if a #-form hex constant was used in a CASE and the high bit was set, the compiler treated it as if it were a signed value that would then overflow, rather than a "just the bits" value. The semantics of the # form are a bit strange, due to Microsoft, and not a direct map onto the standard Z'xxxx' form.

[garyscott]

That's the only MS extension that I still use. I really like that one. What do you find about the rules that are strange? I haven't found anything strange or unexpected so far.

[Steven_L_Intel1]

The # syntax is a signed integer syntax, just like normal integer constants (eg. +124).You can even specify a sign! So on the face of it, #D00000003, for example, wouldbe a positive integer that is too large for representing in 32-bits. Compare this with the Z'xxx' syntax which does not have an inherent data type - the type is dependent on the context.

So normally you would expect the compiler to be right to complain about the overflow. But Microsoft throws a curve and says, "However, for numbers with a radix other than 10, the compiler reads out of range numbers up to 2**32. [The text actually says "232", but they mean 2**32.] They are interpreted as negative numbers with the corresponding internal representation."

So Microsoft plays it both ways, with a funny exception rule that we missed in our implementation.

[g_f_thomas]

Thanks for sharing this Steve. It's reassuring that the Intel compiler folks are on their toes, the main reason we put our trust in them. Keep it up!

Ciao,
Gery T.

[Steven_L_Intel1]

You're welcome. Oh, did you realize that the # syntax allows other bases? For example, +8#17171717 or 36#2DM8F ? The base can be from 2-36 - if omitted, 16 is assumed.

[garyscott]

Interesting. I guess I've never tried to stuff more bits into a particular data type than I thought would fit. I think I would prefer an overflow warning in that case. One of the reasons I like the syntax though is because it supports different bases (other than BOZ). With BOZ, you'd quickly use up all the letters of the alphabet (not to mention rote memorization problems for us old guys).