public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "templed at tcd dot ie" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67177] New: MOVE_ALLOC not automatically allocating deferred character arrays in derived types Date: Mon, 10 Aug 2015 16:35:00 -0000 [thread overview] Message-ID: <bug-67177-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67177 Bug ID: 67177 Summary: MOVE_ALLOC not automatically allocating deferred character arrays in derived types Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: templed at tcd dot ie Target Milestone: --- (First time submitting a bug, apologies if I've messed up somewhere) When a derived type containing a deferred-length character variable is the TO= argument of a MOVE_ALLOC() call the character length is not correctly set and the value of the variable is not stored. Two workarounds for this is to either not use deferred-length character variables (use an allocatable array of single characters), or to preallocate the length to the variable that will be the TO= argument. The below test program has been tested with Intel 15.0.2 (20150121) and, when the line critical line is commented out (see code) the program correctly allocates the deferred-length string and populates it with the correct value. In gfortran 5.2 (and 4.9.2, FWIW) it fails to allocate the length and store the value even though a check with allocated() returns true. $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/support/modules/gnu-5.2/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/support/modules/gnu-5.2 --disable-multilib Thread model: posix gcc version 5.2.0 (GCC) Test program: program str implicit none type string character(:), Allocatable :: text end type string type strings type(string), allocatable, dimension(:) :: strlist end type strings type(strings) :: teststrs type(string) :: tmpstr integer :: strlen = 20 allocate(teststrs%strlist(1)) allocate(character(len=strlen) :: tmpstr%text) ! This is the critical line. If this is commented then ! the move_alloc fails. Whereas what should happen is that ! this variable should be allocated automatically by move_alloc allocate(character(len=strlen) :: teststrs%strlist(1)%text) ! Needs blanking otherwise memory is leaked tmpstr%text(1:20) = ' ' tmpstr%text(1:3) = 'foo' ! Should return "alloc?, strlen F 20" when the critical line is commented out (shows 'T' otherwise) write(*,*)'alloc?, strlen ',allocated(teststrs%strlist(1)%text),len(tmpstr%text) call move_alloc(tmpstr%text,teststrs%strlist(1)%text) ! Should return "alloc?, strlen T 20" write(*,*)'alloc?, strlen ',allocated(teststrs%strlist(1)%text),len(teststrs%strlist(1)%text) ! Should return "foo " write(*,*)'"',teststrs%strlist(1)%text,'"' end program str
next reply other threads:[~2015-08-10 16:35 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-08-10 16:35 templed at tcd dot ie [this message] 2015-09-05 10:47 ` [Bug fortran/67177] " dominiq at lps dot ens.fr 2015-10-17 9:36 ` pault at gcc dot gnu.org 2015-10-17 13:49 ` pault at gcc dot gnu.org 2015-10-18 9:32 ` pault at gcc dot gnu.org 2015-10-26 17:25 ` pault at gcc dot gnu.org 2015-10-26 17:27 ` pault at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-67177-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).