View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Fri Apr 21, 2017 12:36 pm Post subject: INTERFACE not compiling due to ambiguity-but ok in GFortran |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Apr 21, 2017 3:41 pm Post subject: |
|
|
I have made a note that this needs checking out. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Apr 21, 2017 4:00 pm Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Sat Apr 22, 2017 11:37 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Apr 22, 2017 11:48 am Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed May 03, 2017 11:24 am Post subject: |
|
|
Do you have an approximate date for the next release? Thanks |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Wed May 03, 2017 2:12 pm Post subject: |
|
|
No not really. The period between major releases can be estimated from the Announcements section of this forum. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu May 04, 2017 11:24 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri May 05, 2017 8:37 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Fri May 05, 2017 9:15 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Thu Mar 21, 2019 9:57 am Post subject: |
|
|
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 |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Mar 22, 2019 11:50 am Post subject: |
|
|
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 ... " |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Apr 02, 2019 8:47 am Post subject: |
|
|
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 |
|
|
|