diff mbox

PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

Message ID 20161208021434.GA53267@troutmask.apl.washington.edu
State New
Headers show

Commit Message

Steve Kargl Dec. 8, 2016, 2:14 a.m. UTC 
All,

The attach patch fixes an ICE from a testcase in PR fortran/65173.

First, I draw your attention to the comment in gfortran.h above
the definition of gfc_charlen.  It is

/* Character length structures hold the expression that gives the
   length of a character variable.  We avoid putting these into
   gfc_typespec because doing so prevents us from doing structure
   copies and forces us to deallocate any typespecs we create, as well
   as structures that contain typespecs.  They also can have multiple
   character typespecs pointing to them.

   These structures form a singly linked list within the current
   namespace and are deallocated with the namespace.  It is possible to
   end up with gfc_charlen structures that have nothing pointing to them.  */

The last paragraph is important, here.  So, the problematic code was 

program foo
   type t
     character, allocatable :: z1(:), z1(:)
   end type t
end program foo

gfortran rightly rejected this code and issues an appropriate error.
However, when parse.c (reject_statement) tries to cleanup the parsing
of the invalid statement, it manages to corrupt the namespace's cl_list.
How? Well, that's a good question on which I wasted too much time given 
the last paragraph in the gfortran.h comment.  Removing the manipulations
of the cl_list in reject_statement, then revealed that old_cl_list is
unneeded.  So, I give unto you

2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/65173
	* gfortran.h (gfc_namespace): Remove old_cl_list member.
	* parse.c (use_modules, next_statement): old_cl_list is gone.
	(clear_default_charlen): Remove no longer used function.
	(reject_statement): Do not try to clean up gfc_charlen structure(s)
	that may have been added to a cl_list list.
	* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/65173
	* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
	* gfortran.dg/pr65173.f90: New test.

The patch is attached and regression tested on x86_64-*-freebsd.
OK to commit?

-- 
Steve

Comments

Steve Kargl Dec. 8, 2016, 3:55 a.m. UTC | #1 
On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:
> 

> 2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

> 

> 	PR fortran/65173

> 	* gfortran.h (gfc_namespace): Remove old_cl_list member.

> 	* parse.c (use_modules, next_statement): old_cl_list is gone.

> 	(clear_default_charlen): Remove no longer used function.

> 	(reject_statement): Do not try to clean up gfc_charlen structure(s)

> 	that may have been added to a cl_list list.

> 	* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

> 


Appears to fix PR fortran/78350 as well.

-- 
Steve
Steve Kargl Dec. 8, 2016, 4:51 a.m. UTC | #2 
On Wed, Dec 07, 2016 at 07:55:01PM -0800, Steve Kargl wrote:
> On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:

> > 

> > 2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

> > 

> > 	PR fortran/65173

> > 	* gfortran.h (gfc_namespace): Remove old_cl_list member.

> > 	* parse.c (use_modules, next_statement): old_cl_list is gone.

> > 	(clear_default_charlen): Remove no longer used function.

> > 	(reject_statement): Do not try to clean up gfc_charlen structure(s)

> > 	that may have been added to a cl_list list.

> > 	* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

> > 

> 

> Appears to fix PR fortran/78350 as well.

  Appears to fix PR fortran/69859 as well.

-- 
Steve
Steve Kargl Dec. 8, 2016, 5:10 a.m. UTC | #3 
On Wed, Dec 07, 2016 at 08:51:11PM -0800, Steve Kargl wrote:
> On Wed, Dec 07, 2016 at 07:55:01PM -0800, Steve Kargl wrote:

> > On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:

> > > 

> > > 2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

> > > 

> > > 	PR fortran/65173

> > > 	* gfortran.h (gfc_namespace): Remove old_cl_list member.

> > > 	* parse.c (use_modules, next_statement): old_cl_list is gone.

> > > 	(clear_default_charlen): Remove no longer used function.

> > > 	(reject_statement): Do not try to clean up gfc_charlen structure(s)

> > > 	that may have been added to a cl_list list.

> > > 	* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

> > > 

> > 

> > Appears to fix PR fortran/78350 as well.

>   Appears to fix PR fortran/69859 as well.

    Appears to fix PR fortran/69064 (although I had no intention to ever
    fix this PR.  Sigh, accidence happens).

