This question already has an answer here:
Compiling issue with ifort composer_xe_2015.3.187
(1 answer)
Closed 7 years ago.
I am using a numerical model that is sensitive to the precision of numerics. With my old ifort compiler I successfully used the Fortran flags
"fp-model precise"
I recently installed intel compiler composer_xe_2015.3.187. It does not recognize the Fortran flag
"fp-model precise".
This is the exact error that I get
f95: error: precise: No such file or directory
f95: error: unrecognized command line option ‘-fp-model’
I am afraid if I would be sacrificing my efficiency in lieu of the new compiler or is the new one inherently able to maintain precision.
The compiler you are invoking with the name f95 is not Intel Fortran. Based on the error message, I'm guessing it is actually the GNU Fortran compiler, but you can check for sure by running f95 -v to see what the compiler identifies itself as.
Intel Fortran 15 still supports the option -fp-model precise.
Before invoking ifort, you need to setup its environment, e.g.
source /path/to/intel/bin/ifortvars.sh intel64
for the 64 bit compiler. You can then invoke the compiler as ifort.
Related
I am trying to migrate a .FOR file (for practice purposes) from ifort to gfortran. This file compiles in my Intel Visual Fortran solution with no issues. However when I compile it in gfortran using the following command:
gfortran -ffree-form -ffree-line-length-200 -Dinternal_debug -c MyFile.FOR -o MyFile.o
I get the following error message:
MyFile.FOR:4561:22:
102 format(A, I)
1
Error: Nonnegative width required in format string at (1)
Does ifort simply not require there to be a format width or are there additional ifort options that enable relaxing this requirement? How come the file runs smoothly in ifort but not in gfortran?
Your observation is correct, I have encountered this myself before. Intel Fortran does not enforce this requirement while gfortran does. The field width is actually required by the Fortran standard. I am not aware of any compiler option that could change this behaviour. The only option I am aware of is to fix the code to make it standard compliant.
How to do it can be found in Error: Nonnegative width required in format string at (1) . Note that the g0 that you asked about is not a compiler option to accept I. It is a different format descriptor to put into the code instead of I.
I am attempting to compile a C++ code using gcc/5.3 on Scientific Linux release 6.7. I keep getting the following errors whenever I run my Makefile though:
/tmp/ccjZqIED.s: Assembler messages:
/tmp/ccjZqIED.s:768: Error: no such instruction: `shlx %rax,%rdx,%rdx'
/tmp/ccjZqIED.s:1067: Error: no such instruction: `shlx %rax,%rdx,%rdx'
/tmp/ccjZqIED.s: Assembler messages:
/tmp/ccjZqIED.s:6229: Error: no such instruction: `mulx %r10,%rcx,%rbx'
/tmp/ccjZqIED.s:6248: Error: no such instruction: `mulx %r13,%rcx,%rbx'
/tmp/ccjZqIED.s:7109: Error: no such instruction: `mulx %r10,%rcx,%rbx'
/tmp/ccjZqIED.s:7128: Error: no such instruction: `mulx %r13,%rcx,%rbx'
I've attmpted to follow the advice from this question with no change to my output:
Compile errors with Assembler messages
My compiler options are currently:
CXXFLAGS = -g -Wall -O0 -pg -std=c++11
Does anyone have any idea what could be causing this?
This means that GCC is outputting an instruction that your assembler doesn't support. Either that's coming from inline asm in the source code, or that shouldn't happen, and suggests that you have compiled GCC on a different machine with a newer assembler, then copied it to another machine where it doesn't work properly.
Assuming those instructions aren't used explicitly in an asm statement you should be able to tell GCC not to emit those instructions with a suitable flag such as -mno-avx (or whatever flag is appropriate to disable use of those particular instructions).
#jonathan-wakely's answer is correct in that the assembler, which your compiler invokes, does not understand the assembly code, which your compiler generates.
As to why that happens, there are multiple possibilities:
You installed the newer compiler by hand without also updating your assembler
Your compiler generates 64-bit instructions, but assembler is limited to 32-bit ones for some reason
Disabling AVX (-mno-avx) is unlikely to help, because it is not explicitly requested either -- there is no -march in the quoted CXXFLAGS. If it did help, then you did not show us all of the compiler flags -- it would've been best, if you simply included the entire compiler command-line.
If my suspicion is correct in 1. above, then you should build and/or install the latest binutils package, which will provide as aware of AVX instructions, among other things. You would then need to rebuild the compiler with the --with-as=/path/to/the/updated/as flag passed to configure.
If your Linux installation is 32-bit only (suspicion 2.), then you should not be generating 64-bit binaries at all. It is possible, but not trivial...
Do post the output of uname -a and your entire compiler command-line leading to the above error-messages.
I’m building a Cocos2d-x game for Android on a Mac, using Android NDK, and I get many warnings like this when compiling the C++ part:
/usr/include/module.map:1662:22: warning: unknown attribute 'extern_c' [-Wignored-attributes]
Is it dangerous? How can I fix it?
I'm guessing that extern_c is a compiler directive for the module map saying it is referencing functions from C++ that were written in the C language (different call frame structure).
The LLVM portion of the CLANG compiler is probably having a version mismatch.
http://clang.llvm.org/docs/Modules.html#module-maps
Try a command line $ clang -v
You may have to verify the compiler library version
xcode->preferences->locations->command line tools.
Ultimately you will want to clear this up so your stack frames match the arguments and your not referencing a C language function.
This is simple fortran90 program testing MPI.
I would like to compile it on MS Windows platform using MinGW64 Fortran and the known MS-MPI package.
However, it's not working due to missing "mpi.mod". When I replace the use mpi with include 'mpif.h', it's giving other errors (below).
Any help, please ? Does the MS-MPI suite cooperate with the MinGW gfortran ?
PS1:
Working with MS-MPI and MinGW gfortran is not an easy task, https://social.microsoft.com/Forums/en-US/245dcda4-7699-494f-bbe1-b76eb19e53da/linking-msmpi-with-mingw-gfortran?forum=windowshpcmpi
C:\Users\milias\Documents\Dirac\software\autocmake-devel\ms-mpi>gfortran -fno- range-check -c example.f90
mpif.h:344.38:
Included at example.f90:4:
PARAMETER (MPI_AINT=z'4c00043b')
1
Error: PARAMETER attribute of 'mpi_aint' conflicts with PARAMETER attribute at (1)
mpif.h:359.35:
Included at example.f90:4:
PARAMETER (MPI_ADDRESS_KIND=INT_PTR_KIND())
1
Error: Function 'int_ptr_kind' in initialization expression at (1) must be an intrinsic function
solved here, I apologize for the duplicate.
https://github.com/scisoft/autocmake/issues/85#issue-102874399
I am trying to compile some Fortran code that, according to the documentation, is known to compile with "Intel Fortran Compiler 11." However, when I try to compile the code using the version of ifort that comes with Intel® Fortran Composer XE 2013 for OS X (here: http://software.intel.com/en-us/fortran-compilers), I get a number of errors. I suspect that I'm either 1) using a compiler that's incompatible with the exact dialect of Fortran used and/or 2) failing to include some necessary libraries.
I'm not a Fortran programmer, so I'm hoping that someone with more experience will be able to glance at the code and recognize if it's just a simple matter of using a different compiler, setting some compiler options, including some specific libraries, or if I'm missing something else altogether.
The full source code can be found just above the Contents here: http://baydeltaoffice.water.ca.gov/modeling/deltamodeling/models/dsm2/dsm2.cfm
To start with, I'm just trying to compile groups.f in /DSM2_v8_0_6_src/dsm2_v8_0/src/common (which requires that a few other modules be compiled first), but the eventual goal is to compile DSM2_v8_0_6_src/dsm2_v8_0/src/ptm/native/fixedData.f and all of its dependencies.
The syntax I'm using follows this basic pattern:
ifort -c DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
To get a sense of the types of errors I'm encountering, here are a couple of types that occur repeatedly:
groups.f(225): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of:
( * ) :: , . % + - [ : . ** / // .LT. < .LE. <= .EQ. == ...
write(unit_error,*)"Error in matching text pattern:",trim(pattern)
---------------------------------------------------------------------^
groups.f(265): error #5120: Unterminated character constant
& "Error in pattern matching. Implementation count does not equal count in NumberMatches"
------^
Could be F77 or F90 depending on how you have done the formatting. Stack oveflow fomatting requires 4 spaces to start the code. On the line 225, is it indented by 6 or not indented at all. If it is indented by 6 and line 265 is indented by 5 then it is F77.
The other question is whether leading spaces have been stripped when moving from one machine to another. If that is the case then they need to be re-inserted.
On the first line with an error, check the line terminations. All lines should end with either CR LF or just LF. If there is a mix, the compiler will throw a wobbly.
If it is F77, try renaming the files with a .f extension to a .for extension. ifort will then definitely pick them up as f77.
In case this might help point somebody with a similar problem in the right direction, after doing some digging I was able to determine that the code was originally compiled using Visual Studio with the compiler option FixedFormLineLength="fixedLength132". So, using ifort from the command line, I can compile using the following basic pattern (omitting all of the include paths, etc., for clarity):
ifort -c -132 DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
As for the dialect, I later heard from the provider that the code was mostly written in Fortran 77, with some parts later revised to Fortran 90.