From: Paul Thomas <paulthomas2@wanadoo.fr>
To: Fortran List <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>,
Tobias Burnus <burnus@net-b.de>
Subject: [Patch, fortran] PR32880 - User operator & allocatable TYPE components: wrong deallocate
Date: Fri, 27 Jul 2007 17:59:00 -0000 [thread overview]
Message-ID: <46AA2BCF.1060108@wanadoo.fr> (raw)
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
:ADDPATCH fortran:
This fix for pr32880 is blessedly simple and self-explanatory. We now
have a clean sweep on the iso_varying_string testsuite:)
Thanks to Tobias for pointing out where the problem was.
Regtested on Cygwin_NT/amd64 - OK for trunk?
I'll add a testcase - I was in such a burning hurry to communicate this
that I couldn't wait!
2007-07-27 Paul Thomas <pault@gcc.gnu.org>
PR fortran/32880
* trans-expr.c (gfc_trans_scalar_assign): Revert to fixed order
for lse and rse pre expressions, for derived types with
allocatable components. Instead, assign the lhs to a temporary
and deallocate after the assignment.
[-- Attachment #2: pr32880.diff --]
[-- Type: text/x-patch, Size: 1713 bytes --]
Index: gcc/fortran/trans-expr.c
===================================================================
*** gcc/fortran/trans-expr.c (revision 126973)
--- gcc/fortran/trans-expr.c (working copy)
*************** gfc_trans_scalar_assign (gfc_se * lse, g
*** 3512,3536 ****
}
/* Deallocate the lhs allocated components as long as it is not
! the same as the rhs. */
if (!l_is_temp)
{
! tmp = gfc_deallocate_alloc_comp (ts.derived, lse->expr, 0);
if (r_is_var)
tmp = build3_v (COND_EXPR, cond, build_empty_stmt (), tmp);
! gfc_add_expr_to_block (&lse->pre, tmp);
}
! if (r_is_var)
! {
! gfc_add_block_to_block (&block, &lse->pre);
! gfc_add_block_to_block (&block, &rse->pre);
! }
! else
! {
! gfc_add_block_to_block (&block, &rse->pre);
! gfc_add_block_to_block (&block, &lse->pre);
! }
gfc_add_modify_expr (&block, lse->expr,
fold_convert (TREE_TYPE (lse->expr), rse->expr));
--- 3512,3531 ----
}
/* Deallocate the lhs allocated components as long as it is not
! the same as the rhs. This must be done following the assignment
! to prevent deallocating data that could be used in the rhs
! expression. */
if (!l_is_temp)
{
! tmp = gfc_evaluate_now (lse->expr, &lse->pre);
! tmp = gfc_deallocate_alloc_comp (ts.derived, tmp, 0);
if (r_is_var)
tmp = build3_v (COND_EXPR, cond, build_empty_stmt (), tmp);
! gfc_add_expr_to_block (&lse->post, tmp);
}
! gfc_add_block_to_block (&block, &rse->pre);
! gfc_add_block_to_block (&block, &lse->pre);
gfc_add_modify_expr (&block, lse->expr,
fold_convert (TREE_TYPE (lse->expr), rse->expr));
next reply other threads:[~2007-07-27 17:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 17:59 Paul Thomas [this message]
2007-07-27 21:12 ` Tobias Burnus
2007-07-27 22:08 ` Paul Thomas
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=46AA2BCF.1060108@wanadoo.fr \
--to=paulthomas2@wanadoo.fr \
--cc=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@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: link
Be 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).