Странное поведение gfortran -Wconversion

Рассмотрим следующий код.

! test.f90

program test
    use iso_fortran_env, only: INT64, REAL64
    print *, real(0_INT64, REAL64)
    print *, real(1000_INT64, REAL64)
    print *, real(huge(0_INT64), REAL64)      
end program test

При компиляции с gfortran следующим образом:

$ gfortran -Wconversion -std=f2008 test.f90

Я получил следующее предупреждение:

test.f90:5:18:

    5 |     print *, real(huge(0_INT64), REAL64)
      |                  1
Warning: Change of value in conversion from ‘INTEGER(8)’ to ‘REAL(8)’ at (1) [-Wconversion]

Обратите внимание, что gfortran доволен первыми двумя преобразованиями, но не последним.

Вопрос. Является ли показанное выше предупреждение ожидаемым поведением gfortran? Я думал, что ни в одном из трех случаев не должно появляться никаких предупреждений, поскольку преобразование выполняется явным образом с помощью REAL( , INT64).

Вот информация о версии моего gfortran:

$ gfortran --version

GNU Fortran (Ubuntu 9.3.0-10ubuntu2) 9.3.0

Для справки: ifort 19.1.127 компилирует test.f90 без нареканий:

$ ifort -warn all -stand f08 test.f90

Большое спасибо за любые комментарии или критику.


gfortran fortran intel-fortran fortran2008
person Nuno    schedule 09.09.2020    source источник
comment
0 и 1000 могут быть точно представлены в REAL64 (и даже в REAL32). HUGE(INT64) равно 9223372036854775807 и не может. REAL64 имеет 53 бита для «мантиссы» (действительно, мантиссы), и после вычитания знака и добавления скрытого бита это поддерживает чуть менее 16 десятичных цифр величины. 9223372036854775807 состоит из 19 десятичных цифр. Стандарт не требует диагностики, поэтому каждый «процессор» (компилятор) должен решать, что с этим делать.   -  person dave_thompson_085    schedule 09.09.2020
comment
Я понимаю. Очень ясно. Я думал только о диапазоне, но забыл посчитать десятичные цифры. Большое спасибо! @dave_thompson_085   -  person Nuno    schedule 09.09.2020

Ответы (1)


arrow_upward
0
arrow_downward

Ответ @dave_thompson_085 в комментариях:

«0 и 1000 могут быть представлены точно в REAL64 (и даже в REAL32). HUGE(INT64) равно 9223372036854775807 и не может. REAL64 имеет 53 бита для «мантиссы» (действительно, мантиссы), и после вычитания знака и добавления скрытого бита это поддерживает чуть менее 16 десятичных цифр величины. 9223372036854775807 состоит из 19 десятичных цифр. Это не диагностика, требуемая стандартом, поэтому каждый «процессор» (компилятор) должен решать, что с этим делать».

Большое спасибо, @dave_thompson_085.

person Nuno    schedule 09.09.2020
comment
Собираетесь ли вы отправить ответ по списку [email protected], поскольку вы также просили о помощи? - person evets; 09.09.2020