-- 
Steve
Paul Richard Thomas Dec. 8, 2016, 6:58 a.m. UTC | #4 
Hi Steve,

"Accidence" == state of fixing non-deterministic ICEs? :-)

OK for trunk.

Thanks for dealing with this kind of dead wood.

Cheers

Paul


On 8 December 2016 at 06:10, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Wed, Dec 07, 2016 at 08:51:11PM -0800, Steve Kargl wrote:

>> On Wed, Dec 07, 2016 at 07:55:01PM -0800, Steve Kargl wrote:

>> > On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:

>> > >

>> > > 2016-12-07  Steven G. Kargl  <kargl@gcc.gnu.org>

>> > >

>> > >   PR fortran/65173

>> > >   * gfortran.h (gfc_namespace): Remove old_cl_list member.

>> > >   * parse.c (use_modules, next_statement): old_cl_list is gone.

>> > >   (clear_default_charlen): Remove no longer used function.

>> > >   (reject_statement): Do not try to clean up gfc_charlen structure(s)

>> > >   that may have been added to a cl_list list.

>> > >   * symbol.c (gfc_new_charlen): old_cl_list structure is gone.

>> > >

>> >

>> > Appears to fix PR fortran/78350 as well.

>>   Appears to fix PR fortran/69859 as well.

>     Appears to fix PR fortran/69064 (although I had no intention to ever

>     fix this PR.  Sigh, accidence happens).

>

> --

> Steve




-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama
Steve Kargl Dec. 8, 2016, 9:33 p.m. UTC | #5 
On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:
> 

> "Accidence" == state of fixing non-deterministic ICEs? :-)

> 

> OK for trunk.

> 

> Thanks for dealing with this kind of dead wood.

> 


Committed revision 243463.

-- 
Steve
Paul Richard Thomas Dec. 9, 2016, 11:47 a.m. UTC | #6 
Hi Steve,

In doing the final regtest of the fix for PR44265, I found that
charlen_15.f90 is still giving the original error for PR78350.

module.c:3419 is seeing (after continuing three times)
(gdb) print *e->ts.u.cl->length
$12 = {expr_type = 0, ts = {type = 81, kind = 0, u = {derived = 0x20ff570,
      cl = 0x20ff570, pad = 34600304}, interface = 0x20ff340,
    is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false},
  rank = 0, shape = 0x20fe310, symtree = 0x0, ref = 0x0, where = {
    nextc = 0x50, lb = 0x50}, base_expr = 0x20fe5e0, is_boz = 0, is_snan = 0,
  error = 0, user_operator = 0, mold = 0, must_finalize = 0, representation = {
    length = 4096, string = 0x7ffff1a68000 "\002"}, value = {logical = 471,
    iokind = 471, integer = {{_mp_alloc = 471, _mp_size = 0,
        _mp_d = 0x41006600000000}}, real = {{_mpfr_prec = 471, _mpfr_sign = 0,
        _mpfr_exp = -1, _mpfr_d = 0x7fffffffff}}, complex = {{re = {{
            _mpfr_prec = 471, _mpfr_sign = 0, _mpfr_exp = -1,
            _mpfr_d = 0x7fffffffff}}, im = {{_mpfr_prec = 0, _mpfr_sign = 241,
            _mpfr_exp = 214358001816, _mpfr_d = 0x2100100}}}}, op = {op = 471,
      uop = 0x41006600000000, op1 = 0xffffffffffffffff, op2 = 0x7fffffffff},
    function = {actual = 0x1d7,
      name = 0x41006600000000 <Address 0x41006600000000 out of bounds>,
      isym = 0xffffffffffffffff, esym = 0x7fffffffff}, compcall = {
      actual = 0x1d7,
      name = 0x41006600000000 <Address 0x41006600000000 out of bounds>,
      base_object = 0xffffffffffffffff, tbp = 0x7fffffffff, ignore_pass = 0,
      assign = 0}, character = {length = 471, string = 0x41006600000000},
    constructor = 0x1d7}}

It is the expr_type == = that causes the ICE in gfc_code2string.

Cheers

Paul

On 8 December 2016 at 22:33, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:

>>

>> "Accidence" == state of fixing non-deterministic ICEs? :-)

>>

>> OK for trunk.

