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

Sorry for this

JVanB
Valued Contributor II
808 Views

It's a mess. Does it compile?

EDIT: Modified lesson01.f90 so it passes compile-time checks by ifort .

0 Kudos
4 Replies
jimdempseyatthecove
Honored Contributor III
808 Views

No

1>------ Build started: Project: lesson01, Configuration: Debug Win32 ------
1>Compiling with Intel(R) Visual Fortran Compiler 17.0.0.109 [IA-32]...
1>lesson01.f90
1>C:\test\lesson01\lesson01\lesson01.f90(60): remark #6536: All symbols from this module are already visible due to another USE; the ONLY clause will have no effect. Rename clauses, if any, will be honored.   [ISO_C_BINDING]
1>C:\test\lesson01\lesson01\lesson01.f90(994): remark #6536: All symbols from this module are already visible due to another USE; the ONLY clause will have no effect. Rename clauses, if any, will be honored.   [ISO_C_BINDING]
1>C:\test\lesson01\lesson01\lesson01.f90(2001): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [MODES]
1>C:\test\lesson01\lesson01\lesson01.f90(2120): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [PROCS]
1>C:\test\lesson01\lesson01\lesson01.f90(2133): error #6404: This name does not have a type, and must have an explicit type.   [CREATEGLWINDOW]
1>C:\test\lesson01\lesson01\lesson01.f90(2139): error #6404: This name does not have a type, and must have an explicit type.   [GLWIN]
1>C:\test\lesson01\lesson01\lesson01.f90(2139): error #6460: This is not a field name that is defined in the encompassing structure.   [DPY]
1>C:\test\lesson01\lesson01\lesson01.f90(2161): error #6460: This is not a field name that is defined in the encompassing structure.   [WIDTH]
1>C:\test\lesson01\lesson01\lesson01.f90(2162): error #6460: This is not a field name that is defined in the encompassing structure.   [HEIGHT]
1>C:\test\lesson01\lesson01\lesson01.f90(2184): error #6460: This is not a field name that is defined in the encompassing structure.   [FS]
1>C:\test\lesson01\lesson01\lesson01.f90(2119): error #6581: Unresolved rename.   [IGNORE]
1>compilation aborted for C:\test\lesson01\lesson01\lesson01.f90 (code 1)
1>
1>Build log written to  "file://C:\test\lesson01\lesson01\Debug\BuildLog.htm"
1>lesson01 - 10 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

These are rather sophomoric issues, much beneath your skill level.

Module procs faild to compile due to:

1>C:\test\lesson01\lesson01\lesson01.f90(2001): error #6634: The shape matching rules of actual arguments and dummy arguments have been violated. [MODES]
result4 = XFree(modes)


The routine where the error occurs has

               type(XF86VidModeModeInfo), pointer :: pmode
               call C_F_POINTER(modes(bestMode),pmode)
...
               result4 = XFree(modes)

XFree is expecting a C_PTR. you are passing in an array of C_PTR's.

You likely need to "cast" the LOC(modes) to C_PTR, though you will have to look closer at this.

Jim Dempsey

0 Kudos
JVanB
Valued Contributor II
808 Views

Thanks for the feedback, Jim. That was very constructive. The first two remarks are just ifort being bitchy and can be fixed via the command-line switch /Qdiag-disable:6536 although I suppose it would read -diag-disable:6536 in Linux. The next one is real, though, and I'm surprised that gfortran didn't smoke it out. Indeed I had passed the wrong thing to XFree: it should have been cmodes, which in turn had to be pulled out to procedure scope to be available at this point.

The next 7 errors are compound errors from the above. The last error is there because ifort doesn't seem to have implemented EVENT_TYPE in ISO_FORTRAN_ENV yet, while gfortran has (although they don't seem to have documented it as yet, but see https://gcc.gnu.org/onlinedocs/gfortran/EVENT_005fQUERY.html ). I fixed this up by eliminating the offending line of code and renaming the event_type variable so it doesn't conflict in gfortran.

At this point ifort for Windows compiles it but of course the XWindows and xf86 stuff go as unsatisfied external references on that platform. One thing I did notice was that the setup_handler function was also marked as unsatisfied external reference because I neglected to mark it as PUBLIC in module PROCS. I don't know how this worked in gfortran. Fixed that too, and uploaded a new version that at least compiles in ifort for Windows. There is a bug in the forum software that doesn't allow an editor to replace a *.f90 file so I had to delete the old file and create a new link. The link doesn't seem to have propagated completely as of this writing so you may have to log in to be able to download it unless you wait a little while.

If the program freezes, it can be killed by switching to the Terminal window from which you launched it and hitting <CTRL>-C. If it doesn't freeze, it can be killed by putting the focus on the graphics window and hitting the <F1> key. Does this compile to something that runs at this point? The command line that works in gfortran is

gfortran-6 -Wall lesson01.f90 -lGL -lX11 -lXxf86vm -lGLU -olesson01

EDIT: by the time I finished this post, propagation of the link to the new file was complete.

 

0 Kudos
Steve_Lionel
Honored Contributor III
808 Views

Events are a F2015 feature that ifort doesn't support yet.

0 Kudos
jimdempseyatthecove
Honored Contributor III
808 Views

When you post a file, and then if someone comments on the file in the Forum, it is good form .NOT. to modify the original code (as originally named). Please, create a new file (name), such as: lesson01_rev1.f90 (you can locally keep it as-was named). If you should replace the original code, then subsequent readers of this forum can not make sense out of the posts referencing things no longer present in the uploaded file.

Jim Dempsey

0 Kudos
Reply