Massive failures

[Steve Kargl]

On Wed, Apr 12, 2006 at 12:50:39PM -0700, DeLisle, Jerry V wrote:
> I don't think its anything Jakub and I have done.  I won't have time to
> look around until tonight.  Any more data available on this?
> 
> I am at work so must keep this brief.
> 

I think I've come to some conclusion with the massive regressions.
A new memory allocator was committed to FreeBSD in mid-January,
and this is the first time I've updated since that allocator was
available.  This allocator has the feature that all newly allocated
or freed bytes of memory are set to 0xa5.  It appears that libgfortran
is making some really bad assumptions with regards to whether
memory is explicitly or implicitly bzero'd.

With the following patch:

Index: transfer.c
===================================================================
--- transfer.c	(revision 112881)
+++ transfer.c	(working copy)
@@ -2353,9 +2353,11 @@ st_write_done (st_parameter_dt *dtp)
 
       case NO_ENDFILE:
 	/* Get rid of whatever is after this record.  */
+#if 0
 	flush (dtp->u.p.current_unit->s);
 	if (struncate (dtp->u.p.current_unit->s) == FAILURE)
 	  generate_error (&dtp->common, ERROR_OS, NULL);
+#endif
 
 	dtp->u.p.current_unit->endfile = AT_ENDFILE;
 	break;

I get the expected testsuite result:

		=== gfortran Summary ===

# of expected passes		12202
# of unexpected failures	8
# of expected failures		8
# of unsupported tests		56
/usr/home/sgk/gcc/obj41/gcc/testsuite/gfortran/../../gfortran  version 4.1.1 20060412 (prerelease)

instead of the 560 unexpected failures.  Can others on the list
test other OS's with electric fence or dmalloc or some other 
strict memory allocator.

-- 
Steve