[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