> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc <g...@gcc.gnu.org> wrote:
>
>
> Hi Iain,
>
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have different entry points for the two formats.
>
> I meant the case where the user writes, with an old, KIND=16 is double
> double compiler,
>
> subroutine foo(a)
> real(kind=16) :: a
> a = a + 1._16
> end subroutine foo
>
> and puts it in a library or an old object file, and in new code with an
> IEEE QP compiler calls that with
>
> real(kind=16) :: a
> a = 2._16
> call foo(a)
> print *,a
>
> this will result in silent generation of garbage values, since Fortran
> does not mangle the function name based on it types. For both cases, the
> subroutine will be called foo_ (or MOD..._foo).
hmm, well I thought about that case, but … isn’t this “pilot error”?
if one compiles different parts of a project with incompatible command line
options…
… or, say, compile with -mavx512 and then try to run code on hardware without
such a vector unit?
Getting wrong answers silently can likely be done with other command line
option mismatches.
Iain
> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
>
> This is starting to look like a can of worms from Pandora's box,
> if you pardon my mixed metaphors.
>
> Best regards
>
> Thomas