>>

>> Thanks for dealing with this kind of dead wood.

>>

>

> Committed revision 243463.

>

> --

> Steve




-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama
Janne Blomqvist Dec. 9, 2016, 11:54 a.m. UTC | #7 
On Fri, Dec 9, 2016 at 1:47 PM, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Hi Steve,

>

> In doing the final regtest of the fix for PR44265, I found that

> charlen_15.f90 is still giving the original error for PR78350.

>

> module.c:3419 is seeing (after continuing three times)

> (gdb) print *e->ts.u.cl->length

> $12 = {expr_type = 0, ts = {type = 81, kind = 0, u = {derived = 0x20ff570,

>       cl = 0x20ff570, pad = 34600304}, interface = 0x20ff340,

>     is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false},

>   rank = 0, shape = 0x20fe310, symtree = 0x0, ref = 0x0, where = {

>     nextc = 0x50, lb = 0x50}, base_expr = 0x20fe5e0, is_boz = 0, is_snan = 0,

>   error = 0, user_operator = 0, mold = 0, must_finalize = 0, representation = {

>     length = 4096, string = 0x7ffff1a68000 "\002"}, value = {logical = 471,

>     iokind = 471, integer = {{_mp_alloc = 471, _mp_size = 0,

>         _mp_d = 0x41006600000000}}, real = {{_mpfr_prec = 471, _mpfr_sign = 0,

>         _mpfr_exp = -1, _mpfr_d = 0x7fffffffff}}, complex = {{re = {{

>             _mpfr_prec = 471, _mpfr_sign = 0, _mpfr_exp = -1,

>             _mpfr_d = 0x7fffffffff}}, im = {{_mpfr_prec = 0, _mpfr_sign = 241,

>             _mpfr_exp = 214358001816, _mpfr_d = 0x2100100}}}}, op = {op = 471,

>       uop = 0x41006600000000, op1 = 0xffffffffffffffff, op2 = 0x7fffffffff},

>     function = {actual = 0x1d7,

>       name = 0x41006600000000 <Address 0x41006600000000 out of bounds>,

>       isym = 0xffffffffffffffff, esym = 0x7fffffffff}, compcall = {

>       actual = 0x1d7,

>       name = 0x41006600000000 <Address 0x41006600000000 out of bounds>,

>       base_object = 0xffffffffffffffff, tbp = 0x7fffffffff, ignore_pass = 0,

>       assign = 0}, character = {length = 471, string = 0x41006600000000},

>     constructor = 0x1d7}}

>

> It is the expr_type == = that causes the ICE in gfc_code2string.


I'm seeing the same thing, I guess. Or rather that the ts->type == 81
which is non-sensical. No idea where that comes from..

Backtrace from gdb:

