topic Recompiling an old visual studio parallel studio project in Intel® oneAPI Math Kernel Library

Recompiling an old visual studio parallel studio project

Groostav — Sat, 01 Mar 2025 05:36:26 GMT

Hey guys,

I believe I have a defunct license Intel for Parallel Studio XE 2019 (?). I can no longer find my license in the intel software portal.

I need to compile some MKL dependent code again and I have no way of doing it. I tried installing the latest Intel OneAPI and using both ifx and ifort, but both crash unceremoniously, it seems like something to do with file order.

Do you have advice on the best path forward for me?

Who could I contact to re-activate my old Intel Parallel XE license, such that I can at least compile this source with my old toolchain?

Regards,

-Geoff

Re: Recompiling an old visual studio parallel studio project

Fengrui — Mon, 03 Mar 2025 17:42:07 GMT

Hi Geoff,

Thank you for posting in the oneMKL forum.

Could you please provide more details about the crash? A stack trace would be helpful. Also could you describe how the code looks like near the crash?

For the license, let's talk about it through email.

Thanks,

Fengrui

Re: Recompiling an old visual studio parallel studio project

Groostav — Tue, 04 Mar 2025 02:35:49 GMT

Well I just restarted the project and started adding things one-by-one.

When I added a vs-cpp project as a dependent to the fortran project I'm now getting
lld-link error: undefined symbol: __declspec(dllimport) GetUserNameA file:lld-link
which is a linker error in the llvm linker that I should've known Id be using. I'm not familiar enough with this hybrid toolchain that im now apparently using to know why im getting this error from this linker for this function.

Re: Recompiling an old visual studio parallel studio project

Groostav — Thu, 06 Mar 2025 02:41:07 GMT

Ok, now I've got something closer to an SSCCE: in visual studio i simply get "Compilation aborted (code 1)", with no extra messages. I'm guessing that ifx is outputting some information somewhere, I just need to track it down.

MODULE UTILS
ABSTRACT INTERFACE
    TYPE(C_PTR) FUNCTION evaluatorCallback(inputMat,matM,matN,chosenFunctions,length)&
    BIND(C)
    USE, INTRINSIC :: ISO_C_BINDING
    TYPE(C_PTR), INTENT(IN), VALUE :: inputMat, chosenFunctions
    INTEGER(C_INT), INTENT(IN), VALUE :: matM, matN, length
    END FUNCTION
END INTERFACE

SUBROUTINE evaluateStuff(evalCbk,resOut)
    PROCEDURE(evaluatorCallback), POINTER, INTENT(IN) :: evalCbk
    REAL*8,DIMENSION(:,:),ALLOCATABLE,INTENT(OUT) :: resOut

...

END SUBROUTINE
END MODULE

Seems to be the culprit. Any suggestions?

Re: Recompiling an old visual studio parallel studio project

Fengrui — Tue, 18 Mar 2025 23:25:52 GMT

It looks "contains" is missing before "subroutine evaluateStuff()".

Adding "contains" would make it compile.

Re: Recompiling an old visual studio parallel studio project

Groostav — Wed, 19 Mar 2025 01:26:17 GMT

I've omitted some things for brevity, apologies.

But my problem is not that it doesn't compile per se, if I had a compiler error I would be quite happy.

My problem is that ifx crashes unceremoniously with no output at all.

I must confess, I've said some unkind things about the bespoke nature of the go-lang toolchain, arguing that the community would be better served by writing a front-end to llvm. Now that I'm working with exactly such a front end as ifx I'm not impressed.