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

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

I have made a note that this needs checking out.

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.

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

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.

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

No not really. The period between major releases can be estimated from the Announcements section of this forum.

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.

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.

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)).

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'.