#0  gfc_code2string (m=m@entry=0x182fe00 <bt_types>,
code=code@entry=81) at ../../trunk-git/gcc/fortran/misc.c:193
#1  0x000000000065645f in mio_name (t=81, m=m@entry=0x182fe00
<bt_types>) at ../../trunk-git/gcc/fortran/module.c:1722
#2  0x000000000065acb9 in mio_name_bt (m=0x182fe00 <bt_types>,
t=<optimized out>) at ../../trunk-git/gcc/fortran/module.c:2106
#3  mio_typespec (ts=ts@entry=0x2420918) at
../../trunk-git/gcc/fortran/module.c:2530
#4  0x000000000065ae50 in mio_expr (ep=0x24217d0) at
../../trunk-git/gcc/fortran/module.c:3432
#5  0x000000000065b300 in mio_charlen (clp=clp@entry=0x241fa80) at
../../trunk-git/gcc/fortran/module.c:2500
#6  0x000000000065ad50 in mio_typespec (ts=ts@entry=0x241fa78) at
../../trunk-git/gcc/fortran/module.c:2558
#7  0x000000000065ae50 in mio_expr (ep=ep@entry=0x24208a8) at
../../trunk-git/gcc/fortran/module.c:3432
#8  0x000000000065bb73 in mio_component (c=c@entry=0x2420830,
vtype=vtype@entry=0) at ../../trunk-git/gcc/fortran/module.c:2799
#9  0x000000000065bbdb in mio_component_list (cp=cp@entry=0x2422138,
vtype=0) at ../../trunk-git/gcc/fortran/module.c:2818
#10 0x000000000065c913 in mio_symbol (sym=sym@entry=0x2422090) at
../../trunk-git/gcc/fortran/module.c:4238
#11 0x000000000065cb8b in write_symbol (n=2, sym=sym@entry=0x2422090)
at ../../trunk-git/gcc/fortran/module.c:5613
#12 0x000000000065e87f in write_symbol0 (st=0x2422680) at
../../trunk-git/gcc/fortran/module.c:5653
#13 0x000000000065e7f2 in write_symbol0 (st=0x2420650) at
../../trunk-git/gcc/fortran/module.c:5632
#14 0x000000000065ea03 in write_module () at
../../trunk-git/gcc/fortran/module.c:5992
#15 0x000000000065ec59 in dump_module (name=name@entry=0x7ffff6853060
"m", dump_flag=dump_flag@entry=1) at
../../trunk-git/gcc/fortran/module.c:6120
#16 0x000000000065edf8 in gfc_dump_module (name=0x7ffff6853060 "m",
dump_flag=1) at ../../trunk-git/gcc/fortran/module.c:6163
#17 0x0000000000675edd in gfc_parse_file () at
../../trunk-git/gcc/fortran/parse.c:6158
#18 0x00000000006baa5b in gfc_be_parse_file () at
../../trunk-git/gcc/fortran/f95-lang.c:202
#19 0x0000000000ce0456 in compile_file () at ../../trunk-git/gcc/toplev.c:463
#20 0x0000000000ce240d in do_compile () at ../../trunk-git/gcc/toplev.c:1983
#21 0x0000000000ce2934 in toplev::main
(this=this@entry=0x7fffffffd860, argc=argc@entry=13,
argv=argv@entry=0x7fffffffd968) at ../../trunk-git/gcc/toplev.c:2117
#22 0x00000000016fc99c in main (argc=13, argv=0x7fffffffd968) at
../../trunk-git/gcc/main.c:39


>

> Cheers

>

> Paul

>

> On 8 December 2016 at 22:33, Steve Kargl

> <sgk@troutmask.apl.washington.edu> wrote:

>> On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:

>>>

>>> "Accidence" == state of fixing non-deterministic ICEs? :-)

>>>

>>> OK for trunk.

>>>

>>> Thanks for dealing with this kind of dead wood.

>>>

>>

>> Committed revision 243463.

>>

>> --

>> Steve

>

>

>

> --

> If you're walking down the right path and you're willing to keep

> walking, eventually you'll make progress.

>

> Barack Obama




-- 
Janne Blomqvist
Andreas Schwab Dec. 9, 2016, 1:46 p.m. UTC | #8 
FAIL: gfortran.dg/charlen_15.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/charlen_15.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/charlen_15.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/charlen_15.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/charlen_15.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/charlen_15.f90   -Os  (internal compiler error)

spawn -ignore SIGHUP /opt/gcc/gcc-20161209/Build/gcc/testsuite/gfortran1/../../gfortran -B/opt/gcc/gcc-20161209/Build/gcc/testsuite/gfortran1/../../ -B/opt/gcc/gcc-20161209/Build/aarch64-suse-linux/./libgfortran/ /opt/gcc/gcc-20161209/gcc/testsuite/gfortran.dg/charlen_15.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -pedantic-errors -B/opt/gcc/gcc-20161209/Build/aarch64-suse-linux/./libgfortran/.libs -L/opt/gcc/gcc-20161209/Build/aarch64-suse-linux/./libgfortran/.libs -L/opt/gcc/gcc-20161209/Build/aarch64-suse-linux/./libgfortran/.libs -L/opt/gcc/gcc-20161209/Build/aarch64-suse-linux/./libatomic/.libs -lm -o ./charlen_15.exe
f951: internal compiler error: gfc_code2string(): Bad code
0x6231f3 gfc_internal_error(char const*, ...)
        ../../gcc/fortran/error.c:1328
0x65b563 gfc_code2string(mstring const*, int)
        ../../gcc/fortran/misc.c:193
0x65cfcb mio_name
        ../../gcc/fortran/module.c:1725
0x660847 mio_name_expr_t
        ../../gcc/fortran/module.c:2095
