Bug 90741 - Unreachable second '__builtin_malloc' for scalar 'allocatable'
Summary: Unreachable second '__builtin_malloc' for scalar 'allocatable'
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 10.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-04 12:42 UTC by Thomas Schwinge
Modified: 2019-06-05 08:07 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Schwinge 2019-06-04 12:42:50 UTC 
Based on trunk r271854, I noticed that for the following simple Fortran code:

    program main
      implicit none
      integer, allocatable :: a
    
      allocate (a)
    
      a = 50
    
      deallocate (a)
    end program main

... the following appears in the '-fdump-tree-original' dump:

    [...]
          a = (integer(kind=4) *) __builtin_malloc (4);
          if (a == 0B)
            { 
              _gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1});
            }
        }
      if (a != 0B) goto L.1;
      a = (integer(kind=4) *) __builtin_malloc (4);
      L.1:;
      *a = 50;
      if (a == 0B)
        { 
          _gfortran_runtime_error_at (&"At line 9 of file [...]"[1]{lb: 1 sz: 1}, &"Attempt to DEALLOCATE unallocated \'%s\'"[1]{lb: 1 sz: 1}, &"a"[1]{lb: 1 sz: 1});
        }
      else
        { 
          __builtin_free ((void *) a);
        }
      a = 0B;
    }

I have not looked up where/why that second '__builtin_malloc' is emitted.  At least in this simple case, it's unreachable, so it's not a memory leak.
Comment 1 Jakub Jelinek 2019-06-04 12:53:27 UTC 
The first malloc call is from expansion of allocate statement, while the second one is for the a = 50 assignment which must allocate on the assignment if not allocated already.  I don't see any bug.
Comment 2 kargls 2019-06-04 16:50:02 UTC 
(In reply to Jakub Jelinek from comment #1)
> The first malloc call is from expansion of allocate statement, while the
> second one is for the a = 50 assignment which must allocate on the
> assignment if not allocated already.  I don't see any bug.

Jakub is correct here.  Fortran has (re)allocation on assignment.
You can disable the (re)allocation with the -fno-realloc-lhs option.

This simple code

% cat a.f90
program foo
   integer, allocatable :: i
   allocate(i)
   i = 42
end program foo

compiled with

%  gfcx -c -fdump-tree-original -fno-realloc-lhs a.f90

yields (shortening error messages for brevity)

{
  integer(kind=4) * i;

  i = 0B;
  if (i != 0B)
    {
      _gfortran_runtime_error_at ("Attempting to allocate ...");
    }
  else
    {
      i = (integer(kind=4) *) __builtin_malloc (4);
      if (i == 0B)
        {
          _gfortran_os_error ("exceed memory limit");
        }
    }
  *i = 42;
}
Comment 3 Richard Biener 2019-06-05 08:07:18 UTC 
Agreed, this isn't a bug (unless you suggest the Frontend optimize it).