https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-11-21
Ever confirmed|0 |1
--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #8)
> On Wed, Nov 21, 2018 at 08:49:55AM +0000, tkoenig at gcc dot gnu.org wrote:
> >
> > --- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> > The type has SEQUENCE, so I think this should actually work... or did I miss
> > something here?
> >
>
> Remove the INCLUDE from the problem, and consider
>
> program foo
> type aaa
> integer i
> end type aaa
> type(aaa) a
> call bar(a)
> print *, a%i
> end program foo
>
> subroutine foo(a)
> type aaa
> character(4) i
> end type aaa
> type(aaa) a
> a%i = 'abcd'
> end subroutine foo
>
> Put each unit in its own file, compile each separately, and link.
> type aaa is clearly not the same both unit.
Correct.
> Do you expect to link
> and execute the program?
No.
> You can now change character(4) to integer.
> How is the compiler to know that the types are the same as the types
> are in different namespaces.
Not for your example.
However, the original test case had SEQUENCE in the type
definition.
Here is 4.5.2.4 from F2008:
4.5.2.4 Determination of derived types
Derived-type definitions with the same type name may appear in different
scoping units, in which case they might be independent and describe different
derived types or they might describe the same type.
Two data entities have the same type if they are declared with reference to the
same derived-type definition. Data entities also have the same type if they are
declared with reference to different derived-type definitions that specify the
same type name, all have the SEQUENCE attribute or all have the BIND attribute,
have no components with PRIVATE accessibility, and have type parameters and
components that agree in order, name, and attributes. Otherwise, they are of
different derived types. [Rest about PRIVATE elided]
So, the original test case fulfilled the condition of 4.5.2.4, and the two
types in the different scoping unit did indeed describe the same type.
> Sure, it may compile, link, and execute
> but I think that is undefined behavior. I also think SEQUENCE is a
> red herring here, as its only purpose is to restrict a compiler from
> re-ordering components in a type with multiple components.
> The fix for the person in fortran@ is trivially stupid. Use a module.
It certainly is a workaround, and the definitely preferred way to do
it, but what he showed was correct.