0x660847 mio_expr
        ../../gcc/fortran/module.c:3400
0x660f1f mio_charlen
        ../../gcc/fortran/module.c:2488
0x66104f mio_typespec
        ../../gcc/fortran/module.c:2546
0x66084f mio_expr
        ../../gcc/fortran/module.c:3419
0x66137b mio_component
        ../../gcc/fortran/module.c:2787
0x662573 mio_component_list
        ../../gcc/fortran/module.c:2806
0x662573 mio_symbol
        ../../gcc/fortran/module.c:4223
0x662687 write_symbol
        ../../gcc/fortran/module.c:5598
0x66285b write_symbol0
        ../../gcc/fortran/module.c:5638
0x66279f write_symbol0
        ../../gcc/fortran/module.c:5617
0x66508f write_module
        ../../gcc/fortran/module.c:5977
0x66508f dump_module
        ../../gcc/fortran/module.c:6105
0x665457 gfc_dump_module(char const*, int)
        ../../gcc/fortran/module.c:6148
0x67d287 gfc_parse_file()
        ../../gcc/fortran/parse.c:6158
0x6c2b0f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:202

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab Dec. 9, 2016, 2:18 p.m. UTC | #9 
FAIL: gfortran.dg/charlen_03.f90   -O  (internal compiler error)
FAIL: gfortran.dg/charlen_10.f90   -O  (internal compiler error)

spawn -ignore SIGHUP /usr/local/gcc/gcc-20161209/Build/gcc/testsuite/gfortran5/../../gfortran -B/usr/local/gcc/gcc-20161209/Build/gcc/testsuite/gfortran5/../../ -B/usr/local/gcc/gcc-20161209/Build/ia64-suse-linux/./libgfortran/ /usr/local/gcc/gcc-20161209/gcc/testsuite/gfortran.dg/charlen_03.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O -pedantic-errors -S -o charlen_03.s
/usr/local/gcc/gcc-20161209/gcc/testsuite/gfortran.dg/charlen_03.f90:5:39: Error: Allocatable component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
0x40000000011d55df crash_signal
        ../../gcc/toplev.c:333
0x40000000003f3530 resolve_variable
        ../../gcc/fortran/resolve.c:5040
0x40000000003f3530 gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.c:6484
0x400000000023352f resolve_array_bound
        ../../gcc/fortran/array.c:327
0x400000000023527f gfc_resolve_array_spec(gfc_array_spec*, int)
        ../../gcc/fortran/array.c:368
0x40000000003ec4af resolve_component
        ../../gcc/fortran/resolve.c:13621
0x40000000003ee2cf resolve_component
        ../../gcc/fortran/resolve.c:13737
0x40000000003ee2cf resolve_fl_derived0
        ../../gcc/fortran/resolve.c:13738
0x40000000003eeebf resolve_fl_derived0
        ../../gcc/fortran/resolve.c:13823
0x40000000003eeebf resolve_fl_derived
        ../../gcc/fortran/resolve.c:13815
0x40000000003e516f resolve_symbol
        ../../gcc/fortran/resolve.c:14138
0x400000000043a17f do_traverse_symtree
        ../../gcc/fortran/symbol.c:3985
0x40000000003d687f resolve_types
        ../../gcc/fortran/resolve.c:15940
0x40000000003e31af gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:16053
0x40000000003b3def resolve_all_program_units
        ../../gcc/fortran/parse.c:5947
0x40000000003b3def gfc_parse_file()
        ../../gcc/fortran/parse.c:6194
0x4000000000470f9f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:202

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Steven G. Kargl Dec. 9, 2016, 7:50 p.m. UTC | #10 
On Fri, Dec 09, 2016 at 01:54:34PM +0200, Janne Blomqvist wrote:
> On Fri, Dec 9, 2016 at 1:47 PM, Paul Richard Thomas

> <paul.richard.thomas@gmail.com> wrote:

>

> I'm seeing the same thing, I guess. Or rather that the ts->type == 81

> which is non-sensical. No idea where that comes from..

> 

> Backtrace from gdb:

> 

> #0  gfc_code2string (m=m@entry=0x182fe00 <bt_types>,

> code=code@entry=81) at ../../trunk-git/gcc/fortran/misc.c:193

