[Bug fortran/27954] New: ICE on garbage in DATA statement

[Bug fortran/27954] New: ICE on garbage in DATA statement

[reichelt at gcc dot gnu dot org]

The following invalid code snippet causes an ICE since GCC 4.0.0:

==============================
      subroutine FOO

      character*20 X  0
      data X /'A'/    0

      end subroutine FOO
==============================

 In file bug.f:4

      data X /'A'/    0                                                 
                 1
Error: Syntax error in DATA statement at (1)
 In file bug.f:6

      end subroutine FOO                                                
                                                                       1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol


-- 
           Summary: ICE on garbage in DATA statement
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code, error-recovery, monitored
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: reichelt at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2006-06-12 00:02 -------
Okay, your bug report says gcc 4.0.0 and the reported against
field says 4.2.0.  Which is correct, because gfortran does
the right thing with gcc 4.2.0.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[reichelt at gcc dot gnu dot org]

------- Comment #2 from reichelt at gcc dot gnu dot org  2006-06-12 12:45 -------
Well, the "Internal Error" at the end of the eror message doesn't look
like "the right thing" to me:

 Internal Error at (1):
 gfc_get_default_type(): Bad symbol

And this happens since GCC 4.0.0. I.e. GCC 4.0.x, 4.1.x, and mainline
are affected.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2006-06-12 14:23 -------
I don't see the internal error.

laptop:kargl[205] cat > r.f90
      subroutine FOO

      character*20 X  0
      data X /'A'/    0

      end subroutine FOO
laptop:kargl[206] gfc -c r.f90
 In file r.f90:3

      character*20 X  0
                   1
Error: Syntax error in data declaration at (1)
 In file r.f90:4

      data X /'A'/    0
                 1
Error: Syntax error in DATA statement at (1)
 In file r.f90:4

      data X /'A'/    0
             1
Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4)
laptop:kargl[208] gfc -c r.f
 In file r.f:4

      data X /'A'/    0                                                 
                 1
Error: Syntax error in DATA statement at (1)
 In file r.f:4

      data X /'A'/    0                                                 
             1
Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4)
laptop:kargl[209] gfc --version
GNU Fortran 95 (GCC) 4.2.0 20060610 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[reichelt at gcc dot gnu dot org]

------- Comment #4 from reichelt at gcc dot gnu dot org  2006-06-12 15:32 -------
Maybe it's target dependent?
Are you using --enable-checking?

I have

% gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-threads
--enable-checking --prefix=/somepath/gcc-4.2-20060612 --with-gmp=/somepath/GMP
--with-mpfr=/somepath/MPFR
Thread model: posix
gcc version 4.2.0 20060612 (experimental)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #5 from sgk at troutmask dot apl dot washington dot edu  2006-06-12 23:04 -------
Subject: Re:  ICE on garbage in DATA statement

On Mon, Jun 12, 2006 at 03:32:15PM -0000, reichelt at gcc dot gnu dot org
wrote:
>----- Comment #4 from reichelt at gcc dot gnu dot org  2006-06-12 15:32 -------
> Maybe it's target dependent?

I'm guessing this is the case.

> Are you using --enable-checking?

I had not checking on i386-*-freebsd and this morning
I rebuilt with --enable-checking on amd64-*-freebsd.
I do not see the Internal Compiler Error.

troutmask:sgk[203] gfc4x -v
Using built-in specs.
Target: amd64-unknown-freebsd7.0
Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x
--enable-languages=c,fortran --enable-checking
Thread model: posix
gcc version 4.2.0 20060612 (experimental)
troutmask:sgk[204] gfc4x -c l.f90
 In file l.f90:3

      character*20 X  0
                   1
Error: Syntax error in data declaration at (1)
 In file l.f90:4

      data X /'A'/    0
                 1
Error: Syntax error in DATA statement at (1)
 In file l.f90:4

      data X /'A'/    0
             1
Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[reichelt at gcc dot gnu dot org]

