Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28383 Discussions

2022.1.0 versus 2022.2.1 ia32 differences?

sarge130
Beginner
779 Views

I've been working on setting up a new system but have run into some issues when installing an old piece of software that is required to be compiled with 32-bit mode binaries. Unfortunately, while the software seemed to compile without issue, when I actually started using the software it had some runtime issue that I had never seen before.

After some time, I found that the problem seems to be with the recent version update of ifort. I've ran a parallel compilation with 2022.1.0 and 2022.2.1 and confirmed that the software works when compiled with the 2022.1.0 version and does not work when compiled with 2022.2.1. Both installations compiled without issue and I don't see any differences (such as compilation warnings) in the compilation logs other than timestamps.

The software itself is quite old and extensive so finding exactly what to modify would be quite difficult, but it's a mix of C and fortran code (the C compiler is gcc). Both the fortran and C compilations use the -m32 option in addition to using the 32-bit versions of the compilers. The software states that it failed on execvp when compiled with ifort 2022.2.1. I looked at the changelog but I don't see any specifics of what functional/security updates have been applied in https://www.intel.com/content/www/us/en/developer/articles/release-notes/oneapi-fortran-compiler-release-notes.html. I imagine that there is potentially some sort of compiler flag that I can use to bypass some check, but I'm not really sure what features have been implemented.

Is there a detailed list of the changes that were made between these versions?

0 Kudos
7 Replies
jimdempseyatthecove
Honored Contributor III
767 Views

It may help if you supply the error message(s)

 

execvp is a (linux) C call to execute a command line.

 

It may be that the newer ifort is missing (or miswritten) interface to this C runtime library routine.

If it is missing, you can add this interface declaration yourself.

 

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
767 Views

There is not, and from long experience writing release notes in the past, such a list would not be helpful to you. You're going to have to put in the effort to narrow down where in the code the behavior changes (I don't recogize "execvp" - that sounds like something in the application code) and try to identify the difference. It could be an error in your code that is surfacing in the newer compiler, or there could be a compiler bug that was introduced. 

0 Kudos
Ron_Green
Moderator
700 Views

If you can narrow down to the Fortran statement causing the error that would be helpful.  Compile and link with debug with -g -traceback options

If it is execvp, is your C calling this?  Or in the Fortran do you have any calls to SYSTEM ?

 

The OS distro and version would be helpful as well.

0 Kudos
sarge130
Beginner
685 Views

Thanks for the responses! Understood about the changelogs. I'm running on CentOS 9 virtual machine.

As far as I can tell, the software runs many layers of subprocesses, so I'm still digging around to see exactly what and where it's failing (I at least have a working version with the older version of ifort). I've re-compiled the source code with the -g and -traceback options but haven't run any debug tools yet (any recommendations for these specific flags?). The few lines of C code in the software that show this error (I think) are few lines:

 

    switch(chpid=vfork()){

      case -1:

        if(errno == ENOMEM) return -5;

        return -2;

      case 0:

        i=execvp(argv[0],argv);

        fprintf(stderr,"execvp failed on %s\n",argv[0]);

        fflush(stderr);

        _exit(-1);

...

I'm still working on finding where the last fortran call to that section of code is happening.

 

Thanks again.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
656 Views

Try:

      case 0:
#if defined(_DEBUG)
        // note, execvp requires 2nd argument be a list of char*'s
        // with the list terminated with a null pointer.
        fprintf(stderr,"calling execvp with:\n");
        for(i=0; argv[i]; ++i) {
            fprintf(stderr,"%s\n", argv[i]); }
        fflush(stderr);
#endif
        i=execvp(argv[0],argv);

        fprintf(stderr,"execvp failed on %s\n",argv[0]);

        fflush(stderr);

        _exit(-1);

Then examine what is being passed to execvp. See if some data is trashed or missing.

 

Jim Dempsey

0 Kudos
sarge130
Beginner
565 Views

Thanks Jim, I'm looking into this now. I see something odd when I run the tool with your suggested debugging method. I'm now getting a 'read: Resource temporarily unavailable' message that I wasn't before. I wonder if there is garbage at the end of the argv array? The relevant output text:

 

calling execvp with:
/opt/mk5/2022.12.01/bin/SLEND
0
34
1129
-1
AS
3
read: Resource temporarily unavailable
Program /opt/mk5/2022.12.01/bin/SLEND abnormally terminated

As a test, I moved the printing of the argv array to after the call to execvp and got the following:

execvp failed on /opt/mk5/2022.12.01/bin/SLEND                    
calling execvp with:
/opt/mk5/2022.12.01/bin/SLEND
0
34
1129
-1
AS
3
read: Resource temporarily unavailable
Program /opt/mk5/2022.12.01/bin/SLEND abnormally terminated 

 

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
560 Views

This appears to be a file/pipe/socket/handle/... I/O error due to a "resource temporarily unavailable".

Perform a google search for: read resource temporarily unavailable

This may be due conflicting access to a resource that the code was written under the assumption that it has exclusive access to the resource. 

Or, attempts to read a new file (created by the app or another process spawned by the app) but which the system's Anti-Virus program has temporarily opened (exclusively) for virus scanning. In this case, place the temporary files in a folder that is marked for "do not scan".

What I/O is being performed by SLEND?

 

Jim Dempsey

 

0 Kudos
Reply