gfortran WRITE и FORMAT, по-видимому, не должны соответствовать компилятору Intel

Я компилирую программу, которая, как известно, компилируется с помощью ifort с использованием gfortran. Однако компилятор терпит неудачу в строке

WRITE (11,1325) ((IFILE,FILENAME(IFILE)),IFILE=1,IFILES)

с ошибкой компиляции:

main_file.f:205.32:

     WRITE (11,1325) ((IFILE,FILENAME(IFILE)),IFILE=1,IFILES)       
                            1
Error: Expected PARAMETER symbol in complex constant at (1)
make: *** [main_file.o] Error 1

Изменение этой строки на (обратите внимание на удаление '(' и ')')

WRITE (11,1480) (IFILE,FILENAME(IFILE),IFILE=1,IFILES)

чтобы соответствовать следующей строке

1480      FORMAT (1X,I1,' ',A40)

решает проблему, но мне было интересно, может ли кто-нибудь знать, почему эта ошибка не фиксируется компилятором Intel. В данном случае кажется, что gfortran дает правильное поведение. Мои флаги компиляции:

gfortran -fno-automatic -mcmodel=medium -O2 -ffast-math  main_file.o -o main_file

gfortran fortran
person dmon    schedule 29.04.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Довольно интересный вопрос. Работает только для массивов:

 print *, ((1,["a","b"]),i=1,10)
end

работает, но

 print *, ((1,"a"),i=1,10)
end

терпит неудачу с ifort:

: error #6063: An INTEGER or REAL data type is required in this context.   ['a']
 print *, ((1,"a"),i=1,10)

Бог знает, что думает парсер в первом рабочем случае, может быть, неполное вложенное подразумеваемое действие? Конечно, это недопустимый синтаксис Фортрана и должен быть отклонен компилятором, который требует стандартного Фортрана. У Intel могут быть причины принять этот синтаксис.

person Vladimir F    schedule 29.04.2013
comment
Здравствуйте еще раз Владимир! Спасибо за быстро опубликованный комментарий. Да, это мое первое подробное знакомство с Фортраном, и мне кажется, что у него есть удивительные особенности для зрелого языка. - person dmon; 29.04.2013

arrow_upward
1
arrow_downward

Как писали другие в подобных недавних вопросах, из-за своего наследия компилятор Intel по умолчанию допускает ряд расширений. Компилятор выдаст диагностику, если вы укажете соответствующую стандартную опцию проверки (например, /stand в Windows).

Я не уверен в конкретном источнике этого конкретного расширения, но оно охватывает несколько случайных недоразумений синтаксиса, когда люди помещали «аргументы» для записи или чтения «функции» в круглые скобки...

READ (*,*) (not_valid_syntax)

(В операторе записи выражение в круглых скобках само по себе является выражением, и это допустимый элемент выходного списка - несколько лет назад компилятор Intel немного запутался бы в этом.)

person IanH    schedule 29.04.2013
comment
Ура, Ян, да, кажется, комбинация старого FORTRAN и альтернативного нового компилятора породила ряд причуд. Как программист, не работающий на FORTRAN, я начинаю понимать, почему он потерял популярность, несмотря на свою скорость. - person dmon; 01.05.2013
comment
Ваш исходный код не является и никогда не был настоящим Fortran, как определено любым из различных стандартов Fortran. Он использует специальные расширения компилятора. То, что использование расширений стандартного языка может вызвать проблемы при смене компилятора, вряд ли является специфичной проблемой Fortran. Переносимость между компиляторами является причиной существования стандартов - если программисты не придерживаются их, они получают то, что заслуживают. - person IanH; 01.05.2013