------- Comment #6 from reichelt at gcc dot gnu dot org  2006-06-12 23:26 -------
I can reproduce the bug also on i686-pc-linux-gnu.
Does freebsd vs. linux really matter that much here?
Or could GMP or MPFR be the culprit?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #7 from sgk at troutmask dot apl dot washington dot edu  2006-06-13 00:35 -------
Subject: Re:  ICE on garbage in DATA statement

On Mon, Jun 12, 2006 at 11:26:16PM -0000, reichelt at gcc dot gnu dot org
wrote:
> 
> I can reproduce the bug also on i686-pc-linux-gnu.
> Does freebsd vs. linux really matter that much here?
> Or could GMP or MPFR be the culprit?
> 

I doubt it is gmp or mpfr.  There is nothing in
the program that uses either library.  Can you
run the executable under valgrind?  The difference
may be in the memory allocators, which do differ
between linux and freebsd.

Yep.  That's the problem.

troutmask:sgk[211] setenv MALLOC_OPTIONS AJ
troutmask:sgk[213] 
troutmask:sgk[213] gfc4x -c l.f90
 In file l.f90:3

      character*20 X  0
                   1
Error: Syntax error in data declaration at (1)
 In file l.f90:4

      data X /'A'/    0
                 1
Error: Syntax error in DATA statement at (1)
l.f90:0: internal compiler error: Bus error: 10
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #8 from sgk at troutmask dot apl dot washington dot edu  2006-06-13 00:56 -------
Subject: Re:  ICE on garbage in DATA statement

On Mon, Jun 12, 2006 at 05:34:52PM -0700, Steve Kargl wrote:
> On Mon, Jun 12, 2006 at 11:26:16PM -0000, reichelt at gcc dot gnu dot org wrote:
> > 
> > I can reproduce the bug also on i686-pc-linux-gnu.
> > Does freebsd vs. linux really matter that much here?
> > Or could GMP or MPFR be the culprit?
> > 
> 
> I doubt it is gmp or mpfr.  There is nothing in
> the program that uses either library.  Can you
> run the executable under valgrind?  The difference
> may be in the memory allocators, which do differ
> between linux and freebsd.
> 
> Yep.  That's the problem.
> 
> troutmask:sgk[211] setenv MALLOC_OPTIONS AJ
> troutmask:sgk[213] 
> troutmask:sgk[213] gfc4x -c l.f90
>  In file l.f90:3
> 
>       character*20 X  0
>                    1
> Error: Syntax error in data declaration at (1)
>  In file l.f90:4
> 
>       data X /'A'/    0
>                  1
> Error: Syntax error in DATA statement at (1)
> l.f90:0: internal compiler error: Bus error: 10
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
Program received signal SIGBUS, Bus error.
0x00000000004458c3 in gfc_resolve_expr (e=0x201520240)
    at ../../gcc4x/gcc/fortran/resolve.c:2793
2793      if (sym->attr.flavor == FL_PROCEDURE && !sym->attr.function)
(gdb) bt
#0  0x00000000004458c3 in gfc_resolve_expr (e=0x201520240)
    at ../../gcc4x/gcc/fortran/resolve.c:2793
#1  0x0000000000447413 in resolve_data_variables (d=0x2014212c0)
    at ../../gcc4x/gcc/fortran/resolve.c:5867
#2  0x0000000000447671 in resolve_types (ns=0x2014a2000)
    at ../../gcc4x/gcc/fortran/resolve.c:5896
#3  0x0000000000449cbd in gfc_resolve (ns=0x2014a2000)
    at ../../gcc4x/gcc/fortran/resolve.c:6558
#4  0x000000000043f958 in gfc_parse_file ()
    at ../../gcc4x/gcc/fortran/parse.c:3190
#5  0x000000000045e90e in gfc_be_parse_file (set_yydebug=Variable "set_yydebug"
is not available.
)
    at ../../gcc4x/gcc/fortran/f95-lang.c:303
#6  0x000000000074595e in toplev_main (argc=Variable "argc" is not available.
) at ../../gcc4x/gcc/toplev.c:999

--
Steve


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[reichelt at gcc dot gnu dot org]

