headers
Billinghurst, David (CALCRTS | 1 Sep 2004 01:19
Picon

RE: Testsuite results on amd64-unknown-freebsd

fortran-owner <at> gcc.gnu.org wrote:
> We have one failure that suggest we have a 32-bit vs
> 64-bit issue.
> 
> FAIL: gfortran.dg/der_array_1.f90  -O0  execution test
> Fortran runtime error: shape and target do not conform

gfortran.dg/der_array_1.f90 passes with the -n32 ABI but 
fails with the -64 ABI on irix6.5, which support the 32-bit
vs 64-bit theory.

__________________________________________________________________

NOTICE

This e-mail and any attachments are private and confidential and 
may contain privileged information.

If you are not an authorised recipient, the copying or distribution 
of this e-mail and any attachments is prohibited and you must not 
read, print or act in reliance on this e-mail or attachments.

This notice should not be removed.
__________________________________________________________________
Permalink | Reply | 0 comments |
headers
Paul Brook | 1 Sep 2004 01:42
Gravatar

[gfortran] Handle end= and iostat=

The end= specifier was being ignored on IO data transfer statements when the 
iostat= specified was also used. Patch below fixes this.

Tested on i686-linux.
Applied to mainline.

Paul

2004-09-01  Paul Brook  <paul <at> codesourcery.com>

 * runtime/error.c (generate_error): Set both iostat and
 library_return.
testsuite/
 * gfortran.dg/eof_2.f90: New test.

Index: runtime/error.c
===================================================================
RCS file: /var/cvsroot/gcc-cvs/gcc/libgfortran/runtime/error.c,v
retrieving revision 1.4
diff -u -p -r1.4 error.c
--- runtime/error.c 28 Aug 2004 19:48:02 -0000 1.4
+++ runtime/error.c 31 Aug 2004 21:46:13 -0000
 <at>  <at>  -445,13 +445,11  <at>  <at>  translate_error (int code)
 void
 generate_error (int family, const char *message)
 {
-
+  /* Set the error status.  */
   if (ioparm.iostat != NULL)
-    {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Sep 2004 02:37
Picon

Memory corruption on amd64 FreeBSD

Paul,

The good news is that one of my research codes is running
on amd64-unknown-freebsd.  The bad news is a second code is
giving me a seg fault in runtime/memory.c.  Both codes 
make use of allocate/deallocate, but the second code
does many more allocate/deallocate pairs.

dhcp-78-96:kargl[203] gdb ../tdi tdi.core
GNU gdb 6.1.1 [FreeBSD]
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 "amd64-marcel-freebsd"...
Core was generated by `tdi'.
Program terminated with signal 11, Segmentation fault.
#0  _gfortran_internal_free (mem=Variable "mem" is not available.
)
    at ../../../gcc/libgfortran/runtime/memory.c:210

warning: Source file is more recent than executable.

210       m->next->prev = m->prev;
(gdb) bt
#0  _gfortran_internal_free (mem=Variable "mem" is not available.
)
    at ../../../gcc/libgfortran/runtime/memory.c:210
#1  0x0000000000415655 in _gfortran_deallocate (mem=0x7fffffffe080, stat=0x0)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Bud Davis | 1 Sep 2004 04:31
Picon

misc topics in the i/o library

Here are a few possible improvements to the I/O library that have been
rattling around in my head. 

#1/  unformatted sequential I/O performance.  fortran people just love 
     this stuff (personally, I like a data file that can be read by vi,
     not hexdump).  
     there is an open PR on the performance being poor.
     (short example)

         integer X(10000)
         write(7)X

     the slowness is probably caused by transferring a single integer
     10000 times. How can we tell the run-time that this is a contiguous
     block of memory and it can be written in one big hunk ?

     another thing people like to do is write small records. these take
     a performance hit because we have to seek back to the beginning to
     write the byte count.  if the front end could tell tell us how big
     the record is going to be prior to sending the data, that would be
     a time saver.  Is this possible ?

#2.  The size of the REC= parameter in the write statements and some
     of the open statement parameters do not support 64 bit integers.
     (PR 16288 is a possibility here)
     This is needed to handle Really Big Files.  
     I don't see how we can support this with the mechanisms currently
     in place. trans-io.c (set_parameter_value, set_parameter_reference)

#3.  size of chunk used for mmap.  it is too small.  why not just mmap
(Continue reading)

Permalink | Reply | 2 comments |
headers
enlight1 | 1 Sep 2004 07:42
Picon

Re: Memory corruption on amd64 FreeBSD

On Tue, 2004-08-31 at 17:37, Steve Kargl wrote:
> Paul,
> 
> The good news is that one of my research codes is running
> on amd64-unknown-freebsd.  The bad news is a second code is
> giving me a seg fault in runtime/memory.c.  Both codes 
> make use of allocate/deallocate, but the second code
> does many more allocate/deallocate pairs.
I also am getting a segfault on some code that uses a lot of
allocate/deallocate.  I am unable to isolate yet.  This is on i686
linux.  

It compiles very cleanly.  

Jerry
Permalink | Reply | 1 comment |
headers
Steve Kargl | 1 Sep 2004 07:48
Picon

Re: Memory corruption on amd64 FreeBSD

On Tue, Aug 31, 2004 at 10:42:20PM -0700, enlight1 wrote:
> On Tue, 2004-08-31 at 17:37, Steve Kargl wrote:
> > 
> > The good news is that one of my research codes is running
> > on amd64-unknown-freebsd.  The bad news is a second code is
> > giving me a seg fault in runtime/memory.c.  Both codes 
> > make use of allocate/deallocate, but the second code
> > does many more allocate/deallocate pairs.
> I also am getting a segfault on some code that uses a lot of
> allocate/deallocate.  I am unable to isolate yet.  This is on i686
> linux.  
> 
> It compiles very cleanly.  
> 

Disaster struck tonight :-(

I downloaded the problematic code from my amd64 FreeBSD system
to my home i386 athlon system.  While updating Makefiles and the
directory structure to test the segfault problem, I managed to
delete my entire testsuite.  The nearly half million lines of
Fortran are easy to recover, but my build infrastructure was
not properly backed up.  This is going to take a few days to
reconstuct.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Paul Brook | 1 Sep 2004 13:13
Gravatar

Re: misc topics in the i/o library

On Wednesday 01 September 2004 03:31, Bud Davis wrote:
> Here are a few possible improvements to the I/O library that have been
> rattling around in my head.
>
> #1/  unformatted sequential I/O performance.  fortran people just love
>      this stuff (personally, I like a data file that can be read by vi,
>      not hexdump).
>      there is an open PR on the performance being poor.
>      (short example)
>
>          integer X(10000)
>          write(7)X
>
>      the slowness is probably caused by transferring a single integer
>      10000 times. How can we tell the run-time that this is a contiguous
>      block of memory and it can be written in one big hunk ?

I can think of two ways of doing this:

(a) Pass an array descriptor to the IO routine. This can then decide whether 
to iterate, write it out as a block or do something else clever. Care needs 
to be taken with derived types.
Incurs slightly more overhead in the fastest case (your example above), but 
still much better than the current code. It allows us to "optimize" cases 
that can't be proved at compile time, eg. pointer variables.

(b) Pass a pointer+number of elements, and only use it when we know the 
elements are sequential. This can only be used when the compiler knows the 
array is contiguous (eg. your example above). For other cases (eg. pointers) 
we need to fall back to the existing system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Schlüter | 1 Sep 2004 14:50
Picon
Favicon

[gfortran] Change libgfortran license to GPL+exception


Following Mike Stump's advice, I prepared a patch which changes libgfortran to
GPL+exception. I've taken the wording from libgcc2.c and changed all files
which had a copyright header to use that license (the only ones which don't
are a few m4 scripts, and fmain.c, which probably is not copyrightable). I
also added 2004 to the copyright years, as I assumed that this change would be
copyrightable.

Previous licenses some files were plain GPL, a few said LGPL. Besides this, I
also fixed one glaring typo in the header of runtime/pause.c and added a
copyright line to runtime/select.c, after verifying which years had to be added.

Patch gzipped due to its size and its repetitive nature (>200kb, the gzipped
version is <8kb).

I verified that the library still builds, but I haven't regenerated the
generated files. Paul, could you please apply the patch and do this, if it
gets approved?

Thanks,
- Tobi

2004-09-01  Tobias Schlueter  <tobias.schlueter <at> physik.uni-muenchen.de>
	
	* all files: Change copyright header to GPL+exception, add 2004 to
	copyright years.
	* runtime/pause.c: In addition, fix typo.
	* runtime/select.c: In addition, add copyright line.
(Continue reading)

Permalink | Reply | 30 comments |
headers
Eric Botcazou | 1 Sep 2004 19:01
Picon

Re: [libgfortran] generate tables of kinds

>         * mk-sik-inc.sh, mk-srk-inc.sh: New files.

Broke bootstrap on Solaris/SPARC because we recommend using ksh and according 
to the 'echo' man page: "In addition, ksh's echo does not have a -n option. 
sh's echo and /usr/bin/echo only have a -n option if the SYSV3 environment 
variable is set (see ENVIRONMENT below)."

I've attached a patch to fix the problem.  It allows bootstrap to complete on 
SPARC 32-bit, but not on SPARC 64-bit where I get:

 In file /home/eric/cvs/gcc/libgfortran/intrinsics/selected_real_kind.f90:61

end function
           1
 Internal Error at (1):
 gfc_validate_kind(): Got bad kind

The selected_real_kind.inc file reads:

  integer, parameter :: c = 3
  type (real_info), parameter :: real_infos(c) = (/ &
    real_info (4, precision(0.0_4), range(0.0_4)), &
    real_info (8, precision(0.0_8), range(0.0_8)), &
    real_info (16, precision(0.0_16), range(0.0_16)) /)

and is the same as for SPARC 32-bit, so I'm leaning towards a more subtle 
problem, maybe a miscompilation somewhere.  At the ICE point:

Breakpoint 5, gfc_validate_kind (type=BT_LOGICAL, kind=345088, may_fail=0 
'\0')
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Henderson | 1 Sep 2004 19:42
Picon
Favicon

Re: [libgfortran] generate tables of kinds

On Wed, Sep 01, 2004 at 07:01:41PM +0200, Eric Botcazou wrote:
> 	* mk-sik-inc.sh: Use a temporary string instead of 'echo -n'.
> 	* mk-srk-inc.sh: Likewise.

Ok.

I'll have a look at the sparc64 problem, but please do 
create a pr for it.

r~
Permalink | Reply | 1 comment |

Gmane