> #1  0x000000000065645f in mio_name (t=81, m=m@entry=0x182fe00

> <bt_types>) at ../../trunk-git/gcc/fortran/module.c:1722

> #2  0x000000000065acb9 in mio_name_bt (m=0x182fe00 <bt_types>,

> t=<optimized out>) at ../../trunk-git/gcc/fortran/module.c:2106

> #3  mio_typespec (ts=ts@entry=0x2420918) at

> ../../trunk-git/gcc/fortran/module.c:2530

> #4  0x000000000065ae50 in mio_expr (ep=0x24217d0) at

> ../../trunk-git/gcc/fortran/module.c:3432

> #5  0x000000000065b300 in mio_charlen (clp=clp@entry=0x241fa80) at

> ../../trunk-git/gcc/fortran/module.c:2500

> #6  0x000000000065ad50 in mio_typespec (ts=ts@entry=0x241fa78) at

> ../../trunk-git/gcc/fortran/module.c:2558

> #7  0x000000000065ae50 in mio_expr (ep=ep@entry=0x24208a8) at

> ../../trunk-git/gcc/fortran/module.c:3432

> #8  0x000000000065bb73 in mio_component (c=c@entry=0x2420830,

> vtype=vtype@entry=0) at ../../trunk-git/gcc/fortran/module.c:2799

> #9  0x000000000065bbdb in mio_component_list (cp=cp@entry=0x2422138,

> vtype=0) at ../../trunk-git/gcc/fortran/module.c:2818

> #10 0x000000000065c913 in mio_symbol (sym=sym@entry=0x2422090) at

> ../../trunk-git/gcc/fortran/module.c:4238

> #11 0x000000000065cb8b in write_symbol (n=2, sym=sym@entry=0x2422090)

> at ../../trunk-git/gcc/fortran/module.c:5613

> #12 0x000000000065e87f in write_symbol0 (st=0x2422680) at

> ../../trunk-git/gcc/fortran/module.c:5653

> #13 0x000000000065e7f2 in write_symbol0 (st=0x2420650) at

> ../../trunk-git/gcc/fortran/module.c:5632

> #14 0x000000000065ea03 in write_module () at

> ../../trunk-git/gcc/fortran/module.c:5992

> #15 0x000000000065ec59 in dump_module (name=name@entry=0x7ffff6853060

> "m", dump_flag=dump_flag@entry=1) at

> ../../trunk-git/gcc/fortran/module.c:6120

> #16 0x000000000065edf8 in gfc_dump_module (name=0x7ffff6853060 "m",

> dump_flag=1) at ../../trunk-git/gcc/fortran/module.c:6163

> #17 0x0000000000675edd in gfc_parse_file () at

> ../../trunk-git/gcc/fortran/parse.c:6158

> #18 0x00000000006baa5b in gfc_be_parse_file () at

> ../../trunk-git/gcc/fortran/f95-lang.c:202


Ugh.  I can only reproduce the ICE under valgrind.  There is
some interesting stuff happening in module.c  

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
https://www.youtube.com/watch?v=6hwgPfCcpyQ
Paul Richard Thomas Dec. 10, 2016, 6:44 p.m. UTC | #11 
Dear Steve and Andre,

It turns out that Andre's instrumented gfortran came up trumps. There
was a block in resolve_structure_cons that attempted to remove a
charlen and, in so doing, broke the charlen chain. I have left it to
namespace cleanup to do the job in revision 243517. The module.c stuff
was a very red fish of some kind.

Cheers

Paul

2016-12-10 Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/78350
    * resolve.c (resolve_structure_cons): Remove the block that
    tried to remove a charlen and rely on namespace cleanup.

On 9 December 2016 at 20:50, Steven G. Kargl
<kargl@troutmask.apl.washington.edu> wrote:
> On Fri, Dec 09, 2016 at 01:54:34PM +0200, Janne Blomqvist wrote:

>> On Fri, Dec 9, 2016 at 1:47 PM, Paul Richard Thomas

>> <paul.richard.thomas@gmail.com> wrote:

>>

>> I'm seeing the same thing, I guess. Or rather that the ts->type == 81

>> which is non-sensical. No idea where that comes from..

>>

>> Backtrace from gdb:

>>

>> #0  gfc_code2string (m=m@entry=0x182fe00 <bt_types>,

