forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem with integer KINDs when pointers are present

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
Andre



Joined: 19 Jan 2017
Posts: 14

PostPosted: Wed Aug 23, 2017 12:38 pm    Post subject: Problem with integer KINDs when pointers are present Reply with quote

Consider the following program:
Code:
program main
    integer, target :: foo            ! var 1
    integer, pointer :: bar => null() ! var 2
    integer :: abc = 123              ! var 3

    bar => foo
    bar = huge(foo)

    print *, 'Kind of integer: ', kind(abc)
    print *, 'Target: ', foo, ' kind=', kind(foo)
    print *, 'Pointer ', bar, ' kind=', kind(bar)
end program

All 'integer':
32 bit:
If I compile with normally in 32 bit (e.g. ftn95 main.f90 /link), the output is as follows:
Code:
 Kind of integer:            3
 Target:   2147483647 kind=           3
 Pointer   2147483647 kind=           3

As expected, variables 1,2,3 have kind 3 (integer*4).

64 bit:
However, if I compile with /64, the output is:
Code:
 Kind of integer:            3
 Target:   9223372036854775807 kind=           4
 Pointer   9223372036854775807 kind=           4

which means that target and pointer (vars 2,3) are implicitly converted to integer*8, as also can be seen by the huge() value being assigned. I consider this wrong behavior.

All 'integer*4':
32 bit:
If I replace 'integer' in vars 1,2,3 with 'integer*4', 32 bit compiles just fine and produces the expected output (see above).

64 bit:
However, the 64bit version won't even compile:
Code:
0009)     print *, 'Kind of integer: ', kind(abc)
*** Internal compiler error - floating point exception

    1 ERROR [main.F90] - Compilation failed.


Target 'integer*8', pointer 'integer':
32 bit:
As expected, this combination fails in 32 bit:
Code:
0006)     bar => foo
*** This pointer assignment would assign a pointer to the wrong kind of data

64 bit:
In 64 bit, the code surprisingly (or not?) compiles fine and gives the same output as in the first case (i.e. it implicitly converts the pointer to an integer*8 pointer)

All 'integer*8':
This works fine in both 32 bit and 64 bit.

I assume this behavior of ftn95/64 is a bug and needs to be fixed.

The bad thing here is that if you only use plain 'integer' as data type you won't even notice that actually the code is broken (e.g. if you rely on integers having a specific size).

Best regards,
André

Edit: I used FTN95 v8.10.0


Last edited by Andre on Wed Aug 23, 2017 2:13 pm; edited 2 times in total
Back to top
View user's profile Send private message
Andre



Joined: 19 Jan 2017
Posts: 14

PostPosted: Wed Aug 23, 2017 1:28 pm    Post subject: Reply with quote

Okay, the problem seems to be even worse:
Consider again this very simple program:
Code:
program main
    integer, target :: foo
!    integer, pointer :: bar => null()
    foo = 123
    print *, 'Target: ', foo, ' kind=', kind(foo)
end program


Both 32 and 64 bit provide the expected output:
Code:
 Target:          123 kind=           3


If we comment in the second line and compile with 64 bit however, the output is:
Code:
 Target:                   123 kind=           4

Note that the sheer presence of a pointer makes the target integer become a integer*8, which should not happen.
This also happens if we remove the target specifier from the variable!


None of this happens with 32 bit (i.e. in this case it works as expected).


Last edited by Andre on Wed Aug 23, 2017 2:12 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Wed Aug 23, 2017 1:49 pm    Post subject: Reply with quote

Thanks for the feedback. I have made a note that this needs investigating.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sat Jul 13, 2019 8:13 am    Post subject: Reply with quote

Upon review, these issues are no longer apparent so they have been fixed in some other context.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group