--- 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
--- 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
--- 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 clas
--- 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 unde
--- 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 plen
--- 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);
--- 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
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2007-02-05 22:15:24 |2007-03
--- 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 <[EMAIL PROTECTED]>
PR fortran
--- 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
--- 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 <[EMAIL PROTECTED]>
PR fortran
--- 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 st
--- 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
--- 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 val
--- 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
--- 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 trie
--- 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 stri
--- 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://
--- 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
>
--- 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
--- 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
--- 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/../gc
--- 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
--- 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.00
^C
[pactech01:~/tests] dir% cat recursiveio.f90
external fun
--- 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 undefi
--- 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
--- 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
--- 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
29 matches
Mail list logo
