This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
fixed format source code. cat -T l.fThat is a question of view point. The Fortran 77 standard does not define tabs but only has spaces. With spaces there is no problem. I played around with some compilers and they all hand it differently (including whether the line is cut off after 72 characters or not). If you do not rely on the cut off, you can use -ffixed-line-length-none (or -ffixed-line-length-n with your choice of "n").
!234567890123456789012345678901234567890123456789012345678901234567890123456789 ! 1 2 3 4 5 6 7 ^I INTEGER A
this is deceptive, because cat displayed the tab as a ^I, so the text is shown shifted right one position. g77 accepted this. gfortran does not [...]
is this a bug ?
3 baby bugs ( no XOR operator, no common block name in VOLATILE statements, tab counts more than one position in fixed format).The problem with .XOR. (see PR 33432 and 34933) is that it potentially conflicts with a user-defined .XOR. operator, which would reject valid Fortran 95 code; as written one could implement it using a flag, but as replacing it by .eqv. is presumably easier and makes the program more standard conform.
trust me. this is nothing. it has taken days after a compiler switch in the past to get the code:-)
to compile. many days in some circumstances :) wonderful. i encourage anyone who has been waiting to make the plunge to gfortran from g77 to
give it a try.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |