This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #13)
--- snip ---
> 
> Although I partially agree with that, I don't understand why
> 
>          if ( x(1) < 0 .or.          &
>              x(2) < 0 ) print *, x
> 
> does not trigger any matching error in free form, while
> 
>          if ( x(1) < 0 .or.
>      &        x(2) < 0 ) print *, x
> 
> does in fixed form. IMO there is latent bug in the parser.

I dont think in the parser.  I agree this is an odd duck.  Theoretically
continuation markers are removed and the parser only sees one line.  One
difference between fixed and free is that fixed lines are padded out to the
max-line-length with spaces.

Another odd thing I found is on or about scanner.c:1530 is this:

      if (c == '0' || c == ' ' || c == '\n')

What is the significance of a zero digit in that position.  Is this some old
syntax.  I have deleted it and also tried changing it to '\0', as in NULL, but
it has no effect on the problem at hand or the testsuite.

Also when an unexpected end of file is encountered, the locus is backed up one
line.  It could be that one line is trying to be parsed a second time and
giving the error. I have not had time to try additional debuggery. This gets
into an area we engineers call the $#!t to worth ratio. ;)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]