release_notes.htm

里面有详细计算程序设计手册和原码分析 fortran90-and-computational-science

		<h4>Note on gcc Versions</h4>
		<p>The Intel compilers are tested with a number of different Linux distributions,
		  with different versions of gcc. If you are using any of gcc 3.2.3,
		  3.3.3, 3.3, 3.2, 3.4, 4.0, 4.1, you can expect to be successful. However
		  the version of binutils can impact your experience: later ones are generally
		  better and we recommend using at least 2.14. Some Linux distributions
		  may contain header files different from those we have tested, which may cause
		  problems. The version of glibc you use must be consistent with the
		  version of gcc in use. </p>
		<p><strong>Notes:</strong> </p>
		<ul>
		  <li>Compiling very large source files (several thousands
		    of lines) using advanced optimizations such as <code>-O3, -ipo</code> and <code>-openmp</code>,
		    may require substantially larger amounts of RAM.</li>
<li>The above lists of processor model names are not exhaustive - other
            processor models correctly supporting the same instruction set as
            those listed are expected to work. Please contact Intel&reg; Premier
            Support if you have questions regarding a specific processor model</li>
          <li>Some optimization options have restrictions regarding the processor
            type on which the application is run. Please see the documentation
            of these options for more information. </li>
</ul>
<!-- #EndLibraryItem --><h2><a name="Install"></a>Installation</h2>
		<p>Please see the separate <a href="INSTALL.htm">Installation Guide</a> for
		  information on installing the compiler and setting up the compiler
		  environment. The default installation directories, referred to elsewhere
		  in this document as <code>&lt;install-dir&gt;</code> and <code>&lt;idb-install-dir&gt;</code>,
		  are:</p>
		<ul>
			<li>
				<code>/opt/intel/fc/10.0.xxx</code>
			(for IA-32 and IA-64)
			<li>
				<code>/opt/intel/fce/10.0.xxx</code>			(for Intel&reg; 64)
			<li>
				<code>/opt/intel/idb/10.0.xxx </code>
			(for IA-32 and IA-64)
			<li>
				<code>/opt/intel/idbe/10.0.xxx</code> (for Intel&reg; 64)
			</li>
		</ul>
		<h2><a name="Limitations"></a>Known Issues</h2>
		<h4>Binary Incompatibility for OpenMP Applications</h4>
		<p>Programs compiled with the Intel Compiler version 9.0 using the <code>-openmp</code> switch
		  may not run after installing the Intel Compiler version 10.0. For such programs,
		  the loader may exit at run time with an error message about undefined symbols
		  beginning with the string <code>_intel</code> (for example, <code>_intel_fast_memset</code>).
		  If this occurs, please recompile the executable using the Intel Compiler
		  version 10.0 and the loader error message should disappear.</p>
		<h4>Installation Warning for RPM 4.0.2 and RPM 4.1</h4>
		<p>RPM 4.0.2 cannot install to a non-default directory. This has been resolved in 
			RPM 4.0.3. RPM 4.1 cannot install to a non-default directory. This has been 
			resolved in RPM 4.11 to 4.2.</p>
		<h4>Segmentation Violation with Static Link to libpthreads</h4>
		<p>Applications built with <code>libpthreads.a</code> statically linked, (<code>libpthreads.a </code>is
		  used  by default when -static is used), may fail with a segmentation
		  violation on some versions of Linux when the applications use more than 2GB
		  of stack space. This is a known limitation of Linuxthreads. If you encounter
		  this problem, link libpthreads dynamically. As an alternative, on Red Hat
		  Linux 9 and Red Hat Enterprise Linux 3.0, you can install the <code>nptl-devel</code> package
		  and  pass "<code>-I/usr/include/nptl -L/usr/lib/nptl</code>" on the ifort
		  command  line. This will create a statically-linked binary which will
		  run under nptl only, but which does not have the stack size limitation.</p>
		<h4>OpenMP limitations </h4>
		<ul>
          <li>
            <p>POSIX threaded programs that require a large stack size may not
              run correctly on some versions of Linux because of hard-coded stack
              size limits in some versions of the Linux POSIX threads libraries.
              These limits also apply to OpenMP programs (-openmp) and automatically
              generated parallel programs (<code>-parallel</code> ) with the
              Intel compilers, because the Intel compilers use the POSIX threads
              library to implement OpenMP based and automatically generated parallelism.
              Threaded programs that exceed the stack space limit usually experience
              segmentation violations or addressing errors. </p>
            <p>To avoid these limitations, use a version of glibc built with
              the <code>FLOATING_STACKS</code> parameter defined. For some distributions,
              this implies using the shared rather than the static version of
              the pthreads library. Then use the <code>ulimit -s</code> or <code>limit
              stacksize</code> command to set the maximum shell stack size to
              an explicit large value, in units of KBytes, (not <code>unlimited</code>),
              and also set the <code>KMP_STACKSIZE</code> environment variable
              to the needed thread stacksize in bytes. Note, in the bash shell, <code>ulimit
              -s</code> can be used to set a large maximum stack size only once.
              In the C shell (csh), <code>limit stacksize</code> , with no dash
              before the argument, can be used to reset the maximum stacksize
              repeatedly.</p>
            <p>This solution has been tested on glibc version 2.2.4-13 for IA-32
              and glibc 2.2.4-19 for IA-64 as found in
              the Red Hat 7.2 Linux distribution. For glibc 2.2.4-13 on IA-32,
              the shared version of the POSIX threads library must be used, (there
              should not be a <code>-static</code> flag in the compiler .cfg
              file or on the command line).</p>
          </li>
		  <li>
		    <p>It is noted that Linux thread local storage (TLS) is not fully supported
		      by the default installations of <code>/usr/lib/libpthread.a</code> and <code>/usr/lib/libc.a</code> on
		      certain versions of Linux (Red Hat Enterprise Linux 4 and earlier are
		      known examples). When using the Linux TLS mechanism and linking with <code>-static</code>,
		      the inclusion of <code>-openmp</code> or calls to <code>libpthread</code> may
		      trigger a runtime failure when trying to access thread local storage.
		      To fix this problem, install the <code>nptl-devel.rpm</code> package
		      (included on the Linux installation CD) and compile with <code>-L/usr/lib/nptl</code>.</p>
	      </li>
          <li>If a common block is declared as <code>THREADPRIVATE</code> with
            an OpenMP directive, the common block must have the same length in
          all the source files in which it is declared. </li>
	</ul>
		<h4>IA-64  Floating Point Software Assistance Handler 1.12 Error on Red Hat
		  Linux 7.2</h4>
		<p>On IA-64 systems, the Floating Point Software Assistance handler 
			(FPSWA), part of the system BIOS, performs software completion of
		  floating  point operations that generate exceptional values such as
		  NaNs and Infinities. Version 1.12 of the FPSWA has an error which can
		  be revealed on Red Hat Linux 7.2 systems as an unexpected segmentation
		  violation fault when an application runs. Intel is not aware that this
		  issue affects other distributions or versions of Linux on IA-64 systems.</p>
		<p>To correct this problem, upgrade the system BIOS to one that includes FPSWA 
			version 1.18 or later. Please contact your system manufacturer for BIOS update 
			information.</p>
		<h4><code>gprel relocation</code> Error Messages on IA-64
		  Linux Systems</h4>
		<P>On IA-64 systems running Linux, when the -shared switch is used to 
			create a Dynamic Shared Object (.so), there may be some "relocation against
			 dynamic symbol" messages generated during the ld phase, similar to:
		</P>
		<BLOCKQUOTE>
			<P><code>/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol 
					for__segv_default_msg
					<BR>
					/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol 
					for__l_fpe_mask
					<BR>
					/usr/bin/ld: for_init.o: @gprel relocation against dynamic symbol for__l_undcnt<BR>
				</code>...</P>
		</BLOCKQUOTE>
		<P>To fix this problem, add the switches <code>-i_dynamic</code> and <code>-nofor_main</code>
			to the command line. As of version 9.0, specifying <code>-shared</code> will
			 automatically set <code>-i_dynamic</code> and <code>-nofor_main</code>.</P>
		<h4><code>-ipo_obj</code> option is no longer supported</h4>
		<p>The <code>-ipo_obj</code> option, which forced generation of direct object
		  code, is no longer supported. If the option is specified, a warning is given
		  and the effect is as if <code>-ip</code> was specified instead. </p>
		<h4><code>-relax</code> no longer passed to linker on IA-64 systems </h4>
		<p>As of version 9.0, the compiler driver no longer passes the <code>-relax</code> switch
		  to the linker on IA-64 systems, as this conflicts with the <code>-r</code> option.
		  The -relax option is not needed as it is the default when using binutils
		  2.11.90.0.27 or later - 2.14 is recommended. If you must use an older
		  binutils and wish to specify the <code>-relax</code> option, use <code>-Xlinker
		  -relax</code> on
		  the compile command which invokes the linker. </p>
		<h4><code>ld</code> warning about <code>libunwind.so.7</code> on SLES 10</h4>
		<p>When applications are built using the Intel compiler on SUSE LINUX Enterprise
		  Server 10, you may see a warning similar to the following:</p>
		<p><code>ld: warning: libunwind.so.7, needed by /usr/lib/gcc/ia64-suse-linux/4.1.0/../../..//libgcc_s.so,
		    may conflict with libunwind.so.6 </code></p>
		<p>A workaround is to add the following line to <code>ifort.cfg</code>:</p>
		<p><code>-L /usr/lib </code></p>
		<p>This issue is expected to be resolved in a future release of the Intel compiler.</p>
		<h4>Limited debug information with automatic CPU dispatching <code>(-ax*</code>)</h4>
		<p>Compilation using <code>-ax{W|N|B|P}</code> results in two copies of generated 
			code for each function. One for IA-32 generic code and one for CPU specific 
			code. The symbol for each function then refers to an Auto CPU Dispatch routine 
			that decides at run-time which one of the generated code sections to execute. 
			Debugger breakpoints that are set on these functions by name cause the 
			application to stop in the dispatch routine. This may cause unexpected behavior 
			when debugging. This issue may be addressed in a future version of the Intel 
			Debugger and Compilers.
		</p>
		<h4>Cannot debug or view traceback for IA-32 programs built without <code>-fp </code>
		</h4>
		<p>Compilation using <code>-fp</code> specifies that the IA-32 EBP register be used 
			as a frame pointer rather than a general purpose register. Debuggers and 
			traceback handlers may not be able to properly unwind through a stack that 
			contains a call to a function that is compiled without <code>-fp</code> in 
			effect. If you compile with <code>-g</code> or <code>-O0</code>, <code>-fp</code>
			is implicitly enabled, but not if you specify a higher optimization level 
			explicitly (such as <code>-O2</code>). If you intend to use the debugger or 
			traceback on an application, and are using some level of optimization higher 
			than <code>-O0</code>, you should also specify <code>-fp</code> to ensure that 
			the debugger and traceback handler can use frame pointers.
		</p>
		<h4>GNU assembler may not recognize generated code</h4>
		<p>Older versions of the GNU Assembler may not be able to process assembly
		  code generated by compiling with the <code>-[a]xP</code>, <code>T</code> or <code>S</code> options.
		  Use binutils version 2.17.50.0.15 or later if this is an issue for you. </p>
		<h4>Use <code>idb</code> with Extended Debug Information</h4>
		<p>If you use the <code>-debug </code>keywords <code>inline_debug_info</code>, <code>semantic_stepping</code>, <code>variable_locations</code> or <code>extended</code>,
		  you should use the Intel Debugger (idb), as other debuggers may not
		  understand the extended information and may behave unpredictably. We
		  are working with the developers of other debuggers towards their adding support
		  for the extended debug information. </p>
		<h4><code>-auto_ilp32</code> Option Not Supported</h4>
		<p>The <code>-auto_ilp32</code> option which specifies that that an application 
			cannot exceed a 32-bit address space, and which is mentioned in the 
			documentation, is not supported.		</p>
		<h4>Enabling Run-Time Checks May Also Enable Compile-Time Checks</h4>
		<p>In some cases, enabling run-time checks using the <code>-check</code> or <code>-C</code> option may
		  cause the compiler to issue diagnostics for the requested condition
		  at compile-time, if it can be diagnosed then. For example, an array
		  bounds violation with a constant subscript may result in a compile-time
		  error if -<code>check bounds</code> or <code>-CB</code> is specified. </p>
		<h2><a name="TechSupport"></a>Technical Support</h2>