<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Thu, 09 Feb 2012 23:00:17 -0800 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/fdiag6405/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments Feed</title>
    <link>http://software.intel.com/en-us/articles/fdiag6405</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By brchrisman</title>
      <description><![CDATA[ I noticed that this error seems to be generated when a module name conflicts with a derived type name.  In the example below, derived type 'two' is defined in module 'one', but when referenced in module 'two', it conflicts.
The spec doesn't seem to help here (I'm looking at an f95 'final draft', if there's a free f90 spec pdf around somewhere, please let me know, I couldn't find it).  The section 14.1.2 identifies three classes of entities which aren't allowed to conflict, but module name/identifier doesn't seem to be listed in any of them?

This throws an error under gfortran and ifort, but pgf accepts it.  I'm compiling code that originally compiled on pgf, which is how I noticed it.  Am I interpreting this correctly?

-Brian

module one
  type two
    integer :: aaa
  end type
end module

module two
  use one
  contains
    integer function test()
      type (two) :: my_two
    end function
end module

program main
end program

[bc@anubis sample]$ ifort test.f90
test.f90(11): error #6405: The same named entity from different modules and/or program units cannot be referenced.   [TWO]
      type (two) :: my_two
------------^
 ]]></description>
      <link>http://software.intel.com/en-us/articles/fdiag6405/#comment-37856</link>
      <pubDate>Thu, 07 Jan 2010 22:45:26 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/fdiag6405/#comment-37856</guid>
    </item>
    <item>
      <title>By brchrisman</title>
      <description><![CDATA[ From 11.3 in f95,
"The module name is global to the program, and shall not be the same as the name of any other 
program unit, external procedure, or common block in the program, nor be the same as any local 
name in the module."

In my example, the 'use one' would make type 'two' a local name in the 'two' module, which causes the conflict when the derived type is referenced? ]]></description>
      <link>http://software.intel.com/en-us/articles/fdiag6405/#comment-37859</link>
      <pubDate>Thu, 07 Jan 2010 23:21:09 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/fdiag6405/#comment-37859</guid>
    </item>
    <item>
      <title>By Steve Lionel (Intel)</title>
      <description><![CDATA[ Yes, that's the rule that makes this code invalid. ]]></description>
      <link>http://software.intel.com/en-us/articles/fdiag6405/#comment-37878</link>
      <pubDate>Fri, 08 Jan 2010 07:02:24 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/fdiag6405/#comment-37878</guid>
    </item>
    <item>
      <title>By Joe Zuntz</title>
      <description><![CDATA[ Are there any ifort 11.1 compiler flags that would help track down exactly which modules define the symbol?  If you have a bit of a web of modules this can take a while. ]]></description>
      <link>http://software.intel.com/en-us/articles/fdiag6405/#comment-44853</link>
      <pubDate>Tue, 15 Jun 2010 06:11:23 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/fdiag6405/#comment-44853</guid>
    </item>
    <item>
      <title>By Steve Lionel (Intel)</title>
      <description><![CDATA[ Sorry, no, we don't.  I agree that would be nice. ]]></description>
      <link>http://software.intel.com/en-us/articles/fdiag6405/#comment-44909</link>
      <pubDate>Wed, 16 Jun 2010 11:41:04 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/fdiag6405/#comment-44909</guid>
    </item>
  </channel></rss>
