public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
@ 2013-02-27 18:19 ` dominiq at lps dot ens.fr
2014-05-20 13:58 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-02-27 18:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefano.borini at ferrara
| |dot linux.it
--- Comment #36 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-27 18:18:38 UTC ---
*** Bug 51286 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
2013-02-27 18:19 ` [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O dominiq at lps dot ens.fr
@ 2014-05-20 13:58 ` dominiq at lps dot ens.fr
2014-08-03 0:08 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-05-20 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter.machon at arcor dot de
--- Comment #37 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 61251 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
2013-02-27 18:19 ` [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O dominiq at lps dot ens.fr
2014-05-20 13:58 ` dominiq at lps dot ens.fr
@ 2014-08-03 0:08 ` dominiq at lps dot ens.fr
2014-10-16 13:50 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-08-03 0:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jannis at teunissen dot net
--- Comment #38 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 62000 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-08-03 0:08 ` dominiq at lps dot ens.fr
@ 2014-10-16 13:50 ` jakub at gcc dot gnu.org
2014-10-16 13:57 ` sidio47 at hotmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-10-16 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #29)
> > 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".
Just because you've mentioned this PR:
There is a significant difference. ICE on invalid is something clearly
undesirable, because it is the compiler that is crashing, and compiler should
not have undefined behavior on whatever garbage you throw at it.
If you compile code with undefined behavior in it, run it and that code
crashes, hangs or formats your disk, that is a bug in the code you are running,
not in the compiler. Anything can happen when you invoke undefined behavior.
And anything includes hanging, segfault, formatting your disk etc.
E.g. if you invoke undefined behavior in some loop, gcc will often optimize
away loop bound checks in that case (on the assumption that in valid code, the
loop e.g. could be invoked only certain number of iterations and not more).
So, you may very well get a hang in that case too.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-10-16 13:50 ` jakub at gcc dot gnu.org
@ 2014-10-16 13:57 ` sidio47 at hotmail dot com
2015-08-26 17:12 ` fxcoudert at gcc dot gnu.org
2020-11-28 22:54 ` dominiq at lps dot ens.fr
6 siblings, 0 replies; 11+ messages in thread
From: sidio47 at hotmail dot com @ 2014-10-16 13:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Cyrus <sidio47 at hotmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sidio47 at hotmail dot com
--- Comment #40 from Cyrus <sidio47 at hotmail dot com> ---
*** Bug 63561 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-10-16 13:57 ` sidio47 at hotmail dot com
@ 2015-08-26 17:12 ` fxcoudert at gcc dot gnu.org
2020-11-28 22:54 ` dominiq at lps dot ens.fr
6 siblings, 0 replies; 11+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-26 17:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2007-03-03 13:31:17 |2015-8-26
CC| |fxcoudert at gcc dot gnu.org
--- Comment #41 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #39)
> Anything can happen when you invoke undefined behavior.
Yes. Yet, as a "quality of implementation" issue, it is desirable for us to
detect and error out on recursive I/O. Simply as indicated by the number of
duplicates of this bug, it's a common occurrence (currently on Darwin, but I
think there is no guarantee that the deadlocks don't start manifesting
themselves anytime on another platform).
The question is: can we do it with the current lock implementation? Do we have
a way to check, when we want to acquire that lock (get_external_unit), in the
case where the lock is already held, whether it's by the same thread or not.
I.e., prevent the deadlock.
I don't know how the gthread API works, but POSIX threads allow that if I read
correctly: using a PTHREAD_MUTEX_ERRORCHECK-type mutex and check for EDEADLK on
pthread_mutex_lock(). Jakub, does this sound possible the way I propose it?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-08-26 17:12 ` fxcoudert at gcc dot gnu.org
@ 2020-11-28 22:54 ` dominiq at lps dot ens.fr
6 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-11-28 22:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anthony.debeus at gmail dot com
--- Comment #42 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 98046 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3
@ 2007-01-27 19:47 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 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: dominiq at lps dot ens dot fr @ 2007-01-27 19:47 UTC (permalink / raw)
To: gcc-bugs
The executable of the following code:
external fun
real fun
real a
a = fun()
print *, a
print *, fun()
end
real function fun()
print *, 'test'
fun = 1.0
end
compiled with 4.3.0 20070126, hangs. -fdump-tree-original gives:
MAIN__ ()
{
real4 a;
_gfortran_set_std (70, 127, 0, 0);
a = fun ();
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = "fun_external.f90";
dt_parm.0.common.line = 5;
dt_parm.0.common.unit = 6;
dt_parm.0.common.flags = 128;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_real (&dt_parm.0, &a, 4);
_gfortran_st_write_done (&dt_parm.0);
}
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = "fun_external.f90";
dt_parm.1.common.line = 6;
dt_parm.1.common.unit = 6;
dt_parm.1.common.flags = 128;
_gfortran_st_write (&dt_parm.1);
{
real4 D.951;
D.951 = fun ();
_gfortran_transfer_real (&dt_parm.1, &D.951, 4);
}
_gfortran_st_write_done (&dt_parm.1);
}
}
fun ()
{
real4 __result_fun;
{
struct __st_parameter_dt dt_parm.2;
dt_parm.2.common.filename = "fun_external.f90";
dt_parm.2.common.line = 9;
dt_parm.2.common.unit = 6;
dt_parm.2.common.flags = 128;
_gfortran_st_write (&dt_parm.2);
_gfortran_transfer_character (&dt_parm.2, "test", 4);
_gfortran_st_write_done (&dt_parm.2);
}
__result_fun = 1.0e+0;
return __result_fun;
}
and if run under gdb, after ^C, where gives:
#0 0x90017238 in semaphore_wait_signal_trap ()
#1 0x90001d90 in pthread_mutex_lock ()
#2 0x0020093c in get_external_unit (n=6, do_create=3331) at
../../../gcc-4.3-20070127/libgfortran/../gcc/gthr-posix.h:604
#3 0x001ff6e0 in data_transfer_init (dtp=0x6004d8, read_flag=3331) at
../../../gcc-4.3-20070127/libgfortran/io/transfer.c:1698
#4 0x00002b48 in fun_ () at fun_external.f90:9
#5 0x00002abc in MAIN__ () at fun_external.f90:6
#6 0x00002bac in main (argc=14, argv=0xd03) at
../../../gcc-4.3-20070127/libgfortran/fmain.c:18
Note that I see the same problem on OSX 10.4 with gcc version 4.2.0 20060617.
Any idea around?
--
Summary: recursive I/O hangs under OSX 10.3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-28 22:54 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-30617-4@http.gcc.gnu.org/bugzilla/>
2013-02-27 18:19 ` [Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O dominiq at lps dot ens.fr
2014-05-20 13:58 ` dominiq at lps dot ens.fr
2014-08-03 0:08 ` dominiq at lps dot ens.fr
2014-10-16 13:50 ` jakub at gcc dot gnu.org
2014-10-16 13:57 ` sidio47 at hotmail dot com
2015-08-26 17:12 ` fxcoudert at gcc dot gnu.org
2020-11-28 22:54 ` dominiq at lps dot ens.fr
2007-01-27 19:47 [Bug fortran/30617] New: recursive I/O hangs under OSX 10.3 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
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
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).