Bug 1113793

Summary: GFORTRAN compiler seg faults (the compiler, not the code generated) on type defn with old style initializer lists
Product: Red Hat Enterprise Linux 6 Reporter: Rich <rts>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Miroslav Franc <mfranc>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: fritz, mcermak, mfranc, mpolacek, ohudlick, rts
Target Milestone: rc   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: gcc-4.4.7-9.el6 Doc Type: Bug Fix
Doc Text:
Previously, the Fortran compiler could crash when compiling a code that involves invalid old style initialization for derived type components. This has been fixed and the code is now properly rejected with an error message describing the problem.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-14 05:01:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Tarball with an example that demonstrates the seg fault
none
Simplified test case exhibiting seg-fault
none
Quick fix to avoid seg-faulting in this case none

Description Rich 2014-06-26 23:20:49 UTC
Created attachment 912600 [details]
Tarball with an example that demonstrates the seg fault

Description of problem:

When compiling a small but non-trivial program with GFORTRAN, it simply 
seg faults (during compilation) without any indication of the problem.
Here's a quick view of the compile line:


% gfortran -I./inc -g -fcray-pointer -ffixed-line-length-132 -fdollar-ok  -funderscoring -D_LINX -D_UNIX -fPIC -fpack-derived -ffixed-line-length-132  -finit-local-zero  -c zpipe.f
zpipe.f:28: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make: *** [zpipe.o] Error 1



Version-Release number of selected component (if applicable):

I tried this out on two GFORTRAN compilers:
GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
(A redhat 6 box)

And

GNU Fortran (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)
(A Fedora release 20 box)

How reproducible:

Always.

Steps to Reproduce:
1.Run the makefile (%make zpipe.o)
2.... this tries to compile zpipe.c to a .o
3.... notice the seg fault

Actual results:
===========================================================================
( ~/FORTRANA/testing/bug_report )
brhazrts % make zpipe.o 
gfortran -I./inc -g -fcray-pointer -ffixed-line-length-132 -fdollar-ok  -funderscoring -D_LINX -D_UNIX -fPIC -fpack-derived -ffixed-line-length-132  -finit-local-zero  -c zpipe.f
zpipe.f:28: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make: *** [zpipe.o] Error 1
===========================================================================

Expected results:

This is what I get when I compile under Intel's ifort:
===============================================================================
brhazrts % make -f Makefile.intel zpipe.o
ifort -I./inc -D_LINX -D_UNIX -fpp -fPIC -noalign -extend_source -WB -zero  -c zpipe.f
./inc/qmessdef.inc(13): error #6669: The specification of this object is invalid.
        integer*2 nslots/34/
------------------^
./inc/qmessdef.inc(14): error #6669: The specification of this object is invalid.
        character*1 type/'H'/
--------------------^
===========================================================================


Additional info:

It looks like the GFORTRAN doesn't give me a good syntax error inside a TYPE
definition if I try to use "old style" default values for members of the 
struct.

   TYPE something
    integer*2 nslots/34/     ! DOESn'T work in ifort, and GFORTRAN
   ENDTYPE

But, the new style will work:

   TYPE something
    integer*2 ::nslots=34
   ENDTYPE


It may be illegal code and it may not (it depends on if GFORTRAN is supposed to compile the old style initializing lists), but it definitely shouldn't be a seg fault.

I am including an attachment, with the code and both the Makefile (which uses
the GFORTRAN compiler) and Makefile.intel (which uses ifort).  zpipe.f is the
offending program, but the problem *probably* happens down in the inc/qmessdef.inc

Type:

  make zpipe.o   # to see the seg fault

or
  make -f Makefile.intel   # to see what ifort gives us

See attached.

Comment 1 Rich 2014-06-26 23:28:49 UTC
That should be:

 % make -f Makefile.intel zpipe.o 

To see what ifort reports as the syntax error.

Comment 3 Fritz Reese 2014-06-27 18:46:35 UTC
Created attachment 912913 [details]
Simplified test case exhibiting seg-fault

This is an explicit test case which causes the segmentation fault in gfortran as described in bug 1113793. It can be run with no additional flags (i.e. `gfortran test.f`).

Comment 4 Fritz Reese 2014-06-27 18:49:31 UTC
Comment on attachment 912913 [details]
Simplified test case exhibiting seg-fault

The segmentation fault occurrs when an old-style initialization is present within a derived type declaration. 

The internal function which handles old-style initializations as part of a variable declaration fails to handle the case when the variable being declared is a derived type component.

Comment 5 Fritz Reese 2014-06-27 19:30:17 UTC
Created attachment 912938 [details]
Quick fix to avoid seg-faulting in this case

This is a simple patch for gfortran v4.8.3 (and likely other versions) which throws a syntax error when old-style initializations are used in a derived-type component declaration (thereby avoiding a segmentation fault).

This behavior is justified by the behavior of ifort v11.1+ (the Intel FORTRAN compiler). The Intel compiler also throws a syntax error for attachment 912913 [details] (test.f).

If old-style initializations should be parsed and resolved like standard initializations, the feature should probably be enabled only as a GNU extension. Some additional work may have to be done in gcc/fortran/decl.c, either in match_old_style_init() or variable_decl().


The patch can be applied with the following command from the top-level source directory (e.g. /..../src/gcc-4.8.3/):

patch -p0 < b1113793.patch

Comment 6 Jakub Jelinek 2014-07-01 14:54:48 UTC
I think it is fine to reject it, though with your patch you'll leak as memory in the caller.  Here is an alternative (so far untested) patch:

2014-07-01  Jakub Jelinek  <jakub>
	    Fritz Reese  <Reese-Fritz>

	* decl.c (variable_decl): Reject old style initialization
	for derived type components.

	* gfortran.dg/oldstyle_5.f: New test.

--- gcc/fortran/decl.c.jj	2014-06-30 09:28:50.000000000 +0200
+++ gcc/fortran/decl.c	2014-07-01 16:47:19.466050044 +0200
@@ -1997,6 +1997,13 @@ variable_decl (int elem)
       if (!gfc_notify_std (GFC_STD_GNU, "Old-style "
 			   "initialization at %C"))
 	return MATCH_ERROR;
+      else if (gfc_current_state () == COMP_DERIVED)
+	{
+	  gfc_error ("Invalid old style initialization for derived type "
+		     "component at %C");
+	  m = MATCH_ERROR;
+	  goto cleanup;
+	}
 
       return match_old_style_init (name);
     }
--- gcc/testsuite/gfortran.dg/oldstyle_5.f.jj	2014-07-01 16:50:40.449001427 +0200
+++ gcc/testsuite/gfortran.dg/oldstyle_5.f	2014-07-01 16:48:33.000000000 +0200
@@ -0,0 +1,8 @@
+C { dg-do compile }
+      TYPE T
+      INTEGER A(2)/1,2/ ! { dg-error "Invalid old style initialization for derived type component" }
+      END TYPE
+      TYPE S
+      INTEGER B/1/ ! { dg-error "Invalid old style initialization for derived type component" }
+      END TYPE
+      END

Comment 7 Jakub Jelinek 2014-07-02 09:50:31 UTC
Committed: http://gcc.gnu.org/r212227 , http://gcc.gnu.org/r212228 , http://gcc.gnu.org/r212229 .  Backportable to 4.4-RH.

Comment 11 errata-xmlrpc 2014-10-14 05:01:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1377.html