------- Comment #9 from reichelt at gcc dot gnu dot org  2006-06-16 02:23 -------
Confirmed as the bug was reproduced by Steve.


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-16 02:23:27
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2006-09-11 01:34 -------
Another example showing this is not specific to DATA statements, but is related
to parsing the initilizer.

program FOO
  character*20 Y /'Abcdef'/ garbage
end program FOO

$ gfc pr27954.f90
 In file pr27954.f90:2

  character*20 Y /'Abcdef'/ garbage
                          1
Error: Syntax error in data declaration at (1)
 In file pr27954.f90:3

end program FOO
              1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol

Its interesting that the syntax error is caught, but the following END
statement gets mangled.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-06-16 02:23:27         |2006-09-11 01:34:24
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2006-09-11 01:40 -------
I can coax a segfault out of this:

program FOO
  character*20 Y /'Abcdef'/ 0
  print *, Y
end program FOO

$ gfc pr27954.f90
 In file pr27954.f90:2

  character*20 Y /'Abcdef'/ 0
                          1
Error: Syntax error in data declaration at (1)
pr27954.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2006-10-20 03:24 -------
I believe this is a duplicate of PR18923.  What I am finding is that under some
error conditions, we end up with empty symbols.  When gfc resolve is executed
we are bumping into this arror because the sym->name is equal to '\0'.  With
this patch the call to gfc_get_default_type is avoided and we get a clean exit.
 This begs the question, should these empty symbols be left to begin with. 
This "fixes" both bugs.  I have found another bug, playing with variations on
the test case that gives a similar error in gfc_typename.

