public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52151] New: Segfault with realloc on assignment and RESHAPE to unallocated LHS Date: Tue, 07 Feb 2012 17:40:00 -0000 [thread overview] Message-ID: <bug-52151-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151 Bug #: 52151 Summary: Segfault with realloc on assignment and RESHAPE to unallocated LHS Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned@gcc.gnu.org ReportedBy: burnus@gcc.gnu.org CC: pault@gcc.gnu.org Follow up to PR 52012 and 52117. * B is allocated with the shape (n1,n2,n3): -> Works since the patch for PR 52012 (Before, it had the wrong result for the last two elements) * B is not allocated -> Segfault since the patch for PR 52012 -> Before: no segfault but wrong result in for the last two elements * B allocated with shape (1,1,1) -> Since patch for PR 52012: No crash, but wrong result ("2.0" and 3.0 appear multiple times, 5., 6., 7., 8. are missing and 4. is at the wrong position) -> Before: no segfault but wrong result in for the last two elements The test case has been taken from PR 52117 with adaption to show this bug. chapter08/puppeteer_f2003 of Damian's/Xia's/Xu's book is also affected. I think there might be an ordering issue with regards to the zero condition and the bounds condition. Something like the following might work (completely untested; note also the "ORIF"): --- trans-expr.c (revision 183971) +++ trans-expr.c (working copy) @@ -6296 +6296 @@ fcncall_realloc_result (gfc_se *se, int - tree zero_cond; + tree zero_cond, cond; @@ -6324,0 +6325 @@ fcncall_realloc_result (gfc_se *se, int + cond = boolean_true_node; @@ -6344 +6345 @@ fcncall_realloc_result (gfc_se *se, int - zero_cond); + cond); @@ -6345,0 +6347,4 @@ fcncall_realloc_result (gfc_se *se, int + + zero_cond = fold_build2_loc (input_location, TRUTH_ORIF_EXPR, + boolean_type_node, zero_cond, + cond); ! Based on the example of PR 52117 by Steven Hirshman PROGRAM RESHAPEIT INTEGER, PARAMETER :: n1=2, n2=2, n3=2 INTEGER :: m1, m2, m3, lc REAL, ALLOCATABLE :: A(:,:), B(:,:,:) REAL :: val ALLOCATE (A(n1,n2*n3)) ! <<< No allocation: Segfault ! ALLOCATE (B(1,1,1)) ! << Does not segfault, but result is wrong ! ALLOCATE (B(n1,n2,n3)) ! << WORKS val = 0 lc = 0 DO m3=1,n3 DO m2=1,n2 lc = lc+1 DO m1=1,n1 val = val+1 A(m1, lc) = val END DO END DO END DO B = RESHAPE(A, [n1,n2,n3]) lc = 0 DO m3=1,n3 DO m2=1,n2 lc = lc+1 DO m1=1,n1 PRINT *,'A(',m1,',',lc,') = ',A(m1,lc),' B = ',B(m1,m2,m3) if (A(m1,lc) /= B(m1,m2,m3)) call abort () END DO END DO END DO DEALLOCATE(A, B) END PROGRAM RESHAPEIT
next reply other threads:[~2012-02-07 17:40 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-07 17:40 burnus at gcc dot gnu.org [this message] 2012-02-07 18:03 ` [Bug fortran/52151] " burnus at gcc dot gnu.org 2012-02-07 21:28 ` dominiq at lps dot ens.fr 2012-02-08 16:49 ` burnus at gcc dot gnu.org 2012-02-08 19:40 ` burnus at gcc dot gnu.org 2012-02-08 21:30 ` burnus at gcc dot gnu.org 2012-02-08 21:32 ` burnus at gcc dot gnu.org 2012-02-28 16:27 ` burnus 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-52151-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).