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 

INTERFACE not compiling due to ambiguity-but ok in GFortran

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



Joined: 12 Oct 2016
Posts: 159

PostPosted: Fri Apr 21, 2017 12:36 pm    Post subject: INTERFACE not compiling due to ambiguity-but ok in GFortran Reply with quote

Hi
I have the following test example. If compiled under silverfrost, it complains as follows:

*** This generic call to IUADD is ambiguous as both of the specifics IUADD1 and IUADD2 could match the arguments as supplied

In Gfortran it compiles and runs fine. Is this intended behaviour? It seems to me that they are different arguments. This is a simplified example to show the issue. Thanks


Code:

MODULE ADDITIONS
INTERFACE IUADD
  INTEGER*8 FUNCTION IUADD1(I1,I2)
    INTEGER*8 :: I1, I2
  END FUNCTION

  INTEGER*8 FUNCTION IUADD2(I1,I2)
    INTEGER*8      :: I1
    INTEGER*4      :: I2
  END FUNCTION
END INTERFACE

 
END MODULE

INTEGER*8 FUNCTION IUADD1(I1,I2)
    INTEGER*8 :: I1, I2
   
    IUADD1 = I1 + I2
  END FUNCTION

  INTEGER*8 FUNCTION IUADD2(I1,I2)
    INTEGER*8      :: I1
    INTEGER*4      :: I2
   
    IUADD2 = I1 + I2
  END FUNCTION


PROGRAM MAIN
  USE ADDITIONS
 
  INTEGER*8 K1, K2, KSUM
  INTEGER*4 L2
 
  K1 = 2
  K2 = 5
  L2 = 5
  KSUM = IUADD(K1, L2) ! this works
  KSUM = IUADD(K1, K2) ! this doesn't work in Silverforst (in GFortran yes)
  PRINT*,"KSUM = ",KSUM
END PROGRAM
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Apr 21, 2017 3:41 pm    Post subject: Reply with quote

I have made a note that this needs checking out.
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: Fri Apr 21, 2017 4:00 pm    Post subject: Reply with quote

It seems to work OK for me. What version of FTN95 are you using?

It fails when using /size32 which is probably a bug. Are you using /size32 and do you need it? It is only needed in very unusual situations.
Back to top
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Sat Apr 22, 2017 11:37 am    Post subject: Reply with quote

I am indeed using /size32 (because I am using the size function a few times and I was getting many warnings because I am saving the output of the size as an INTEGER*4). So I will remove the /size32 for now. Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Apr 22, 2017 11:48 am    Post subject: Reply with quote

In the next release of FTN95 you will be able to add a KIND argument to the call of SIZE. Also for now you could opt to ignore particular warning messages by using a command line option.
Back to top
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Wed May 03, 2017 11:24 am    Post subject: Reply with quote

Do you have an approximate date for the next release? Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed May 03, 2017 2:12 pm    Post subject: Reply with quote

No not really. The period between major releases can be estimated from the Announcements section of this forum.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu May 04, 2017 11:24 pm    Post subject: Reply with quote

6 to 9 months on average typically, so we could anticipate likely to be one in last quarter of this year I suppose.

Will there be any particlìular significant 'major' enhancements in the next release Paul ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri May 05, 2017 8:37 am    Post subject: Reply with quote

How big is "major"? A lot of work has already been done including moving large static arrays to virtual storage. Certainly by the time of the next release one can be confident of "significant" enhancements.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri May 05, 2017 9:15 am    Post subject: Reply with quote

Paul, Often big projects issue so called night builds. Firefox browser for example doing that for all betatesters who are interested. Reason for that is that numerous testers may find hidden bugs much faster and report them.

Can at least few enthusiasts or at the final least those who are on current support contracts get latest builds and upgrades on their request? The 2-3 recent DLLs (DLLs from 6) already substantially conflict with the older stable release ver.810 (Clearwin+ and debugger now crashing completely unreasonably and often just after the loading of the program without touching anything) so I can not use them. If compiler developers do not experience crashes that may tell that very substantial changes were made recently which conflicts with older releases. I noticed that some people do not have crashing problems with latest DLLs, which may tell that their codes are small, they do not use debugger, numerous tricky libraries etc. If compiler developers also work with small codes (which is very reasonable to imply) they may also miss the compiler problems users with large problems may immediately experience.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Mar 21, 2019 9:57 am    Post subject: Reply with quote

The issue raised here by StamK has now been reviewed. The outcome for the next release of FTN95 is that the effect of /SIZE32 (which currently is an alias for /SIZE_ISO) has been modified.

This will mean that the above code will compile as expected when using /SIZE_ISO but /SIZE32 will remain as a special device that allows certain 32 bit code be ported to 64 bits without change.

So /SIZE32 will continue to cause the above failure and its use should be avoided in almost all circumstances.

For those who really want to know: /SIZE32 can be used as a quick fix when porting from 32 bit to 64 bits and when a call to SIZE is made whilst passing an argument to a user defined generic routine as for example in CALL generic_fun(SIZE(x)).
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Mar 22, 2019 11:50 am    Post subject: Reply with quote

Do you have an approximate date for the next release? Thanks

Statistically speaking it should appear within the next week .... or in May.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Apr 02, 2019 8:47 am    Post subject: Reply with quote

This is a postscript to my last post above.

Further work has now been completed on this issue with the result that the FTN95 command line option /SIZE32 should now be redundant. If you added this option when porting from 32 bit to 64 bits in order to get your code working then you should be able to work without it (from the next release). If not then please let me know.

The option /SIZE_ISO is retained and meaningful. Now, for 64 bits, by default the SIZE intrinsic (without a KIND specifier) continues to return a 64 bit integer except when it appears as an argument. By using /SIZE_ISO, FTN95 becomes standard conforming which means that by default SIZE always returns an integer (or integer array) of type "default integer".
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