>> code=code@entry=81) at ../../trunk-git/gcc/fortran/misc.c:193

>> #1  0x000000000065645f in mio_name (t=81, m=m@entry=0x182fe00

>> <bt_types>) at ../../trunk-git/gcc/fortran/module.c:1722

>> #2  0x000000000065acb9 in mio_name_bt (m=0x182fe00 <bt_types>,

>> t=<optimized out>) at ../../trunk-git/gcc/fortran/module.c:2106

>> #3  mio_typespec (ts=ts@entry=0x2420918) at

>> ../../trunk-git/gcc/fortran/module.c:2530

>> #4  0x000000000065ae50 in mio_expr (ep=0x24217d0) at

>> ../../trunk-git/gcc/fortran/module.c:3432

>> #5  0x000000000065b300 in mio_charlen (clp=clp@entry=0x241fa80) at

>> ../../trunk-git/gcc/fortran/module.c:2500

>> #6  0x000000000065ad50 in mio_typespec (ts=ts@entry=0x241fa78) at

>> ../../trunk-git/gcc/fortran/module.c:2558

>> #7  0x000000000065ae50 in mio_expr (ep=ep@entry=0x24208a8) at

>> ../../trunk-git/gcc/fortran/module.c:3432

>> #8  0x000000000065bb73 in mio_component (c=c@entry=0x2420830,

>> vtype=vtype@entry=0) at ../../trunk-git/gcc/fortran/module.c:2799

>> #9  0x000000000065bbdb in mio_component_list (cp=cp@entry=0x2422138,

>> vtype=0) at ../../trunk-git/gcc/fortran/module.c:2818

>> #10 0x000000000065c913 in mio_symbol (sym=sym@entry=0x2422090) at

>> ../../trunk-git/gcc/fortran/module.c:4238

>> #11 0x000000000065cb8b in write_symbol (n=2, sym=sym@entry=0x2422090)

>> at ../../trunk-git/gcc/fortran/module.c:5613

>> #12 0x000000000065e87f in write_symbol0 (st=0x2422680) at

>> ../../trunk-git/gcc/fortran/module.c:5653

>> #13 0x000000000065e7f2 in write_symbol0 (st=0x2420650) at

>> ../../trunk-git/gcc/fortran/module.c:5632

>> #14 0x000000000065ea03 in write_module () at

>> ../../trunk-git/gcc/fortran/module.c:5992

>> #15 0x000000000065ec59 in dump_module (name=name@entry=0x7ffff6853060

>> "m", dump_flag=dump_flag@entry=1) at

>> ../../trunk-git/gcc/fortran/module.c:6120

>> #16 0x000000000065edf8 in gfc_dump_module (name=0x7ffff6853060 "m",

>> dump_flag=1) at ../../trunk-git/gcc/fortran/module.c:6163

>> #17 0x0000000000675edd in gfc_parse_file () at

>> ../../trunk-git/gcc/fortran/parse.c:6158

>> #18 0x00000000006baa5b in gfc_be_parse_file () at

>> ../../trunk-git/gcc/fortran/f95-lang.c:202

>

> Ugh.  I can only reproduce the ICE under valgrind.  There is

> some interesting stuff happening in module.c

>

> --

> Steve

> http://troutmask.apl.washington.edu/~kargl/

> https://www.youtube.com/watch?v=6hwgPfCcpyQ




-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama
diff mbox

Patch

Index: gcc/fortran/gfortran.h
===================================================================
--- gcc/fortran/gfortran.h	(revision 243376)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -1768,7 +1768,7 @@  typedef struct gfc_namespace
   /* !$ACC ROUTINE names.  */
   gfc_oacc_routine_name *oacc_routine_names;
 
-  gfc_charlen *cl_list, *old_cl_list;
+  gfc_charlen *cl_list;
 
   gfc_dt_list *derived_types;
 
Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 243376)
+++ gcc/fortran/parse.c	(working copy)
@@ -116,7 +116,6 @@  use_modules (void)
   gfc_pop_error (&old_error);
   gfc_commit_symbols ();
   gfc_warning_check ();
-  gfc_current_ns->old_cl_list = gfc_current_ns->cl_list;
   gfc_current_ns->old_equiv = gfc_current_ns->equiv;
   gfc_current_ns->old_data = gfc_current_ns->data;
   last_was_use_stmt = false;
