[Bug fortran/49278] New: internal compiler error: Segmentation fault

[Bug fortran/49278] New: internal compiler error: Segmentation fault

[petrielmjr at ornl dot gov]

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

           Summary: internal compiler error: Segmentation fault
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: petrielmjr@ornl.gov


Created attachment 24426
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24426
The attachment has the gfortran version, system, command line, command output,
and source file

The source in the attachment causes an ICC.

[Bug fortran/49278] internal compiler error: Segmentation fault

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
      Known to fail|                            |4.3.6, 4.4.7, 4.5.3, 4.6.1,
                   |                            |4.7.0

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-03 16:07:45 UTC ---
Reduced testcase.

module oad_active
   implicit none
   type active
      sequence
      real :: v 
      real :: d =0.
   end type
end module

module tots_c
   use oad_active
   implicit none
   type(active), save :: trlkold
   data trlkold%v /0./
end module

[Bug fortran/49278] internal compiler error: Segmentation fault

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-06-03 18:10:40 UTC ---
On Fri, Jun 03, 2011 at 04:08:05PM +0000, kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
> 
> Reduced testcase.
> 
> module oad_active
>    implicit none
>    type active
>       sequence
>       real :: v 
>       real :: d =0.
>    end type
> end module
> 
> module tots_c
>    use oad_active
>    implicit none
>    type(active), save :: trlkold
>    data trlkold%v /0./
> end module
> 

This simply patch fixes the segfault with the compiler.

