Bug 69422 - Unexpected result with allocatable character type component
Summary: Unexpected result with allocatable character type component
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords:
Depends on:
Blocks: 68241
  Show dependency treegraph
 
Reported: 2016-01-21 22:42 UTC by Antony Lewis
Modified: 2016-01-28 08:52 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-01-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antony Lewis 2016-01-21 22:42:00 UTC
With the current svn master branch the following code prints out nothing for 'test result':

    module funcs
    implicit none
    
    Type T
    character(LEN=:), allocatable :: source
    end type T
    
    type TPointer
    	Type(T), pointer :: P
    end type TPointer
    
    end module
    
    program Test1
    use funcs
    Type(TPointer) :: X
    
    allocate(X%P)
    
    X%P%Source = 'test string'
    print *, 'test result = ', X%P%Source
    
    end program Test1


This may be a regression from earlier 6.0 commits, but not sure.
Comment 1 Dominique d'Humieres 2016-01-22 10:46:29 UTC
Confirmed from 4.8 up to trunk (6.0).
Comment 2 Paul Thomas 2016-01-22 18:27:21 UTC
Hmmm! This works if the pointer attribute is changed to allocatable. As reported, it generates:

  x.p->source = 0B;
  x.p->_source_length = 0;
  {
    struct t t.0;

    t.0.source = 0B;
    t.0._source_length = 0;
    *x.p = t.0;
  }
  {
    integer(kind=4) D.2324;

    D.2324 = x.p->_source_length;
    if (D.2324 != 0)
      {
        if ((unsigned long) D.2324 <= 11)
          {
            __builtin_memcpy ((void *) x.p->source, (void *) &"test string"[1]{lb: 1 sz: 1}, (unsigned long) D.2324);
          }
        else
          {
            __builtin_memcpy ((void *) x.p->source, (void *) &"test string"[1]{lb: 1 sz: 1}, 11);
            __builtin_memset ((void *) x.p->source + 11, 32, (unsigned long) D.2324 + 18446744073709551605);
          }
      }
  }

so that D.2324 is zero and nothing is copied.

I'll take it, although this time it preceeds my input :-)

Thanks for the report

Paul
Comment 3 Paul Thomas 2016-01-23 11:09:56 UTC
(In reply to Paul Thomas from comment #2)
> Hmmm! This works if the pointer attribute is changed to allocatable. As
> reported, it generates:
> 

This is precisely the point! There is no obligation for the processor to automatically (re)allocate a pointer component, is there?

Changing the assignment to

    allocate (X%P%Source, source = 'test string')

works as expected.

I'm sorry but this one is invalid. I suppose that a runtime warning along the lines of that just introduced for assignment of scalars to unallocated, allocatable arrays could be introduced but I am seriously unconvinced that we should be doing this for pointers.

Cheers

Paul
Comment 4 Antony Lewis 2016-01-23 11:43:48 UTC
But "source" is allocatable, not a pointer? (the pointer P is explicitly allocated in the example)
Comment 5 Paul Thomas 2016-01-23 12:00:09 UTC
(In reply to Antony Lewis from comment #4)
> But "source" is allocatable, not a pointer? (the pointer P is explicitly
> allocated in the example)

I beg your pardon - yes, that's right. I am pretty sure that the any attempt to search for (re)allocation is being blocked by the pointer. I'll check the standard!

Unresolving and revalidating!

Thanks

Paul
Comment 6 Paul Thomas 2016-01-28 08:52:31 UTC
I screwed up the PR numbers when I committed the fix and so the changes do not appear in the audit trail.

Committed as r232904.

Thanks for the report

Paul