@@ -1386,7 +1385,6 @@  next_statement (void)
 
   gfc_new_block = NULL;
 
-  gfc_current_ns->old_cl_list = gfc_current_ns->cl_list;
   gfc_current_ns->old_equiv = gfc_current_ns->equiv;
   gfc_current_ns->old_data = gfc_current_ns->data;
   for (;;)
@@ -2483,41 +2481,13 @@  accept_statement (gfc_statement st)
 }
 
 
-/* Clear default character types with charlen pointers that are about
-   to become invalid.  */
-
-static void
-clear_default_charlen (gfc_namespace *ns, const gfc_charlen *cl,
-		       const gfc_charlen *end)
-{
-  gfc_typespec *ts;
-
-  for (ts = &ns->default_type[0]; ts < &ns->default_type[GFC_LETTERS]; ts++)
-      if (ts->type == BT_CHARACTER)
-	{
-	  const gfc_charlen *cl2;
-	  for (cl2 = cl; cl2 != end; cl2 = cl2->next)
-	    if (ts->u.cl == cl2)
-	      {
-		ts->u.cl = NULL;
-		ts->type = BT_UNKNOWN;
-		break;
-	      }
-	 }
-}
-
-/* Undo anything tentative that has been built for the current
-   statement.  */
+/* Undo anything tentative that has been built for the current statement,
+   except if a gfc_charlen structure has been added to current namespace's
+   list of gfc_charlen structure.  */
 
 static void
 reject_statement (void)
 {
-  /* Revert to the previous charlen chain.  */
-  clear_default_charlen (gfc_current_ns,
-			 gfc_current_ns->cl_list, gfc_current_ns->old_cl_list);
-  gfc_free_charlen (gfc_current_ns->cl_list, gfc_current_ns->old_cl_list);
-  gfc_current_ns->cl_list = gfc_current_ns->old_cl_list;
-
   gfc_free_equiv_until (gfc_current_ns->equiv, gfc_current_ns->old_equiv);
   gfc_current_ns->equiv = gfc_current_ns->old_equiv;
 
Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 243376)
+++ gcc/fortran/symbol.c	(working copy)
@@ -3794,31 +3794,22 @@  gfc_charlen*
 gfc_new_charlen (gfc_namespace *ns, gfc_charlen *old_cl)
 {
   gfc_charlen *cl;
+
   cl = gfc_get_charlen ();
 
   /* Copy old_cl.  */
   if (old_cl)
     {
-      /* Put into namespace, but don't allow reject_statement
-	 to free it if old_cl is given.  */
-      gfc_charlen **prev = &ns->cl_list;
-      cl->next = ns->old_cl_list;
-      while (*prev != ns->old_cl_list)
-	prev = &(*prev)->next;
-      *prev = cl;
-      ns->old_cl_list = cl;
       cl->length = gfc_copy_expr (old_cl->length);
       cl->length_from_typespec = old_cl->length_from_typespec;
       cl->backend_decl = old_cl->backend_decl;
       cl->passed_length = old_cl->passed_length;
       cl->resolved = old_cl->resolved;
     }
-  else
-    {
-      /* Put into namespace.  */
-      cl->next = ns->cl_list;
-      ns->cl_list = cl;
-    }
+
+  /* Put into namespace.  */
+  cl->next = ns->cl_list;
+  ns->cl_list = cl;
 
   return cl;
 }
Index: gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90
===================================================================
--- gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90	(revision 243376)
+++ gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90	(working copy)
@@ -3,6 +3,6 @@ 
 subroutine s
   real x ! { dg-error "" }
   implicit character (a) ! { dg-error "IMPLICIT statement at .1. cannot follow data declaration statement at .2." }
-
-  a1 = 'z' ! { dg-error "Symbol .a1. at .1. has no IMPLICIT type" }
+  x = 1
+  a = 'a'
 end subroutine s
Index: gcc/testsuite/gfortran.dg/pr65173.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr65173.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr65173.f90	(working copy)
@@ -0,0 +1,7 @@ 
+! { dg-do compile }
+program p
+   type t
+      character, allocatable :: z1(:), z1(:) ! { dg-error "already declared" }
+   end type
+end
+