Problem with compilation in ifort 2017 when /fcc is used

[Marco_M_3]

Hi,

I cannot provide the code cause it's several modules inter- dependents. The codes compiles fine and works on windows, however, I need a conditional compilation when OMP is not used for how I wrote some of my functions.

I know that Fortran doesn't have a native conditional compilation, but I was reading on the forum that it was possible to use the flag /fcc in visual studio to allow the use of #ifdef _OPENMP.

one of the modules  (and other 3) that starts with

module LL_Bloch  !
integer param_FePt   !Default = 1 for normal 2 for LLL    

real(8), allocatable:: para_table(:),perp_table(:),tanh_part(:),equil_part(:)
real(8),parameter:: epsilon=0.999
real(8) :: n_FePt,k_FePt,Spin_corrector1, Spin_corrector2
    contains 

gives me this error on line

Error    175     error #5078: Unrecognized token '?' skipped    C:\Users\menar_000\Source\Repos\AFMFM_plus_AOS2\NewVoronoi/LL_Bloch.f90    1    
 

The error is repeated 3 times and point to the first line. I checked for all possible signs like ' or ? or # in the file, but I cannot find any. When the /fcc flag is removed the code compiles and run without any issue.

This are the option selected

/nologo /debug:full /Od /Qparallel /fpp /Qopenmp /warn:all /debug-parameters:all /fpe:0 /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc120.pdb" /traceback /check:pointer /check:bounds /libs:static /threads /dbglibs /c

I'm using windows10 and Visual Studio 2013 (the code requires CUDA7.5  for some libraries and doesn't work on newer versions cause it was used some deprecated functions that has been removed), ifort compiler 17.

If the error is too difficult to diagnose, is there any other way to allow conditional compilation in fortran for OPENMP. Thank you,

Marco

[Juergen_R_R]

Wrong forum, this is the one for Linux and MACOSX.

[Steve_Lionel]

True, wrong forum, but the problem is likely generic. You meant /fpp not /fcc.

Try adding /Qsave-temps and look at the temporary file created by fpp. Open it in a binary editor (Visual Studio can do this) and look for non-printing characters.

[Marco_M_3]

Sorry you are right it was a typo (see the /fpp flat) anyway, solved the problem. In case someone else had the same issue (I saw in these forum a similar question but no response, a lot of people were suggesting /fpp or saying the conditional compilation doesn't work).

With Intel compiler 17 (and Gfortran), you can do conditional compilation for OMP this way:

 

!DIR$ IF DEFINED(_OPENMP)
                     <openmp code>
!DIR$ ELSE
                     <non openmp code>
!DIR$ END IF

the only flag you need is -qopenmp (on linux ) or /Qopenmp (on windows). If you are interested, the code seems to run the non omp code, at least on windows, even if you compile with  -qopenmp-stubs or /Qopenmp-stubs (I wasn't sure what this flag does, cause at least on Visual studio, if you have use omp_lib, the code compile and recognize commands like omp_get_wtime() or omp_get_num_threads() even if you don't have that flag, and compile the code sequentially ignoring the omp directives)

Hope it might help other people with the same issue :)

[Steve_Lionel]

I don't understand what triggered the error. You seem to be saying you "solved" it by not using fpp at all.

[Marco_M_3]

I was going to use fcc to allow conditional compilation. I found another way. So the problem of conditional compilation is solved. What is the problem of fcc, since the compilator is not giving any clear information or the correct line, I don't think it's worth spend the time looking into. I check the two files line by line with different text editor and there is no weird symbol. The '?' is not particularly helpful. In the past I already had to fight with an internal error of the intel compiler on centos while the -Ox with x>1 (I discovered it was due to the unrolled factor set to be to high, but the same error was not triggered on windows). It took me several weeks to find due to the unhelpfulness of the message, I don't think it's important to look into it, since no other error is triggered and the results are consistent with the previous version of the code.

I think using the directive of fortran is a better approach and might help other people with the same issue, that's why I said solved.