--- Comment #19 from ek dot kato at gmail dot com 2007-12-18 02:20 ---
OK. I've just sent a mail to gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
--- Comment #15 from ek dot kato at gmail dot com 2007-12-17 02:02 ---
(In reply to comment #14)
> Etsushi,
> Your last patch doesn't do the right thing for the x86_64 multilib. The
> shared libraries in...
>
> /sw/lib/gcc4.3/lib/x86_64
>
> ...are li
--- Comment #5 from ek dot kato at gmail dot com 2007-11-30 02:39 ---
Maybe I could find a reliable testcase for the problem. Following program will
crash while accessing dtp->u.p.line_buffer[dtp->u.p.item_count].
IMPLICIT NONE
CHARACTER(len=10), DIMENSION(2) :: var
NA
--- Comment #4 from ek dot kato at gmail dot com 2007-11-30 01:11 ---
I can't provide a simple test case sorry, but I now realized that it seems to
be related that READ() for a namelist file ended with "&END" instead of "/"
causes the problem.
I use a l
--- Comment #1 from ek dot kato at gmail dot com 2007-11-29 13:18 ---
It turns out that my explanation and assumption about uninitialization was
wrong, but the real cause of the segmentation fault is that some functions call
free_line(dtp) without resetting line_buffer_enabled. Here is
is used in io/list_read.c which
causes segfault
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ek d
--- Comment #13 from ek dot kato at gmail dot com 2007-11-29 09:08 ---
Oops, I noticed the diff sent yesterday was broken. Here is the correct one
for the workaround.
Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in
--- Comment #12 from ek dot kato at gmail dot com 2007-11-28 09:19 ---
Hi,
I encountered this problem today, as I would like to use latest gfortran on Mac
OS X 10.4.11.
Anyway here is the crude workaround to avoid the install name problem. It just
install libgcc_s.*.dylib with