Index: trans-expr.c
===================================================================
--- trans-expr.c        (revision 174566)
+++ trans-expr.c        (working copy)
@@ -4638,7 +4638,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
   cm = expr->ts.u.derived->components;

   for (c = gfc_constructor_first (expr->value.constructor);
-       c; c = gfc_constructor_next (c), cm = cm->next)
+       c && cm; c = gfc_constructor_next (c), cm = cm->next)
     {
       /* Skip absent members in default initializers and allocatable
         components.  Although the latter have a default initializer


It's not clear if it achieves the desired result.  The following
aborts.  Note sure if it is conforming.

module oad_active
   implicit none
   type active
      integer :: v 
      integer :: d = 42
   end type
end module

module tots_c
   use oad_active
   implicit none
   type(active), save :: trlkold
   data trlkold%v /100/
end module

program foo
   use tots_c
   implicit none
   if (trlkold%d /= 42) call abort
   if (trlkold%v /= 100) call abort
end program foo

[Bug fortran/49278] internal compiler error: Segmentation fault

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-06 08:22:53 UTC ---
(In reply to comment #2)
> The following aborts.  Note sure if it is conforming.

* ifort (also w/ "-stand f03 -warn all") and PGI accept it - and have the
expected value

* NAG 5.1 and g95 have %d == 0, i.e. the explicit DATA initialization prevents
the default initialization of trlkold.

* pathf95/openf95/crayftn/sunf95 reject the DATA because there is a default
initialization


It's actually a difficult to see whether it is invalid or not. However, I think
the code is valid (taking the side of NAG and g95): One does not do any double
initialization. From the F2008 standard:

"If a nonpointer object has default initialization, it shall not appear in a
data-stmt-object-list." (5.4.7 DATA statement) -- Does not seem to apply as
"trlkold%v" is not default initialized.

"5.2.3 Initialization":
"Explicit initialization alternatively may be specified in a DATA statement
unless the variable is of a derived type for which default initialization is
specified." -- Ditto.
"A variable, or part of a variable, shall not be explicitly initialized more
than once in a program." -- Also this is not violated.


Hence, it seems to be valid, but I wouldn't mind if someone could cross check,
given that most compilers don't generate the expected result - and given that
reading the standard can be difficult. [Even J3/WG5 members might read it
differently.]

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-07 09:17:05 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > The following aborts.  Note sure if it is conforming.

> Hence, it seems to be valid, but I wouldn't mind if someone could cross check

I have now asked at c.l.f:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8d3b9a3813ef914a#

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-08 05:55:26 UTC ---
(In reply to comment #4)
> I have now asked at c.l.f:

Richard and Dick think the standard is very unclear; they are slightly inclined
to conclude that it is invalid, but suggest to fill an interpretation request,
which I will do.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-14 12:32:02 UTC ---
I have now filled an interpretation request (J3/11-201) - in time for WG5 and
J3 meeting (m195), which is end of June. Let's see what J3/WG5 will decide. Cf.
http://j3-fortran.org/doc/meeting/195/11-201.txt [Remember: Updates will be put
in files named "11-201r1.txt", ...r2.txt, etc.]

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[thenlich at users dot sourceforge.net]

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

Thomas Henlich <thenlich at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thenlich at users dot
                   |                            |sourceforge.net

--- Comment #7 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-30 12:26:30 UTC ---
J3 subgroup has answered this:

http://j3-fortran.org/doc/meeting/195/11-201r1.txt

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.30 12:33:12
     Ever Confirmed|0                           |1

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-30 12:33:12 UTC ---
(In reply to comment #7)
> J3 subgroup has answered this:
> http://j3-fortran.org/doc/meeting/195/11-201r1.txt

Thanks. In a nutshell: It is invalid - the standard does not allow to combine
partial default-initialization with partial DATA initialization.

It is not a constraint, hence, the compiler is not required to diagnose it, but
I think it should - rather than ICEing ...

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
           Keywords|                            |ice-on-valid-code,
                   |                            |wrong-code

--- Comment #21 from anlauf at gcc dot gnu.org ---
There's also valid code that ICEs, and invalid code that is silently accepted.

Invalid code:

program p
  implicit none
  integer, parameter :: b = 1
  data b / 2 /
  print *, b
end

Instead of being rejected, this prints:
           1

One could catch this one in gfc_assign_data_value, but I haven't found out
yet how to get this right with derived type components, so there's possibly
a better place.

And after fixing an obvious NULL pointer dereference,

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 37a0c85fa30..783a0bbddcc 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr, gfc_typespec
*ts, bool array,
        return false;
       cm = expr->ts.u.derived->components;
       for (c = gfc_constructor_first (expr->value.constructor);
-          c; c = gfc_constructor_next (c), cm = cm->next)
+          c && cm; c = gfc_constructor_next (c), cm = cm->next)
        {
          if (!c->expr || cm->attr.allocatable)
            continue;

we arrive at wrong code on valid input:

program p
  implicit none
  type t
     real :: a
  end type t
  type(t) :: z = t(4.0)
  data z%a /3.0/
  print *, z%a
end

This now prints
   4.00000000

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
The -fdump-fortran-original of the last example in comment#21 contains

  symtree: 'z'           || symbol: 'z'            
    type spec : (DERIVED t)
    attributes: (VARIABLE IMPLICIT-SAVE DATA)
    value: t(4.00000000 , 3.00000000)

so perhaps we should properly overwrite or merge with the default initializer
instead of appending?

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #23 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> There's also valid code that ICEs, and invalid code that is silently
> accepted.
> 
> Invalid code:
> 
> program p
>   implicit none
>   integer, parameter :: b = 1
>   data b / 2 /
>   print *, b
> end
> 
> Instead of being rejected, this prints:
>            1

You need know about gfortran's extensions.

% gfcx -Wall -o z -std=f95 a.f90
a.f90:4:12:

    4 |   data b / 2 /
      |            1
Error: GNU Extension: re-initialization of 'b' at (1)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org]

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

--- Comment #24 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> 
> And after fixing an obvious NULL pointer dereference,
> 
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 37a0c85fa30..783a0bbddcc 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr,
> gfc_typespec *ts, bool array,
>         return false;
>        cm = expr->ts.u.derived->components;
>        for (c = gfc_constructor_first (expr->value.constructor);
> -          c; c = gfc_constructor_next (c), cm = cm->next)
> +          c && cm; c = gfc_constructor_next (c), cm = cm->next)
>         {
>           if (!c->expr || cm->attr.allocatable)
>             continue;
> 

Looks like the patch from comment #2 that I posted 9 years ago. LoL.
Bug must not hit real code too often as no one has fixed it.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #24)
> (In reply to anlauf from comment #21)

> Looks like the patch from comment #2 that I posted 9 years ago. LoL.
> Bug must not hit real code too often as no one has fixed it.

Well, there are multiple places with almost identical un-code.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #23)
> (In reply to anlauf from comment #21)
> > There's also valid code that ICEs, and invalid code that is silently
> > accepted.
> > 
> > Invalid code:
> > 
> > program p
> >   implicit none
> >   integer, parameter :: b = 1
> >   data b / 2 /
> >   print *, b
> > end
> > 
> > Instead of being rejected, this prints:
> >            1
> 
> You need know about gfortran's extensions.
> 
> % gfcx -Wall -o z -std=f95 a.f90
> a.f90:4:12:
> 
>     4 |   data b / 2 /
>       |            1
> Error: GNU Extension: re-initialization of 'b' at (1)

I hope you noticed the PARAMETER, which should have been caught by
-fno-writable-parameters ... ;-)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[kargl at gcc dot gnu.org]

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

--- Comment #27 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #26)
> (In reply to kargl from comment #23)
> > (In reply to anlauf from comment #21)
> > > There's also valid code that ICEs, and invalid code that is silently
> > > accepted.
> > > 
> > > Invalid code:
> > > 
> > > program p
> > >   implicit none
> > >   integer, parameter :: b = 1
> > >   data b / 2 /
> > >   print *, b
> > > end
> > > 
> > > Instead of being rejected, this prints:
> > >            1
> > 
> > You need know about gfortran's extensions.
> > 
> > % gfcx -Wall -o z -std=f95 a.f90
> > a.f90:4:12:
> > 
> >     4 |   data b / 2 /
> >       |            1
> > Error: GNU Extension: re-initialization of 'b' at (1)
> 
> I hope you noticed the PARAMETER, which should have been caught by
> -fno-writable-parameters ... ;-)

Yes, I did.  Hopefully, you noticed the word EXTENSION.  As an 
extension, gfortran swallows the code. :-)

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

--- Comment #28 from anlauf at gcc dot gnu.org ---
Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part:

https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:bd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61

commit r11-7564-gbd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Mon Mar 8 21:59:20 2021 +0100

    PR fortran/49278 - ICE when combining DATA with default initialization

    A variable with the PARAMETER attribute may not appear in a DATA statement.

    gcc/fortran/ChangeLog:

            PR fortran/49278
            * data.c (gfc_assign_data_value): Reject variable with PARAMETER
            attribute in DATA statement.

    gcc/testsuite/ChangeLog:

            PR fortran/49278
            * gfortran.dg/parameter_data.f90: New test.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[zeccav at gmail dot com]

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

--- Comment #30 from Vittorio Zecca <zeccav at gmail dot com> ---
On the following source code I still have the ICE:

      type t
       integer g
      end type
      type(t) :: u=t(1)
      data u%g /2/ ! should emit diagnostic here
      end

gfortran -S gfbug63.f
gfbug63.f:6:72:

    6 |       type t
      |                                                                       
1
internal compiler error: Segmentation fault
0xe7a01f crash_signal
        ../../gcc-150221/gcc/toplev.c:327
0x94a42d gfc_conv_structure(gfc_se*, gfc_expr*, int)
        ../../gcc-150221/gcc/fortran/trans-expr.c:8746
0x94a01f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
        ../../gcc-150221/gcc/fortran/trans-expr.c:7895
0x92ed34 gfc_get_symbol_decl(gfc_symbol*)
        ../../gcc-150221/gcc/fortran/trans-decl.c:1917
0x931c03 generate_local_decl
        ../../gcc-150221/gcc/fortran/trans-decl.c:5950
0x8ead22 do_traverse_symtree
        ../../gcc-150221/gcc/fortran/symbol.c:4170
0x932d93 generate_local_vars
        ../../gcc-150221/gcc/fortran/trans-decl.c:6156
0x932d93 gfc_generate_function_code(gfc_namespace*)
        ../../gcc-150221/gcc/fortran/trans-decl.c:6815
0x8afaee translate_all_program_units
        ../../gcc-150221/gcc/fortran/parse.c:6351
0x8afaee gfc_parse_file()
        ../../gcc-150221/gcc/fortran/parse.c:6620
0x90112f gfc_be_parse_file
        ../../gcc-150221/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[anlauf at gcc dot gnu.org]

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
I've just checked the various comments.

What's left:

- comment#2 : the testcase still fails.  See also comment#7 about the invalid
  partial initialization

- lack of diagnostics of overlapping initialization

There is also some overlap with pr50410.

The ICEs appear fixed, in particular the one in comment#31.