Index: symbol.c
===================================================================
--- symbol.c    (revision 117876)
+++ symbol.c    (working copy)
@@ -223,6 +223,9 @@ gfc_set_default_type (gfc_symbol * sym,

   if (sym->ts.type != BT_UNKNOWN)
     gfc_internal_error ("gfc_set_default_type(): symbol already has a type");
+
+  if (*sym->name == '\0')
+    return FAILURE;

   ts = gfc_get_default_type (sym, ns);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2006-10-20 03:26 -------
*** Bug 18923 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Thomas dot Koenig at online
                   |                            |dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2006-10-20 03:54 -------
Another test case with similar error:

program friend
  character*20 y, x 0
  data  y /'abcdef'/, x /'jbnhjk'/ o
  print *, "basketcase"
end program friend

$ gfc pr27954.f90
 In file pr27954.f90:2

  character*20 y, x 0
                  1
Error: Syntax error in data declaration at (1)
 In file pr27954.f90:3

  data  y /'abcdef'/, x /'jbnhjk'/ o
                                   1
Error: Syntax error in DATA statement at (1)
 In file pr27954.f90:6

end program friend
                 1
 Internal Error at (1):
 gfc_typespec(): Undefined type

This actually is error in gfc_typename ()  The error message has a typo in it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[pault at gcc dot gnu dot org]

------- Comment #15 from pault at gcc dot gnu dot org  2006-10-20 04:50 -------
Jerry,

I got your message and will reply later - I have to run for the bus!

I have been aware that there is a problem with empty symbols for some little
while.  Whilst on the way to the lab, I will contemplate how to diagnose it. I
think they arise out of the commit_symbol mechanism but I am not entirely sure.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul dot richard dot thomas
                   |                            |at cea dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[pault at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]



------- Comment #16 from pault at gcc dot gnu dot org  2006-10-20 09:20 -------
The problem is specific to old-style initializers, as 
program FOO
  real :: x = 2.0 q
  real z /2.0/ q
end program FOO
shows (comment out each declaration in turn!).

Grepping on the first error message leads us to decl.c(gfc_match_data_decl).

Proceeding to the Doxygen documentation, we find right away that there is
nothing in the loop over variables that would distinguish old-style data, so
this must happen in variable_decl.

eh voila!
01186       return match_old_style_init (name);

In this function, we find that the gfc_data, it produces, contains an
expression that points to the symtree for the variable. In ALL OTHER error
routes, this gfc_data is freed so that the hanging pointer to the symtree and
to the soon to be non-existent symbol is removed.

match_old_style_init returns SUCCESS and so has hung the gfc_data entry onto
gfc_current_ns->data where it remains until the compiler splutters its last on
trying to swallow it.

Once we figure that, we know right away that this fixes the problem:
Index: gcc/fortran/decl.c
===================================================================
*** gcc/fortran/decl.c  (révision 117879)
--- gcc/fortran/decl.c  (copie de travail)
*************** ok:
*** 2368,2373 ****
--- 2368,2384 ----
    gfc_error ("Syntax error in data declaration at %C");
    m = MATCH_ERROR;

+   /* Check if there are any old fashioned data statements around.
+      If there are, they risk leaving dangling symtree references
+      and do nothing for us since an error has occurred.  */
+   for (;gfc_current_ns->data;)
+     {
+       gfc_data *d;
+       d = gfc_current_ns->data->next;
+       gfc_free (gfc_current_ns->data);
+       gfc_current_ns->data =d;
+     }
+
  cleanup:
    gfc_free_array_spec (current_as);
    current_as = NULL;

This is not checked for breakages or regtested but I believe that it is the
right solution.

It does not fix PR18923 but I think that something similar is at play and could
be investigated in the same way.

(Jerry, I am preparing to depart on a trip; I would be happy if you would
finish off the development of this patch because I cannot return to it for at
least a week.)

Regards

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2006-10-20 14:27 -------
This does not fix it, but I think the idea is in the right direction.  There
are multiple error return paths like this that are not cleaning up enough. 
This explains why making variations on the test case gives several different
errors and results.

I will pursue to completion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2006-10-20 14:33 -------
Correction:  The patch in #16 fixes the case in #11.  However I have several
other variations on this that are taking a different error path.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[pault at gcc dot gnu dot org]

------- Comment #19 from pault at gcc dot gnu dot org  2006-10-20 14:35 -------
Thank goodnessss for that - I thought that I was going batty!

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2006-10-20 16:25 -------
To make you feel better.  I have found the other spots.  Those are fixed as
well and regression tested AOK.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2006-10-27 20:47 -------
Subject: Bug 27954

Author: jvdelisle
Date: Fri Oct 27 20:47:28 2006
New Revision: 118084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118084
Log:
2006-10-27  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/27954
        * decl.c (gfc_free_data_all): New function to free all data structures
        after errors in DATA statements and declarations.
        (top_var_list): Use new function.(top_val_list): Use new function.
        (gfc_match_data_decl): Use new function.
        * misc.c (gfc_typename): Fixed incorrect function name in error text. 

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/misc.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2006-10-27 20:55 -------
Subject: Bug 27954

Author: jvdelisle
Date: Fri Oct 27 20:54:54 2006
New Revision: 118086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118086
Log:
2006-10-27  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libgfortran/27954  Fix type in changelog, pr number
        * gfortran.dg/error_recovery_2.f90: New test.


Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #23 from jvdelisle at gcc dot gnu dot org  2006-10-27 20:58 -------
Fixed on 4.3 Only


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jvdelisle at gcc dot gnu dot org]

------- Comment #24 from jvdelisle at gcc dot gnu dot org  2007-02-04 20:10 -------
*** Bug 30701 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |imre dot bartfai at chello
                   |                            |dot hu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954

[Bug fortran/27954] ICE on garbage in DATA statement

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2007-09-25 10:26 -------
Subject: Bug 27954

Author: jakub
Date: Tue Sep 25 10:26:01 2007
New Revision: 128758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128758
Log:
2006-10-27  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/27954
        * decl.c (gfc_free_data_all): New function to free all data structures
        after errors in DATA statements and declarations.
        (top_var_list): Use new function.(top_val_list): Use new function.
        (gfc_match_data_decl): Use new function.

        PR libgfortran/27954
        * gfortran.dg/error_recovery_2.f90: New test.

Added:
   
branches/redhat/gcc-4_1-branch/gcc/testsuite/gfortran.dg/error_recovery_2.f90
Modified:
    branches/redhat/gcc-4_1-branch/gcc/fortran/ChangeLog
    branches/redhat/gcc-4_1-branch/gcc/fortran/decl.c
    branches/redhat/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954