Reference Number : dpd200045548


Version : 10.1, 11.0, 11.1


Product : Intel Fortran Compiler


Operating System : Mac OS X


Problem Description :  If a library built with ar contains objects with Fortran module data but no executable functions, the symbols corresponding to the module data may not be resolved when an object referencing them is linked against the library. The symbols are present: the compiler generates a common symbol (C), e.g.
0000000000000050 C _module_modname_mp_varname_
but the linker does not realize that it needs to link the corresponding object.


Resolution Status : This issue may be fixed in a future version of the compiler.
It may be worked around by adding -fno-common to the compiler (not linker) options. This will cause symbols such as the above to be placed in the text section instead of the common section, and the linker will then pick them up.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200138527


Version : 11.1


Product : Intel® Fortran Compiler


Operating System : All

Problem Description : If a derived type is declared containing a UNION, and the type is a SEQUENCE type or is interoperable (BIND(C)), and the UNION contains a misaligned field, the compiler incorrectly adds padding bytes before each misaligned field.

UNION is an extension to the Fortran standard, supported by Intel Fortran, that allows the declaration of overlapping sets of derived type components. A SEQUENCE type is a derived type containing the SEQUENCE keyword. The Fortran standard specifies that components of a SEQUENCE type may not be rearranged by the compiler; in Intel Fortran, SEQUENCE types do not, by default, have alignment padding added before misaligned components. (This can be overridden with the "align sequence" option.) Lastly, an interoperable derived type, declared with the BIND(C) specifier, is required to have its components laid out exactly as the companion C processor would do it - this may involve padding if the C processor would pad by default.

Consider the following declaration:

type :: mytype
  sequence
  integer(2) f1
  union
   map
     integer(2) xa1
     integer(4) xa2
     integer(2) xa3
     integer(4) xa4
   end map
   map
     integer(4) xb1
     integer(2) xb2
     integer(4) xb3
     integer(2) xb4
   end map
  end union
end type mytype

Because the first component, f1, is two bytes long, the UNION starts at offset 2. (Remember that SEQUENCE disables padding in Intel Fortran.) This would make components xa1 and xb1 begin at offset 2, causing xb1 to be misaligned, since 2 is not an integral multiple of its size, 4. Components xa2 and xa3 are naturally aligned and should begin at offsets 4 and 8.  xb2 is misaligned at offset 6.

Because of a defect, the compiler incorrectly inserts padding before each misaligned variable inside the UNION.  The following table shows the offsets for each component, with and without the defect:

Component	With Defect	Correct
f1	0	0
xa1	4	2
xa2	8	4
xa3	12	8
xa4	16	10
xb1	4	2
xb2	8	6
xb3	12	8
xb4	16	12
f2	20	14

Note that f2 is (correctly) misaligned in both cases, and that xb4 received an additional two bytes of padding - the inappropriate padding happens only within the UNION.

Resolution Status : This error will be corrected in a future compiler update.  As a workaround, enclose the TYPE declaration in the following directives:

 

!DEC$ OPTIONS /NOALIGN /NOWARN
... TYPE goes here
!DEC$ END OPTIONS

You can also compile with the "noalign" compiler option.

 

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Version : 
All C++/Fortran compiler versions up to 11.1.058.

Operating System : 
Mac OS X

Problem Description : 

Intel(r) Debugger fails to install on Mac Pro with Quad-Core Intel Xeon 5500 series processor and Quad-Core Intel Xeon 3500 series processor.  After installation of the compiler product, Intel Debugger (idb) is not found. 

Resolution Status : 

This issue will be resolved in the next product update.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200138822


Version : 10.1, 11.0, 11.1


Operating System : Linux*, Mac OS X* / IA-32, Intel® 64, IA-64


Problem Description : 

Both the Intel Fortran and C++ compilers for Mac OS and Linux quietly ignore the invalid option -i and pass it to the linker.

The effect is harmless on Mac OS because the linker (ld) does not support the -i option.

