[Bug fortran/81735] New: double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

["flashmozzg at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 81735
           Summary: double free or corruption (fasttop) error (SIGABRT)
                    with character(:) and custom return type with
                    allocatable
           Product: gcc
           Version: 5.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: flashmozzg at gmail dot com
  Target Milestone: ---

This error appears at least starting from gfortran 5.4.0 and is present in
gfortran 7.1.0.
I've tested on Ubuntu 16.04. I've also tested on Win10 x64 with gfortran
bundled with MinGW (from Qt installation) with versions 4.9.2 and 5.3.0 and
couldn't reproduce it there.
I compiled using gfortran -std=f2008 -ffree-form -g -Wall -o foo.f95

I've managed to reduce the program to this small sample:

program fooprog
    implicit none
    type FooType
        integer, allocatable :: x
    end type FooType

    type(FooType), pointer :: bar

    bar => foo()

contains
    function foo() result(res)
        type(FooType), pointer :: res

        character(:), allocatable :: rt
        rt = ""
        res => null()
    end function foo
end program fooprog

Compiling and running it results in a SIGABRT with

*** Error in `./foo': double free or corruption (fasttop): 0x0000000001cff0a0
***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb43f10d7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fb43f11637a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fb43f11a53c]
./foo[0x4008a0]
./foo[0x4008be]
./foo[0x4008f8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb43f0b6830]
./foo[0x400719]
... etc

Important: if I comment rt = "". the problem doesn't occur.
If res has a basic type, the problem doesn't occur.
If x in FooType is not marked allocatable, the problem doesn't occur.