Re: An excessive commit - check recent changes to alocal, configure, all any and count

Tom,

Thanks for that; it is now stored away under ~/first_aid

Once again, sorry everybody - it will not happen again, if only for the 
advice and help that you have all given.

Paul T 

Re: libgfortran.so and C I/O

> Does this also effect stdout and stderr?

Good question. The ansewr is yes, and everything I mentionned applied.

As for the performance issue, I did some profiling, and it couldn't see 
any difference in execution time between mmap-ed and non mmap-ed output 
unit. This is mainly because pre-connected units are formatted, and 
formatting time is what takes all the time.

So, I'm now fully convinced (I'l still be glad to have your opinion, of 
course) we need such a patch for non mmap-ed preconnected units. Will 
post it on Monday.

FX

walking a namespace to check a symbol name?

How does one walk a namespace to determine if a name
has previous been used?  The following program is 
illegal (see PR 21257)

   program f
   integer i,j
   loop: do i = 1, 5
            print *, i
         end do loop
   loop: do j = 1, 5
            print *, j
         end do loop
   end program f

because the do-construct-name is not unique (Thanks,
Richard for forsing me to read 14.1.2(1) several times).
Note, a similar problem also affects if-construct-name
and case-construct-name via gfc_match_label() in match.c.

Oddly, there is code to catch a nested do-construct-name,
for example:

   loop: do i = 1, 5
            print *, i
            loop: do j = 1, 5
                     print *, j
                  end do loop
         end do loop

--

-- 

Re: [patch, libfortran] Fix PR 18958

Please note that, for this patch to work, you'll need to manually
touch the relevant C files (PR 19273).  Otherwise, you'll get
a testsuite failure with the new test case.

	Thomas

Re: walking a namespace to check a symbol name?

Steve Kargl wrote:
> How does one walk a namespace to determine if a name
> has previous been used?  The following program is 
> illegal (see PR 21257)
> 
>    program f
>    integer i,j
>    loop: do i = 1, 5
>             print *, i
>          end do loop
>    loop: do j = 1, 5
>             print *, j
>          end do loop
>    end program f
> 
> because the do-construct-name is not unique (Thanks,
> Richard for forsing me to read 14.1.2(1) several times).
> Note, a similar problem also affects if-construct-name
> and case-construct-name via gfc_match_label() in match.c.

Sounds like you want to call gfc_find_symbol from gfc_match_do, giving an
error if the symbol already exists.

- Tobi

[patch] Clean up testsuite/gfortran.dg/vect files

I will commit the following patch as obvious once a full build/test 
cycle is complete.  Tested on i686-pc-cygwin.

2005-05-02  David Billinghurst  <David.Billinghurst <at> riotinto.com>

	* gfortran.dg/vect/vect-1.f90:  Clean up .vect file.
	* gfortran.dg/vect/vect-2.f90:  Likewise
	* gfortran.dg/vect/vect-3.f90:  Likewise
	* gfortran.dg/vect/vect-4.f90:  Likewise
	* gfortran.dg/vect/vect-5.f90:  Likewise

--- vect-1.f90  29 Mar 2005 16:10:22 -0000      1.2
+++ vect-1.f90  1 May 2005 23:51:45 -0000
 <at>  <at>  -8,3 +8,4  <at>  <at> 
 END

 ! { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" } }
+! { dg-final { cleanup-tree-dump "vect" } }

--- vect-2.f90  29 Mar 2005 16:10:22 -0000      1.2
+++ vect-2.f90  1 May 2005 23:51:45 -0000
 <at>  <at>  -11,3 +11,4  <at>  <at> 
 ! { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" { xfail vect_no_align } } }
 ! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 3 "vect" { xfail
vect_no_align } } }
 ! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" { xfail vect_no_align } } }
+! { dg-final { cleanup-tree-dump "vect" } }

--- vect-3.f90  29 Mar 2005 16:10:22 -0000      1.2
+++ vect-3.f90  1 May 2005 23:51:45 -0000

[rfc] Cleaning up .mod files from testsuite runs

The cruft accumulating in the build testsuite directory is 
distracting me.  For the gfortran.dg tests we can delete 
module files with the dejagnu incantantion below.

How do people feel about this?  I can prepare a patch for the 
other cases if people think it is worth doing.

 
Index: contained_1.f90
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gfortran.dg/contained_1.f90,v
retrieving revision 1.1
diff -u -r1.1 contained_1.f90
--- contained_1.f90     11 Jul 2004 23:00:08 -0000      1.1
+++ contained_1.f90     2 May 2005 06:18:06 -0000
 <at>  <at>  -31,3 +31,5  <at>  <at> 
   call a
   if (i .ne. 1) call abort
 end program
+
+! { dg-final { remove-build-file "contained_1_mod.mod" } }

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.

Re: [rfc] Cleaning up .mod files from testsuite runs

> How do people feel about this?  I can prepare a patch for the 
> other cases if people think it is worth doing.

There are lots of testcases using modules, and will certainly be more in the 
future. Couldn't we add a general mechanism to do this (question is, is 
there any case where we have a .mod file that we'd like to keep after a 
testcase is run)?

FX

[gfortran] patch PR 20788

Dynamically loading libgfortran.so breaks C I/O routines when stdout is 
redirected to a file (same thing for stdin and stderr). This annoys people 
dynamically loading Fortran subroutines for use in a C project (example: R,
see PR fortran/20788 for details).

Attached patch fixes this by disabling use of mmap on stdin, stdout and 
stderr. Profiling shows no performance degradation (all time spent in I/O on 
preconnected units is formatting).

Regtested on i386-linux. OK for mainline and 4.0?

2005-05-02  Francois-Xavier Coudert  <coudert <at> clipper.ens.fr>

	PR libfortran/20788
	* io/unix.c (fd_to_stream): Add an avoid_mmap argument indicating
	we don't we to mmap this stream. Use fd_open instead of mmap_open
	in that case.
	(open_external): Call fd_to_stream with avoid_mmap = 0.
	(input_stream): Call fd_to_stream with avoid_mmap = 1.
	(output_stream): Likewise.
	(error_stream): Likewise.

Re: gfortran on MacOS X

Am 28.04.2005 um 21:48 schrieb Bill Northcott:

> On 29/04/2005, at 1:02 AM, Dominik Epple wrote:
>>> I have managed to build gfortran as part of an Apple gcc-4.0 
>>> compiler on MacOS X 10.3.9.  The code was tagged apple-ppc-5009 and 
>>> seems to be merged with FSF code as at 6 April 2005.
>>>
>>> By adding 'f95' to the --enable-languages line in Apple's 
>>> 'build_gcc' script, I can get gfortran to configure.
>> could you please explain in detail how you did this? Where did you 
>> get this script from? Was it part of an archive? With which arguments 
>> did you run the script?
>
> If you pull gcc code from the cvs with a tag like apple-gcc-50XX you 
> will get the Apple Darwin gcc code including the build script.  There 
> is a file of build instructions README.APPLE.
>>
>> Downloading a googled version of this script and invoking it with 
>> some fancy parameters,
>>
>> ../build_gcc ppc ppc /Users/dominik/gcc-4.0.0 /Users/dominik/destroot 
>> /Users/dominik/destdir /Users/dominik/destinfo
>
> Follow the instructions in README.APPLE.  The script expects a number 
> of environment variables, and will only work on Apple gcc code.  The 
> Apple build does two staging installs.  The first into a standard FSF 
> file layout within the build directory and then a copy from there into 
> an Apple style layout under dst/.  It is that second copy which omits 
> the static libraries.  Once you have an Apple file arrangement in