--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-25
17:33 ---
Fixed by:
2004-12-14 Steve Ellcey [EMAIL PROTECTED]
* libgfortran/io/transfer.c (us_read): Use memcpy/memset
instead of assignment to fill unaligned buffer.
(us_write): Ditto.
--- Additional Comments From sje at cup dot hp dot com 2005-01-25 17:20
---
The patch for this fix was checked in. The final patch was:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00953.html
Does anything else need to be done for this to be closed?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-10
17:44 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00764.html.
--
What|Removed |Added
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09
09:41 ---
sounds reasonable to me. note that gfc_offset is either a 32 or a 63 bit value
depending on offset_t.
there is a testsuite file to test this exact problem,
unopened_unit_1.f90
! PR 14565
program
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09
12:07 ---
32 or 64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
--
What|Removed |Added
Component|fortran |libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
--- Additional Comments From sje at cup dot hp dot com 2004-12-08 19:06
---
The same problem exists in next_record_w, there there are two statments of the
form '*((gfc_offset *) p) = m;' and again there is no gaurentee that p is an
aligned address. These must also be fixed for this
