<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Thank you so much! in Intel® Fortran Compiler</title>
    <link>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934035#M88483</link>
    <description>&lt;P&gt;Thank you so much!&lt;/P&gt;
&lt;P&gt;The data race can be solved by using either "-openmp" or "-recursive". Further inspections find its a problem of memory allocation of local _array_. The option "-auto" can solve this as well.&lt;/P&gt;
&lt;P&gt;I can always find exports here :D&lt;/P&gt;</description>
    <pubDate>Wed, 26 Jun 2013 08:23:58 GMT</pubDate>
    <dc:creator>woshiwuxin</dc:creator>
    <dc:date>2013-06-26T08:23:58Z</dc:date>
    <item>
      <title>why does "-openmp" result different files for an OpenMP-free Fortran code?</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934032#M88480</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;Sorry for the awkward title.&lt;/P&gt;
&lt;P&gt;Basically, I have a piece of Fortran source code which contains no OpenMP directives (Its &lt;STRONG&gt;OpenMP-free&lt;/STRONG&gt;). The compiler commands "&lt;STRONG&gt;ifort -openmp -c foo.f&lt;/STRONG&gt;" and "&lt;STRONG&gt;ifort -c foo.f&lt;/STRONG&gt;" produced different objects. Actually, the commands "&lt;STRONG&gt;ifort -openmp -S&lt;/STRONG&gt;" and "&lt;STRONG&gt;ifort -S&lt;/STRONG&gt;" could generate different assembly files. I was puzzled. Because the source code is OpenMP-free, the "-openmp" option should be expected to have no effect at all.&lt;/P&gt;
&lt;P&gt;Moreover, if this code is compiled without an "-openmp" option (since it's completely OpenMP-free), and an analysis of the final binary with Inspector XE would reveal a data race in the beginning of the source file, e.g. &lt;STRONG&gt;subroutine foo(a, b, n)&lt;/STRONG&gt;. This subroutine has only local variables (no common blocks). I'm really confused...&lt;/P&gt;
&lt;P&gt;Because this code is&amp;nbsp;proprietary, I cannot post it here. Sorry!&lt;/P&gt;
&lt;P&gt;Can anyone comment on this, or do you have the same experience?&lt;/P&gt;</description>
      <pubDate>Tue, 25 Jun 2013 20:41:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934032#M88480</guid>
      <dc:creator>woshiwuxin</dc:creator>
      <dc:date>2013-06-25T20:41:00Z</dc:date>
    </item>
    <item>
      <title>Adding the -openmp option</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934033#M88481</link>
      <description>&lt;P&gt;Adding the -openmp option informs the compiler that the functions and subroutines _may_ be called by OpenMP (from routine not in your compilation unit, eg a library with callbacks). With this option selected, the functions and subroutines are compiles as if the attribute recursive were in effect. (For OpenMP this would be re-enterant)&lt;/P&gt;
&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Wed, 26 Jun 2013 00:20:50 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934033#M88481</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2013-06-26T00:20:50Z</dc:date>
    </item>
    <item>
      <title>Further to what Jim said,</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934034#M88482</link>
      <description>&lt;P&gt;Further to what Jim said, ifort does not perform dynamic allocation of local arrays unless one of the options with effect similar to RECURSIVE is in effect.&amp;nbsp; Any update in such arrays in more than 1 thread would be a race condition.&lt;/P&gt;
&lt;P&gt;One of the recommended tests prior to turning on OpenMP is to verify correct working with RECURSIVE or equivalement compile option.&lt;/P&gt;</description>
      <pubDate>Wed, 26 Jun 2013 03:13:38 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934034#M88482</guid>
      <dc:creator>TimP</dc:creator>
      <dc:date>2013-06-26T03:13:38Z</dc:date>
    </item>
    <item>
      <title>Thank you so much!</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934035#M88483</link>
      <description>&lt;P&gt;Thank you so much!&lt;/P&gt;
&lt;P&gt;The data race can be solved by using either "-openmp" or "-recursive". Further inspections find its a problem of memory allocation of local _array_. The option "-auto" can solve this as well.&lt;/P&gt;
&lt;P&gt;I can always find exports here :D&lt;/P&gt;</description>
      <pubDate>Wed, 26 Jun 2013 08:23:58 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/why-does-quot-openmp-quot-result-different-files-for-an-OpenMP/m-p/934035#M88483</guid>
      <dc:creator>woshiwuxin</dc:creator>
      <dc:date>2013-06-26T08:23:58Z</dc:date>
    </item>
  </channel>
</rss>

