public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/21333] New: in_pack / in_unpack alignment issues Date: Mon, 02 May 2005 11:28:00 -0000 [thread overview] Message-ID: <20050502112726.21333.tkoenig@gcc.gnu.org> (raw) I don't have the machines to test this on, but I think there is a chance of an alignment issue with in_pack / in_unpack. Look at the following program: program main complex a(5),b(5) equivalence(a(1),r(1)),(b(1),r(12)) real r(100) a = (1.0, -1.0) b = (2.0, -2.0) call foo(a(5:1:-1),5) call foo(b(5:1:-1),5) end program main subroutine foo(arr,n) complex, dimension(n) :: a end subroutine foo The equivalence makes sure that a and b cannot both be aligned on an 8-byte-boundary. The array reference gets repacked for both calls to foo: parm.2.dtype = 545; parm.2.dim[0].lbound = 1; parm.2.dim[0].ubound = 5; parm.2.dim[0].stride = -1; parm.2.data = (complex4[0:] *) (complex4[0:] *) &equiv.0.a[4]; parm.2.offset = 0; D.529 = _gfortran_internal_pack (&parm.2); foo (D.529, &C.530); if (D.529 != parm.2.data) { _gfortran_internal_unpack (&parm.2, D.529); _gfortran_internal_free (D.529); } internal_pack_generic has the following code: size = GFC_DESCRIPTOR_SIZE (source); switch (size) { case 4: return internal_pack_4 ((gfc_array_i4 *)source); case 8: return internal_pack_8 ((gfc_array_i8 *)source); } so internal_pack_8 is called. This operates on a gfc_array_i8. On machines where you can only align an i8 on an eight-byte-boundary, this will fail. I'd appreciate if somebody could run the test program on such a machine, to see wehter I got this right :-) Thomas -- Summary: in_pack / in_unpack alignment issues Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21333
next reply other threads:[~2005-05-02 11:28 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-05-02 11:28 tkoenig at gcc dot gnu dot org [this message] 2005-05-11 21:32 ` [Bug libfortran/21333] " tobi at gcc dot gnu dot org 2005-05-11 21:58 ` tobi at gcc dot gnu dot org 2005-05-11 22:40 ` steven at gcc dot gnu dot org 2005-05-17 13:25 ` tkoenig at gcc dot gnu dot org 2005-05-24 22:46 ` tkoenig at gcc dot gnu dot org 2005-06-02 15:49 ` tkoenig at gcc dot gnu dot org 2005-06-11 19:39 ` cvs-commit at gcc dot gnu dot org 2005-06-11 20:19 ` [Bug libfortran/21333] [4.0 only] " tkoenig at gcc dot gnu dot org 2005-06-12 20:28 ` cvs-commit at gcc dot gnu dot org 2005-07-18 17:41 ` cvs-commit at gcc dot gnu dot org 2005-07-18 18:03 ` tkoenig at gcc dot gnu dot org 2005-07-19 17:49 ` cvs-commit at gcc dot gnu dot 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=20050502112726.21333.tkoenig@gcc.gnu.org \ --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).