Dealing with inconstencies between compilers

[awvwgk]

This came up in #444, when trying to create failing tests for a function to wrap internal IO, like printing an integer value with a real format descriptor or a logical with an integer format descriptor.

The initial failing tests were created with gfortran, somewhat surprisingly ifort is particular smart about a lot of cases and implicitly casts the integer to a real before formatting it. What would be the best strategy to deal with such inconsistencies between different compilers?

[arjenmarkus]

Maybe explicitly require that the standard is used? That should turn off a lot of such extensions, but of course it may also mean that the compiler flags such things rhat than generate errors at run-time. Op za 26 jun. 2021 om 12:23 schreef Sebastian Ehlert < ***@***.***>:

…

This came up in #444 <#444>, when trying to create failing tests for a function to wrap internal IO, like printing an integer value with a real format descriptor or a logical with an integer format descriptor. The initial failing tests were created with gfortran, somewhat surprisingly ifort is particular smart about a lot of cases and implicitly casts the integer to a real before formatting it. What would be the best strategy to deal with such inconsistencies between different compilers? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#446>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YRZFVAQCATFTJCYBMVDTUWTCFANCNFSM47LG3CIA> .

[awvwgk]

@arjenmarkus Such options might change the ABI (like ifort -standard-semantics) and make stdlib more difficult to use in projects not using such options.

[arjenmarkus]

Right, so that is not a practical solution :( Op ma 28 jun. 2021 om 10:12 schreef Sebastian Ehlert < ***@***.***>:

…

@arjenmarkus <https://github.com/arjenmarkus> Such options might change the ABI (like ifort -standard-semantics) and make stdlib more difficult to use in projects not using such options. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#446 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR5KPH4ZYE3ZVW4ZAPTTVAVG7ANCNFSM47LG3CIA> .

[awvwgk]

For this particular case the compilers are in fact free to implement their own solution without constraints from the standard, in this case I think we should not/cannot do anything.