Syntax for SELECT TYPE

[James Van Buskirk]

Is this the correct syntax for a SELECT TYPE construct?

module types
implicit none
type CS5SS
integer x
real y
end type CS5SS
type SQS3C
logical u
character(7) v
end type SQS3C
contains
subroutine sub(x)
class(*), allocatable :: x
select type(x)
type is(CS5SS)
write(*,'(a)') 'TYPE IS CS5SS'
type is(SQS3C)
write(*,'(a)') 'TYPE IS SQS3C'
class default
write(*,'(a)') 'TYPE could not be determined'
end select
end subroutine sub
end module types

program test
use types
implicit none
class(*), allocatable :: u1, u2

allocate(u1,source = CS5SS(2,1.414))
allocate(u2,source = SQS3C(.TRUE.,'Message'))
call sub(u1)
call sub(u2)
end program test

[Richard Maine]

James Van Buskirk <not_...@comcast.net> wrote:

> Is this the correct syntax for a SELECT TYPE construct?

[code elided]

Looks ok offhand to me. Tried a few compilers to see if I overlooked
something. Compiles and runs fine with Intel Fortran. GFortran 4.9.2
complains

Error: CASE label at (1) overlaps with CASE label at (2)

which looks like a bug to me. In any case, that's not a syntax
complaint, so it looks like both compilers are happy with the syntax.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[FortranFan]

Given your expertise, I wonder if it's a trick question!!

I assume you're trying gfortran and encountering a compiler error. As Richard Maine indicated, the code works fine with Intel Fortran and also appears standard conforming.

Changing the names of either of your types, say appending an underscore to either one of them, makes the code compile.

See this thread: https://software.intel.com/es-es/forums/intel-visual-fortran-compiler-for-windows/topic/606668?language=ru

Perhaps it's an issue with gfortran hash scheme?

[Thomas Koenig]

James Van Buskirk <not_...@comcast.net> schrieb:

> Is this the correct syntax for a SELECT TYPE construct?

The rather strange error (Case label overlaps) is now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69829

[jfh]

Same error for gfortran 5.3.0

[paul.rich...@gmail.com]

It is indeed the hash scheme. Both names have the hash 43152863. Perhaps James already knew that was the case? :-)

Nuts! I had hoped that we would survive on the SDBM algorithm since it is so simple and that the choice of names that mean something would reduce the possibility of collisions. However, I guessed that this would come up one day but I did not exepct that it would take as long as 7 years.

This is now PR69834 on gcc Bugzilla.

Paul

[paul.rich...@gmail.com]

I did not notice that Thomas had already posted a bug report.

Paul

[James Van Buskirk]

wrote in message
news:3789b88b-d39d-4f02...@googlegroups.com...

On Monday, 15 February 2016 21:37:51 UTC+1, FortranFan wrote:

> > Perhaps it's an issue with gfortran hash scheme?

> It is indeed the hash scheme. Both names have the hash 43152863.
> Perhaps James already knew that was the case? :-)

Not the hash value specifically, but it's easy to search for two
strings that hash the same.

> Nuts! I had hoped that we would survive on the SDBM algorithm
> since it is so simple and that the choice of names that mean
> something would reduce the possibility of collisions. However,
> I guessed that this would come up one day but I did not exepct
> that it would take as long as 7 years.

> This is now PR69834 on gcc Bugzilla.

I find it surprising that an Easter egg like this exists in gfortran
that can causes random incorrect results. In the original example
if the second TYPE IS clause were omitted, the program would
simply print out the wrong answer. So there may already be
programs out there in the wild that are doing so, see the
birthday paradox.

[paul.rich...@gmail.com]

Hi James,

> On Monday, 15 February 2016 21:37:51 UTC+1, FortranFan wrote:
>
> > > Perhaps it's an issue with gfortran hash scheme?
>
> > It is indeed the hash scheme. Both names have the hash 43152863.
> > Perhaps James already knew that was the case? :-)
>
> Not the hash value specifically, but it's easy to search for two
> strings that hash the same.

Indeed it is.

>
> > Nuts! I had hoped that we would survive on the SDBM algorithm
> > since it is so simple and that the choice of names that mean
> > something would reduce the possibility of collisions. However,
> > I guessed that this would come up one day but I did not exepct
> > that it would take as long as 7 years.
>
> > This is now PR69834 on gcc Bugzilla.
>
> I find it surprising that an Easter egg like this exists in gfortran
> that can causes random incorrect results. In the original example
> if the second TYPE IS clause were omitted, the program would
> simply print out the wrong answer. So there may already be
> programs out there in the wild that are doing so, see the
> birthday paradox.

I agree that this is rather more than unfortunate. The use of the hash alone started when the implementation of OOP in gfortran was very much in an experimental phase. Real life intervened and I just never got back to something more robust. I will consult with fellow maintainers as to the best way forward and will endeavour to fix the problem before the 6.0 release.

Paul

[Stefano Zaghi]

Il giorno mercoledì 17 febbraio 2016 10:26:29 UTC+1, paul.rich...@gmail.com ha scritto:
> I will consult with fellow maintainers as to the best way forward and will endeavour to fix the problem before the 6.0 release.
>
> Paul

Thank you very much for your great work, it is very appreciated.

My best regards.