/Qinit:arrays caused access violation

[Andrew_Smith]

I tried to replicate in a small example but failed. It appears on entry to any routine with a local fixed size array of double precision type.

Here is assembler leading up to error from my 64 bit debug compile with XE 16.0:

000007FEECC174F8  jl          000007FEECC17488  
000007FEECC174FA  jmp         000007FEECC17468  
000007FEECC174FF  mov         rax,qword ptr [rsp+50h]  
000007FEECC17504  inc         r9d  
000007FEECC17507  mov         qword ptr [rdi+r8*8],rax  

error occures on last line and shows rdi = 0, r8 = 0, rax = a large number

Compiler flags:

/nologo /debug:full /MP /Od /QxHost /I"Removed for confidentiality" /DIntelQuad /Dx64 /DenhancedChecking /DoutputModel /Qopenmp /standard-semantics /debug-parameters:all /warn:declarations /warn:unused /Qinit:snan /Qinit:arrays /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /libs:dll /threads /dbglibs /Qmkl:parallel /c

[mecej4]

I think that we need to see more context, in Fortran.

If %rdi contains an uninitialized/NULL pointer to an array of 8-byte integers, say, "x", and %r8 is an index into that array, say, "i", then the assembly code that you showed could result from executing the Fortran statement

     x(i) = integer expression

Nothing in the assembly code indicates that double precision variables are involved at all.

[Lorri_M_Intel]

Yes please, I'd like to see actual Fortran code.  Doesn't have to be runnable, and of course, you can remove any confidential markers.

 I'll just be looking at what we do with <that> code and see if there's some sort of interaction with the various command line switches you have.

Or, you can submit it to Kevin through a private message or through the support channel for true confidentiality.

          thanks -

                             --Lorri

[JVanB]

Are you sure you're posting to the right forum? RDI would be the address of the first argument in Linux/MacOS, but it's callee-save in Windows so it would have to get set earlier somewhere in the routine, before the code that jumps to 000007FEECC174FF.

[mecej4]

The command line as well as the assembler syntax tell us that O.P. is running on Win-64. Sorry if I contributed to the confusion by using '%' as a prefix to indicate register names.