# weird behaviour of Listable fortran Librarylink function: different result each evaluation

I am working with fotran librarylink function currently. In this post, I will show some weird result of Listable fortran librarylink generated by intel compiler under windows (I tried gcc on linux the result is normal). The fortran librarylink function is the same as my this post.

I upload a fixed version zip downlad here, which I have packed everything.

I will first show how to create the fortran librarylink using intel compiler.

First, in command line, we enter intel compiler intel64 mode (I am using 64bit win), and compile the fortran source to object file

ifort /c /fast iterateG-librarylink.f90


Needs["CCompilerDriver"];
CCompilerDriver\$CCompiler = {"Compiler" ->
CCompilerDriverIntelCompilerIntelCompiler,
"CompilerInstallation" ->
"c:\\Program Files \
(x86)\\IntelSWTools\\compilers_and_libraries_2016.1.146\\windows\\",
"CompileOptions" -> "/fast"};

CreateLibrary[{FileNameJoin[{NotebookDirectory[],
"iterateG-mma-intel.c"}],
FileNameJoin[{NotebookDirectory[],
"TargetDirectory" -> NotebookDirectory[],
"CompileOptions" -> "/fast"]


funcfortran =
FileNameJoin[{NotebookDirectory[], "iterateG_C.dll"}],
"iterateG_C", {Real, Real, Real, Real, Real, Real, Real, Real,
Real}, Real]


testing

done a sample calculation

funcfortran[1, 1, 1, 1, 1, 1, 1, 1, 1]

0.154666


Now we want to make the librarylink function Listable as Listable compile function, so it can automatically thread parallelized.

We can do this by wrapping the librarylink in a Listable compiled function setting and make "InlineCompiledFunctions" -> True

funcfortranListable =
Compile[{a, s, d, f, g, h, j, k, l},
funcfortran[a, s, d, f, g, h, j, k, l], CompilationTarget -> "C",
Parallelization -> True, RuntimeAttributes -> {Listable},
CompilationOptions -> {"InlineCompiledFunctions" -> True,
"InlineExternalDefinitions" -> True}]


halirutan has provided another way and deep insight on this here. I have confirmed this method works on many librarylink function including C, C++, also fortran. But it fails on this one !

Let us see

funcfortranListable[1, 1, 1, 1, 1, 1, 1, 1, ConstantArray[1, 10]]


it should give

{0.154666, 0.155605, 0.154597, 0.154666, 0.154666}


the weird thing is, it can possibly give right answer on the first run, but if you run it several times, it will get all kinds of answers, for example

{0.134586, 0.137318, 0.154822, 0.146941, 0.154666}


And you can run and run, weirdly, sometimes it return to the right answer. At first I thought there is a period, but there is not.

The librarylink generated by linux seems not suffered by this problem.

Also, I found the "bug" line. I found if I delete

call twobytwolinearsolve(wminush00,tmp)
call twobytwolinearsolve(wminush00,tmpdagger)


in my fortran source, the Listable result is conform.

What is wrong here?

• The /fast switch for Intel Fortran applies very extreme optimizations that can result in miscompilation of programs. It also does not guarantee better performance, so I would generally consider the use of this switch somewhat experimental, as it may not work properly or be effective in different cases. GCC does not do this in the same way, even with -Ofast. Could you try /O1 instead and see if the problem remains? – Oleksandr R. Feb 6 '16 at 18:27
• @OleksandrR. Hi,OleksandrR. Thank you for comment. It seems not a problem of optimization. /O1 also gives weird result. – matheorem Feb 6 '16 at 23:45
• You say that you "tried gcc on linux the result is normal". Doesn't that suggest that the problem is likely to be in the interaction of the Intel compiler with your FORTRAN code, rather than within Mathematica? – MarcoB Feb 8 '16 at 6:43
• @MarcoB But the .dll intel compiler generate gives correct answer when it is not Listable. So I think it is due to mma. mma's thread parallelization make a correct dll gives wrong answer – matheorem Feb 8 '16 at 6:46