For example:

$ ifort -V -i sample.f90
Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090511 Package ID: m_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
ld: unknown option: -i

The effect is not harmless on Linux where both compiler driver's (icc, ifort) quietly passing the option to the linker (ld) turns on incremental linking. Incremental linking produces a non-executable LSB relocatable file and not a LSB executable file.

Because the incremental linking is done quietly it leads to user confusion when trying to execute the non-executable LSB relocatable file. The attempt to execute the resulting file results in a "Permission denied" error.

The demonstration below shows how the invalid -i option leads to this confusing situation and error.

$ ifort sample.f90 -o sample

$ file sample
sample: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ ifort -i sample.f90 -o sample

$ file sample
sample: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped

$ ./sample
-bash: ./sample: Permission denied


$ icc sample.c -o sample

$ file sample
sample: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ icc -i sample.c -o sample

$ file sample
sample: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped

$ ./sample
-bash: ./sample: Permission denied

Resolution Status : This is a known issue that will be fixed in a future release. Since -i is not a valid Intel compiler option, correcting or removing the option will resolve the issue.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200138566


Version : 11.0, 11.1


Operating System : Linux*, Mac OS X* / IA-32, Intel® 64, IA-64


Problem Description : 

Beginning with the 11.x release, the Intel Fortran compiler does not correctly ignore the -extend-source (and other variants) for free-form source files named with the .F90 extension. The option is correctly ignored for source files named with the lower-case .f90 extension.

The mishandling of the option will cause erroneous syntax errors for any Fortran source statement that extends beyond the designated statement field length specified with the -extend-source option.

The example below demonstrates the extraneous errors issued when using -extend-source 132 with the sample program containing an OPEN statement extending beyond 132 characters.

Given the following sample.F90 source:

program sample

open(unit=10,file='/hardware/temporary/model/simulation/version/9.999/xray/store/detection/reflection/fulltrace/resolution/images7654.txt',status='replace',iostat=ios_100)

if(ios_100/=0) then
   print *,"File open failed"
endif

end

$ ifort -V -c -extend-source 132 sample.F90
Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

Intel(R) Fortran 11.1-2536
sample.F90(3): error #5120: Unterminated character constant
open(unit=10,file='/hardware/temporary/model/simulation/version/9.999/xray/store/detection/reflection/fulltrace/resolution/images76&
------------------^
sample.F90(4): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ) ,
&5
--^
compilation aborted for sample.F90 (code 1)

Resolution Status : This is a known issue that will be fixed in a future release. Since -extend-source is not intended to apply to free-form source files, to work around this current defect simply avoid usage with any .F90 source files.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200111543


Version : 11.0


Operating System : All


Problem Description : The compiler gives a syntax error for an array constructor of the form:

(/parameter-name/)

where parameter-name is a PARAMETER constant that has the same name as a datatype keyword (BYTE, INTEGER, REAL, COMPLEX, etc.)  For example:

INTEGER, PARAMETER :: BYTE = 123
INTEGER IA(1)
IA = (/BYTE/)
END

When compiled, this gives an error such as:

example.f90(3): error #5082: Syntax error, found ')' when expecting one of: ( <IDENTIFIER> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT> <INTEGER_CONSTANT> ...
IA = (/BYTE/)
------------^


Resolution Status : This problem is fixed in the January 2009 product update.  A workaround is to use the Fortran 2003 array constructor syntax:

[parameter-name]

instead.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200027325


Version : 10.1, 11.0


Operating System : All


Problem Description : If a FLUSH statement is executed and there is no file open on the specified unit, an error occurs as follows:

forrtl: severe (707): FLUSH: Unit 3 is not connected

The correct behavior would be that this operation has no effect.

Resolution Status : This problem will be corrected in a future version of Intel Fortran Compiler. As a workaround, avoid executing FLUSH statements on units that are not open.  You can use the INQUIRE statement to test whether or not a unit is open.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]