[patch, libgfortram] PR32456 IO error message should show Unit/Filename
Jerry DeLisle
jvdelisle@verizon.net
Thu Jun 28 00:48:00 GMT 2007
Andreas Tobler wrote:
> Jerry DeLisle wrote:
>
>> 2007-06-24 Jerry DeLisle <jvdelisle@gcc.gnu.org>
>>
>> PR libgfortran/32456
>> * runtime/error.c (show_locus): Update to emit the unit number
>> and file name involved with the error. Use new function
>> filename_from_unit.
>> * libgfortran.h (filename_from_unit): Declare new function.
>> * io/unit.c (init_units): Set the unit file name for stdin, stdout,
>> and stderr for use later in error reporting.
>> (filename_from_unit): Add this new function.
>>
>
> Fyi, this one causes several timeouts on darwin {ppc|x86} in the
> gfortran testsuite.
>
> FAIL: gfortran.dg/error_format.f90 -O0 output pattern test, is ,
> should match .*(unit = 99, file = .*)Fortran runtime error: End of file
> WARNING: program timed out.
>
> [imac-catherine:gcc/testsuite/gfortran] andreast% gdb
> error_format.exeGNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct
> 20 15:50:43 GMT 2006)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-apple-darwin"...Reading symbols for
> shared libraries .... done
>
> (gdb) r
> Starting program:
> /Volumes/development/devel/gcc/head/objdir-single/gcc/testsuite/gfortran/error_format.exe
>
> Reading symbols for shared libraries .+ done
> ^C
> Program received signal SIGINT, Interrupt.
> 0x900248c7 in semaphore_wait_signal_trap ()
> (gdb) bt
> #0 0x900248c7 in semaphore_wait_signal_trap ()
> #1 0x90001582 in pthread_mutex_lock ()
> #2 0x00277cda in __gthread_mutex_lock ()
> #3 0x00277fee in get_external_unit ()
> #4 0x0027814b in _gfortrani_find_unit ()
> #5 0x00278b83 in _gfortrani_filename_from_unit ()
> #6 0x00207527 in *__gfortrani_show_locus (cmp=0xbffff3d8) at
> /Volumes/development/devel/gcc/head/gcc/libgfortran/runtime/error.c:258
> #7 0x00207b46 in *__gfortran_generate_error (cmp=0xbffff3d8, family=-1,
> message=0x28a12c "End of file") at
> /Volumes/development/devel/gcc/head/gcc/libgfortran/runtime/error.c:502
> #8 0x00277981 in *__gfortran_st_read (dtp=0xbffff3d8) at
> /Volumes/development/devel/gcc/head/gcc/libgfortran/io/transfer.c:2758
> #9 0x00001d56 in MAIN__ ()
> #10 0x000017a2 in _start ()
> #11 0x000016c9 in start ()
>
It looks to me like locking is handled differently on this platform then others.
When you execute the program, does it just hang without using CPU cycles?
I have an idea on how to get around this, but I will need others to test since I
do not have access to this system.
I will try to have something tonight or tomorrow night.
Thanks for the report. It was also reported by Jack Howarth, but I had not
heard back from him yet.
Regards,
Jerry
More information about the Fortran
mailing list