* [Bug fortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
@ 2007-01-27 21:31 ` kargl at gcc dot gnu dot org
2007-01-27 21:38 ` kargl at gcc dot gnu dot org
` (34 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-01-27 21:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 21:31 -------
I believe recursive IO is undefined (except maybe in some very limited
situations), but I can't locate anything in the F95 Standard that says
this. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug fortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
2007-01-27 21:31 ` [Bug fortran/30617] " kargl at gcc dot gnu dot org
@ 2007-01-27 21:38 ` kargl at gcc dot gnu dot org
2007-01-27 21:43 ` dominiq at lps dot ens dot fr
` (33 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-01-27 21:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 21:38 -------
(In reply to comment #1)
> I believe recursive IO is undefined (except maybe in some very limited
> situations), but I can't locate anything in the F95 Standard that says
> this. :(
>
Okay I found the relevant passage.
9.7 Restrictions on function references and list items
A function reference shall not appear in an expression anywhere in an
input/output statement if such a reference causes another input/output
statement to be executed.
I believe your "print *, fun()" is nonconforming.
Note F2003 changes the restrictions of recursive IO. It may take a
long time before gfortran supports this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug fortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
2007-01-27 21:31 ` [Bug fortran/30617] " kargl at gcc dot gnu dot org
2007-01-27 21:38 ` kargl at gcc dot gnu dot org
@ 2007-01-27 21:43 ` dominiq at lps dot ens dot fr
2007-01-27 21:48 ` [Bug libfortran/30617] " pinskia at gcc dot gnu dot org
` (32 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-01-27 21:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dominiq at lps dot ens dot fr 2007-01-27 21:43 -------
> I believe recursive IO is undefined
Probably, but the same code works with
Target: x86_64-unknown-linux-gnu
gcc version 4.3.0 20061231 (experimental)
on a linux AMD64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (2 preceding siblings ...)
2007-01-27 21:43 ` dominiq at lps dot ens dot fr
@ 2007-01-27 21:48 ` pinskia at gcc dot gnu dot org
2007-01-27 21:51 ` jvdelisle at gcc dot gnu dot org
` (31 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-01-27 21:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-27 21:47 -------
This might be a bug in Mac OS X's libraries.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|fortran |libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (3 preceding siblings ...)
2007-01-27 21:48 ` [Bug libfortran/30617] " pinskia at gcc dot gnu dot org
@ 2007-01-27 21:51 ` jvdelisle at gcc dot gnu dot org
2007-01-27 22:01 ` dominiq at lps dot ens dot fr
` (30 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-01-27 21:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-27 21:51 -------
I recall some time ago working on the patch that enabled this feature.
I agree this is probably platform specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (4 preceding siblings ...)
2007-01-27 21:51 ` jvdelisle at gcc dot gnu dot org
@ 2007-01-27 22:01 ` dominiq at lps dot ens dot fr
2007-01-27 23:34 ` kargl at gcc dot gnu dot org
` (29 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-01-27 22:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dominiq at lps dot ens dot fr 2007-01-27 22:01 -------
Subject: Re: recursive I/O hangs under OSX 10.3
> I agree this is probably platform specific.
Can someone do the test on a Macintel? TIA
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (5 preceding siblings ...)
2007-01-27 22:01 ` dominiq at lps dot ens dot fr
@ 2007-01-27 23:34 ` kargl at gcc dot gnu dot org
2007-01-29 13:46 ` dir at lanl dot gov
` (28 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-01-27 23:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from kargl at gcc dot gnu dot org 2007-01-27 23:34 -------
(In reply to comment #3)
> > I believe recursive IO is undefined
>
> Probably, but the same code works with
>
> Target: x86_64-unknown-linux-gnu
> gcc version 4.3.0 20061231 (experimental)
>
Undefined means undefined. It might do what
you want on one platform and something entirely
different on another.
If I read the F2003 standrad correctly, then
your program conforms to F2003. You may want
to change this to an enhancement request.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (6 preceding siblings ...)
2007-01-27 23:34 ` kargl at gcc dot gnu dot org
@ 2007-01-29 13:46 ` dir at lanl dot gov
2007-01-29 14:13 ` dominiq at lps dot ens dot fr
` (27 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dir at lanl dot gov @ 2007-01-29 13:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from dir at lanl dot gov 2007-01-29 13:45 -------
It hangs on a Intel iMac -
[pactech01:~/tests] dir% gfortran -o recursiveio recursiveio.f90
[pactech01:~/tests] dir% recursiveio
test
1.000000
^C
[pactech01:~/tests] dir% cat recursiveio.f90
external fun
real fun
real a
a = fun()
print *, a
print *, fun()
end
real function fun()
print *, 'test'
fun = 1.0
end
[dranta:~] dir%
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (7 preceding siblings ...)
2007-01-29 13:46 ` dir at lanl dot gov
@ 2007-01-29 14:13 ` dominiq at lps dot ens dot fr
2007-02-05 22:15 ` fxcoudert at gcc dot gnu dot org
` (26 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-01-29 14:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from dominiq at lps dot ens dot fr 2007-01-29 14:13 -------
Subject: Re: recursive I/O hangs under OSX 10.3
> It hangs on a Intel iMac
Thanks for the answer. So it hangs for the different flavor of OSX, but not
for x86_64-unknown-linux-gnu (4.3.0 20061231) and
i386-pc-linux-gnu (4.3.0 20070129). What about the other supported OS and
architecture?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (8 preceding siblings ...)
2007-01-29 14:13 ` dominiq at lps dot ens dot fr
@ 2007-02-05 22:15 ` fxcoudert at gcc dot gnu dot org
2007-02-06 3:04 ` jvdelisle at gcc dot gnu dot org
` (25 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-02-05 22:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-02-05 22:15 -------
When the program hangs, we're in
#0 0x9002bbc8 in semaphore_wait_signal_trap ()
#1 0x90001410 in pthread_mutex_lock ()
#2 0x0025595c in get_external_unit (n=6, do_create=275) at
../../../gcc/libgfortran/../gcc/gthr-posix.h:604
#3 0x00254164 in data_transfer_init (dtp=0xbffff5cc, read_flag=275) at
../../../gcc/libgfortran/io/transfer.c:1698
#4 0x00002bb4 in fun_ () at a.f90:9
#5 0x00002b28 in MAIN__ () at a.f90:6
#6 0x00002c18 in main (argc=14, argv=0x113) at
../../../gcc/libgfortran/fmain.c:18
I don't know how all this works, maybe Jakub could give us some help here?
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-02-05 22:15:24
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (9 preceding siblings ...)
2007-02-05 22:15 ` fxcoudert at gcc dot gnu dot org
@ 2007-02-06 3:04 ` jvdelisle at gcc dot gnu dot org
2007-02-07 9:10 ` brooks at gcc dot gnu dot org
` (24 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-02-06 3:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-02-06 03:04 -------
See the commentary near the top of io/unit.c . This is a basic explanation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (10 preceding siblings ...)
2007-02-06 3:04 ` jvdelisle at gcc dot gnu dot org
@ 2007-02-07 9:10 ` brooks at gcc dot gnu dot org
2007-02-07 9:24 ` dominiq at lps dot ens dot fr
` (23 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: brooks at gcc dot gnu dot org @ 2007-02-07 9:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from brooks at gcc dot gnu dot org 2007-02-07 09:10 -------
(In reply to comment #7)
> If I read the F2003 standrad correctly, then
> your program conforms to F2003. You may want
> to change this to an enhancement request.
This is incorrect -- the code does not conform to F2003 either. Section 9.11,
paragraph 3, says that a recursive I/O statement -- that is, one that occurs
while another is in progress, such as the "print *, 'test'" in this code --
may not identify an external unit, unless it is a "child I/O statement".
Section 9.5.3.7.1, paragarph 2, defines a "child I/O statement" as one that's
occuring within a user-defined derived-type I/O function -- which is definitely
not applicable here.
Therefore, I believe that this bug should be closed as INVALID, but given the
amount of commentary (and the fact that hanging is an unfortunate response even
to invalid code), I'll let someone else make that call.
--
brooks at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |brooks at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX 10.3
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (11 preceding siblings ...)
2007-02-07 9:10 ` brooks at gcc dot gnu dot org
@ 2007-02-07 9:24 ` dominiq at lps dot ens dot fr
2007-02-07 19:55 ` [Bug libfortran/30617] recursive I/O hangs under OSX dominiq at lps dot ens dot fr
` (22 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-07 9:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from dominiq at lps dot ens dot fr 2007-02-07 09:24 -------
Subject: Re: recursive I/O hangs under OSX 10.3
> Section 9.5.3.7.1, paragarph 2, defines a "child I/O statement" as one that's
> occuring within a user-defined derived-type I/O function -- which is definitely
> not applicable here.
Could you please translate this in plain English?
I have looked at the standard draft and have been unable to figure out
a single conforming example, not speaking about a single useful one.
If someone can give me such example(s), I am ready to test it (them)
on both OSX and Linux.
>From the above quotation, am I correct to infer that replacing * by 6
will not make the code standard conforming?
TIA
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (12 preceding siblings ...)
2007-02-07 9:24 ` dominiq at lps dot ens dot fr
@ 2007-02-07 19:55 ` dominiq at lps dot ens dot fr
2007-02-08 3:12 ` jvdelisle at gcc dot gnu dot org
` (21 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-07 19:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from dominiq at lps dot ens dot fr 2007-02-07 19:55 -------
The test is known to fail on OSX 10.3 (gcc 4.3.0 20070202) and 10.4 (PPC with
gcc 4.2.0 20070124
and MacIntel gcc unknown).
When I have filled the PR I have forgotten to say that the same bug was present
in
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90
see http://gcc.gnu.org/ml/fortran/2006-11/msg00394.html and following mails in
the thread
for details.
Note that the slightly modified code:
external fun
real fun
character(10) :: string
real a
a = fun()
print *, a
write(string,*) fun()
print *, string
end
real function fun()
print *, 'test'
fun = 1.0
end
gives
test
1.000000
test
At line 7 of file recursive_io.f90
Fortran runtime error: End of record
on both OSX and Linux.
--
dominiq at lps dot ens dot fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|recursive I/O hangs under |recursive I/O hangs under
|OSX 10.3 |OSX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (13 preceding siblings ...)
2007-02-07 19:55 ` [Bug libfortran/30617] recursive I/O hangs under OSX dominiq at lps dot ens dot fr
@ 2007-02-08 3:12 ` jvdelisle at gcc dot gnu dot org
2007-02-08 8:46 ` dominiq at lps dot ens dot fr
` (20 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-02-08 3:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-02-08 03:12 -------
Try :
external fun
real fun
character(10) :: string
real a
a = fun()
print *, a,a
write(string,'(f10.6)') fun()
print *, string
end
real function fun()
print *, 'test'
fun = 1.0
end
Or increase the size of string.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (14 preceding siblings ...)
2007-02-08 3:12 ` jvdelisle at gcc dot gnu dot org
@ 2007-02-08 8:46 ` dominiq at lps dot ens dot fr
2007-02-08 9:36 ` jakub at gcc dot gnu dot org
` (19 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-08 8:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from dominiq at lps dot ens dot fr 2007-02-08 08:45 -------
Subject: Re: recursive I/O hangs under OSX
> Try :
> ...
> Or increase the size of string.
I have increased the length to 20 and in both cases the executable
(for an invalid code!-) works on OSX.
I have also tried:
external fun
character(20) :: fun
i=2
print trim(fun(i)), 99
end
function fun(i)
character(20) :: fun
integer :: i
write(fun,'(A2,I0,A)') "(I", I, ")"
end
which works. Is this last code valid for f95 (-std=f95 does give any
diagnostic)
and/or f2003?
Anyway the hanging seems due to the recursive access to external I/O.
If I want to corner the problem, where should I look? With directions I can
try to locate the problem and test possible fixes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (15 preceding siblings ...)
2007-02-08 8:46 ` dominiq at lps dot ens dot fr
@ 2007-02-08 9:36 ` jakub at gcc dot gnu dot org
2007-02-08 10:03 ` dominiq at lps dot ens dot fr
` (18 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: jakub at gcc dot gnu dot org @ 2007-02-08 9:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from jakub at gcc dot gnu dot org 2007-02-08 09:36 -------
When writing the unit locking code, I relied on Fortran95 requiring that
the same unit isn't used recursively, you can use different units, but not the
same.
gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with
-fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase
is IMHO not valid Fortran95 source.
Now, if Fortran2003 allows some recursive access to the same unit (under which
conditions?), then the gfc_unit's lock could very well be changed into
__gthread_recursive_mutex_t as well as the initializer, perhaps together with
adding a recursion count (as the recursion count in __gthread_recursive_mutex_t
isn't portably accessible) to gfc_unit as well. The question is how much is
libgfortran prepared for changes happening to gfc_unit happening between
say st_write and st_write_done calls (st_write normally calls get_unit and thus
acquires gfc_unit's lock, which is held until st_write_done calls unlock_unit).
For Fortran95, if a hang is in your opinion not a good implementation of
undefined behavior when running a buggy program, if recursive mutex is used
for gfc_unit's lock and a recursion counter is present, then anyone calling
gfc_unit could then check the recursion count and if it is bigger than 1,
unlock_unit it again and report an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (16 preceding siblings ...)
2007-02-08 9:36 ` jakub at gcc dot gnu dot org
@ 2007-02-08 10:03 ` dominiq at lps dot ens dot fr
2007-02-08 12:07 ` dominiq at lps dot ens dot fr
` (17 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-08 10:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from dominiq at lps dot ens dot fr 2007-02-08 10:03 -------
Subject: Re: recursive I/O hangs under OSX
> gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with
> -fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase
> is IMHO not valid Fortran95 source.
When you say "fails" what kind of failure do you get? Is this a timeout or not?
If this is a runtime error, a "seg fault", or whatever but hanging, this is
fine
with me.
> Now, if Fortran2003 allows some recursive access to the same unit (under which
> conditions?)
I think the question is settled: recursive access to external units is invalid.
> then anyone calling gfc_unit could then check the recursion count and if it is bigger than 1,
> unlock_unit it again and report an error.
This seems the path to follow to implement a runtime error, isn't it?
To be frank, I have a very limited understanding of what you are saying, but
I could look again to the code to figure out what it looks like: I understand
more or less the technical concepts, but not the actual implementation.
Thanks for your time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (17 preceding siblings ...)
2007-02-08 10:03 ` dominiq at lps dot ens dot fr
@ 2007-02-08 12:07 ` dominiq at lps dot ens dot fr
2007-02-08 16:18 ` kargl at gcc dot gnu dot org
` (16 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-08 12:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from dominiq at lps dot ens dot fr 2007-02-08 12:06 -------
The following invalid code:
external fun
real fun
real a
a = fun()
! print *, a
write(10,*) fun(), a, 'try it', ' 1.23'
end
real function fun()
print *, 'test'
fun = 1.0
end
gives a working executable when compiled with gfortran on OSX.
However, if I replace "print *," by "write(10,*)" the executable hangs again.
So the problem seems limited to use of the same external unit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (18 preceding siblings ...)
2007-02-08 12:07 ` dominiq at lps dot ens dot fr
@ 2007-02-08 16:18 ` kargl at gcc dot gnu dot org
2007-02-11 20:59 ` pault at gcc dot gnu dot org
` (15 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-02-08 16:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from kargl at gcc dot gnu dot org 2007-02-08 16:18 -------
(In reply to comment #17)
>
> Now, if Fortran2003 allows some recursive access to the same unit
> (under which conditions?),
Recursive IO to external units is simply not allowed by the Fortran
95 and Fortran 2003 standards. You could wade through Brooks
posts in fortran@ to see where recursion is allowed.
> __gthread_recursive_mutex_t as well as the initializer, perhaps together with
> adding a recursion count (as the recursion count in __gthread_recursive_mutex_t
> isn't portably accessible) to gfc_unit as well. The question is how much is
> libgfortran prepared for changes happening to gfc_unit happening between
> say st_write and st_write_done calls (st_write normally calls get_unit and thus
> acquires gfc_unit's lock, which is held until st_write_done calls unlock_unit).
>
This sound like a performance penalty imposed on anyone writing standard
conforming code to permit nonconforming code to run. The fact
remains that a fortran processor can do anything it wants with nonconforming
code. It might "work" on some architecture and it may "fail" another for
some definition of "work" and "fail". So be it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (19 preceding siblings ...)
2007-02-08 16:18 ` kargl at gcc dot gnu dot org
@ 2007-02-11 20:59 ` pault at gcc dot gnu dot org
2007-02-12 7:37 ` dominiq at lps dot ens dot fr
` (14 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: pault at gcc dot gnu dot org @ 2007-02-11 20:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from pault at gcc dot gnu dot org 2007-02-11 20:59 -------
Subject: Bug 30617
Author: pault
Date: Sun Feb 11 20:58:48 2007
New Revision: 121824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121824
Log:
2007-02-11 Paul Thomas <pault@gcc.gnu.org>
PR fortran/30554
* module.c (find_symtree_for_symbol): New function to return
a symtree that is not a "unique symtree" given a symbol.
(read_module): Do not automatically set pointer_info to
referenced because this inhibits the generation of a unique
symtree. Recycle the existing symtree if possible by calling
find_symtree_for_symbol.
PR fortran/30319
* decl.c (add_init_expr_to_sym): Make new charlen for an array
constructor initializer.
2007-02-11 Paul Thomas <pault@gcc.gnu.org>
PR fortran/30554
* gfortran.dg/used_dummy_types_6.f90: Add the "privatized"
versions of the modules.
PR fortran/30617
* gfortran.dg/intrinsic_actual_2.f90: Make this legal fortran
by getting rid of recursive I/O and providing functions with
results.
PR fortran/30319
* gfortran.dg/char_array_constructor_2.f90
Added:
trunk/gcc/testsuite/gfortran.dg/char_array_constructor_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90
trunk/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (20 preceding siblings ...)
2007-02-11 20:59 ` pault at gcc dot gnu dot org
@ 2007-02-12 7:37 ` dominiq at lps dot ens dot fr
2007-02-17 17:17 ` pault at gcc dot gnu dot org
` (13 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-02-12 7:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from dominiq at lps dot ens dot fr 2007-02-12 07:37 -------
Subject: Re: recursive I/O hangs under OSX
> PR fortran/30319
Thanks Paul ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (21 preceding siblings ...)
2007-02-12 7:37 ` dominiq at lps dot ens dot fr
@ 2007-02-17 17:17 ` pault at gcc dot gnu dot org
2007-03-03 13:31 ` fxcoudert at gcc dot gnu dot org
` (12 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: pault at gcc dot gnu dot org @ 2007-02-17 17:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from pault at gcc dot gnu dot org 2007-02-17 17:17 -------
Subject: Bug 30617
Author: pault
Date: Sat Feb 17 17:16:56 2007
New Revision: 122074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122074
Log:
2007-02-17 Paul Thomas <pault@gcc.gnu.org>
PR fortran/30554
* module.c (find_symtree_for_symbol): New function to return
a symtree that is not a "unique symtree" given a symbol.
(read_module): Do not automatically set pointer_info to
referenced, if the symbol has a namespace, because this
inhibits the generation of a unique symtree. Recycle the
symtree if possible by calling find_symtree_for_symbol. If a
symbol is excluded by an ONLY clause, check to see if there is
a symtree already loaded. If so, attach the symtree to the
pointer_info.
PR fortran/30319
* decl.c (add_init_expr_to_sym): Make new charlen for an array
constructor initializer.
2007-02-17 Paul Thomas <pault@gcc.gnu.org>
PR fortran/30554
* gfortran.dg/used_dummy_types_6.f90: New test.
* gfortran.dg/used_dummy_types_7.f90: New test..
PR fortran/30617
* gfortran.dg/intrinsic_actual_2.f90: Make this legal fortran
by getting rid of recursive I/O and providing functions with
results.
PR fortran/30319
* gfortran.dg/char_array_constructor_2.f90
Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_array_constructor_2.f90
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_dummy_types_6.f90
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/used_dummy_types_7.f90
Modified:
branches/gcc-4_2-branch/gcc/fortran/ChangeLog
branches/gcc-4_2-branch/gcc/fortran/decl.c
branches/gcc-4_2-branch/gcc/fortran/module.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_2.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (22 preceding siblings ...)
2007-02-17 17:17 ` pault at gcc dot gnu dot org
@ 2007-03-03 13:31 ` fxcoudert at gcc dot gnu dot org
2007-03-03 20:56 ` burnus at gcc dot gnu dot org
` (11 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-03-03 13:31 UTC (permalink / raw)
To: gcc-bugs
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Last reconfirmed|2007-02-05 22:15:24 |2007-03-03 13:31:17
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (23 preceding siblings ...)
2007-03-03 13:31 ` fxcoudert at gcc dot gnu dot org
@ 2007-03-03 20:56 ` burnus at gcc dot gnu dot org
2007-03-03 21:46 ` dominiq at lps dot ens dot fr
` (10 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-03-03 20:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from burnus at gcc dot gnu dot org 2007-03-03 20:55 -------
Is this actually now fixed or not? I see a 4.2 and a trunk commit. Can this bug
now be closed, is something missing or should it be checked in for 4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (24 preceding siblings ...)
2007-03-03 20:56 ` burnus at gcc dot gnu dot org
@ 2007-03-03 21:46 ` dominiq at lps dot ens dot fr
2007-04-24 10:59 ` jakub at gcc dot gnu dot org
` (9 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-03-03 21:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from dominiq at lps dot ens dot fr 2007-03-03 21:46 -------
> Is this actually now fixed or not?
No, it is not. The commits are for the side effect of test case
intrinsic_actual_2.f90 that has
been fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (25 preceding siblings ...)
2007-03-03 21:46 ` dominiq at lps dot ens dot fr
@ 2007-04-24 10:59 ` jakub at gcc dot gnu dot org
2007-04-24 12:04 ` dominiq at lps dot ens dot fr
` (8 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: jakub at gcc dot gnu dot org @ 2007-04-24 10:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from jakub at gcc dot gnu dot org 2007-04-24 11:59 -------
Please define "fixed". You run an invalid program, all you need is change
your expectations what will happen.
It is the same as if you write
pthread_mutex_t m;
pthread_mutex_init (&m, NULL);
pthread_mutex_lock (&m);
pthread_mutex_lock (&m);
The deadlock might be detected or might not, at which point it would hang.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (26 preceding siblings ...)
2007-04-24 10:59 ` jakub at gcc dot gnu dot org
@ 2007-04-24 12:04 ` dominiq at lps dot ens dot fr
2007-04-24 14:46 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-04-24 12:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 -------
> Please define "fixed".
For me "fixed"=="no hanging" period.
> You run an invalid program,
Yes, I know, repeating that won't help!
> all you need is change your expectations what will happen.
Bugzilla has plenty of entries "ICE on invalid", I am just asking that "hanging
on invalid" is not brushed aside just because it does happen on a platform some
people don't like.
> It is the same as if you write
> pthread_mutex_t m;
> pthread_mutex_init (&m, NULL);
> pthread_mutex_lock (&m);
> pthread_mutex_lock (&m);
> The deadlock might be detected or might not, at which point it would hang.
As far as I can tell, without knowledge of the 'pthread_mutex' mechanism, the
problem does not occur at this level, but at the level of:
pthread_mutex_unlock (&m)
pthread_mutex_unlock (&m)
where the first 'unlock' releases all the previous locks dealing with the same
unit number, leaving the second 'unlock' "waiting for something that is not
coming". Something like:
pthread_mutex_init (&m, NULL);
pthread_mutex_lock (&m);
pthread_mutex_init (&m1, NULL);
pthread_mutex_lock (&m1);
...
pthread_mutex_unlock (&m1)
pthread_mutex_unlock (&m)
is working (see comment #19), so probably if &m refers to some "event" and not
to some "unit number" (not being ashamed to show my ignorance) the problem
would disappear.
I think the following answer from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d3caadeb9083808e/78c9e65c8b4f930e?lnk=gst&q=recursive&rnum=11#78c9e65c8b4f930e
summarize the discussion
Even if this restriction on recursive input/output is
unnecessary or undesireable, it is, nonetheless, a part
of the Fortran 2003 standard.
Note the "unnecessary or undesireable", leading me to the following comments:
(1) the use of recursive I/O can be detected at run time: xlf does it;
I guess that a second locking of '&m' would not be too difficult to detect and
I don't buy the efficiency argument at this level (gfortran did not strike me
as being any faster than xlf on I/O operations);
(2) the behavior, however "processor" (fortran meaning) dependent it is, should
be platform independent: just imagine the port to OSX of a 100kloc code where
one such recusive I/O used for debuging on Linux (it works) has been left;
(3) I repeat that I am not asking for an immediate fix, only that the problem
is not forgotten due to the 'invalid' label.
Anyway, thanks for the answer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (27 preceding siblings ...)
2007-04-24 12:04 ` dominiq at lps dot ens dot fr
@ 2007-04-24 14:46 ` pinskia at gcc dot gnu dot org
2007-04-24 14:59 ` dominiq at lps dot ens dot fr
` (6 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-04-24 14:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from pinskia at gcc dot gnu dot org 2007-04-24 15:46 -------
> Bugzilla has plenty of entries "ICE on invalid", I am just asking that "hanging
> on invalid" is not brushed aside just because it does happen on a platform some
> people don't like.
It is hanging on undefined, I think there is a difference here, a big
difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (28 preceding siblings ...)
2007-04-24 14:46 ` pinskia at gcc dot gnu dot org
@ 2007-04-24 14:59 ` dominiq at lps dot ens dot fr
2008-07-11 22:19 ` dominiq at lps dot ens dot fr
` (5 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-04-24 14:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from dominiq at lps dot ens dot fr 2007-04-24 15:59 -------
> It is hanging on undefined, I think there is a difference here, a big
> difference.
What is the difference for you?
Just as a side note, that's not me who classed the PR as invalid and so far I
did not see a class "ICE on undefined".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (29 preceding siblings ...)
2007-04-24 14:59 ` dominiq at lps dot ens dot fr
@ 2008-07-11 22:19 ` dominiq at lps dot ens dot fr
2008-07-11 22:22 ` dominiq at lps dot ens dot fr
` (4 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-07-11 22:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from dominiq at lps dot ens dot fr 2008-07-11 22:18 -------
>From pr36806 I think the mutex behavior on Darwin needs to be better understood
(handled).
To answer comment #28, this bug has been "resolved" as "invalid" and not as
"undefined"!
--
dominiq at lps dot ens dot fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] recursive I/O hangs under OSX
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (30 preceding siblings ...)
2008-07-11 22:19 ` dominiq at lps dot ens dot fr
@ 2008-07-11 22:22 ` dominiq at lps dot ens dot fr
2009-05-07 22:00 ` [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O dominiq at lps dot ens dot fr
` (3 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-07-11 22:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #31 from dominiq at lps dot ens dot fr 2008-07-11 22:21 -------
Forgot to say that the problem is still there for ppc/intel Darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (31 preceding siblings ...)
2008-07-11 22:22 ` dominiq at lps dot ens dot fr
@ 2009-05-07 22:00 ` dominiq at lps dot ens dot fr
2009-12-14 20:43 ` dominiq at lps dot ens dot fr
` (2 subsequent siblings)
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-05-07 22:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #32 from dominiq at lps dot ens dot fr 2009-05-07 22:00 -------
Presently invalid recursive I/Os are accepted by gfortran without any
diagnostic at run time. It could be helpful to implement such a diagnostic with
something such as -fcheck=recursive_IO.
Note that xlf gives a run time error for invalid recursive I/Os.
--
dominiq at lps dot ens dot fr changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gmail dot com
GCC target triplet|*-apple-darwin* |
Keywords| |diagnostic
Summary|recursive I/O hangs under |Implement a run time
|OSX |diagnostic for invalid
| |recursive I/O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (32 preceding siblings ...)
2009-05-07 22:00 ` [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O dominiq at lps dot ens dot fr
@ 2009-12-14 20:43 ` dominiq at lps dot ens dot fr
2009-12-14 20:46 ` dominiq at lps dot ens dot fr
2009-12-14 20:52 ` dominiq at lps dot ens dot fr
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-12-14 20:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #33 from dominiq at lps dot ens dot fr 2009-12-14 20:43 -------
Created an attachment (id=19296)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19296&action=view)
assembly generated with -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (33 preceding siblings ...)
2009-12-14 20:43 ` dominiq at lps dot ens dot fr
@ 2009-12-14 20:46 ` dominiq at lps dot ens dot fr
2009-12-14 20:52 ` dominiq at lps dot ens dot fr
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-12-14 20:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #34 from dominiq at lps dot ens dot fr 2009-12-14 20:45 -------
Created an attachment (id=19297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19297&action=view)
assembly generated without -frename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 dominiq at lps dot ens dot fr
` (34 preceding siblings ...)
2009-12-14 20:46 ` dominiq at lps dot ens dot fr
@ 2009-12-14 20:52 ` dominiq at lps dot ens dot fr
35 siblings, 0 replies; 37+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-12-14 20:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #35 from dominiq at lps dot ens dot fr 2009-12-14 20:51 -------
Wrong pr. Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 37+ messages in thread