Re: I'm back -- ISO C binding merge plans.

Hi Steve,

Steve Kargl wrote:
> I'm back from my recent foray into ocean acoustics.  Although my
> gfortran time over the next few weeks is going to be small, I intend
> to constantly merge mainline into my local fortran-experiments
>   
If the fortran-experiments branch is up to date, one can use
diff -x .svn -u -rN
to compare the branch with the trunk.

> and hopefully cut a ISO C binding patch against mainline for submission.
> Chris has done an outstanding job on implementing this feature, and
> think it is time to integrate it into gfortran 4.3.  Yes, there are
> some missing parts (eg procedure pointer) and there may be some things
> that need so cleanup, but it is time.  I would like to see Chris'
> code committed to mainline in the next few weeks.
>   
That would be great. One thing I would like to see be fixed before the
merge is the namespacing FX mentioned the other day.
(Chris uses in libgfortran the ISO_C_BINDING_PREFIX macro, which should
be converted into export_proto/iexport_proto/export/iexport macros.)

In addition, one needs to change the kind test as it currently fails
(C_INT_FAST*_T is not available). I have a modified test (see
attachment), ok for check in?

(Could you check whether loop_nest_1.f90 and pr29581.f90 fail for you?
Chris had problems with those whereas I couldn't reproduce the problems.)

Re: I'm back -- ISO C binding merge plans.

On 3/31/07, Tobias Burnus <burnus <at> net-b.de> wrote:
> Hi Steve,
>
> Steve Kargl wrote:
> > I'm back from my recent foray into ocean acoustics.  Although my
> > gfortran time over the next few weeks is going to be small, I intend
> > to constantly merge mainline into my local fortran-experiments
> >
> If the fortran-experiments branch is up to date, one can use
> diff -x .svn -u -rN
> to compare the branch with the trunk.

Actually you can do it all via "svn diff
svn://gcc.gnu.org/svn/gcc/branches/fortran-experiments
svn://gcc.gnu.org/svn/gcc/trunk"

If you know when the last merge from the mainline to the branch was, you can do:
"svn diff svn://gcc.gnu.org/svn/gcc/branches/fortran-experiments
svn://gcc.gnu.org/svn/gcc/trunk <at> NNNN" where NNNN is that revision
number.

Thanks,
Andrew Pinski

[patch, libgfortran] PR31207 Last record truncated for read after short write, direct access file

:ADDPATCH fortran:

The attached patch fixes this bug by checking the saved_pos value just before 
closing a unit.  If there are bytes indicated, we allocate, which effectively 
moves the file position over the previously written bytes so that they are sent 
to the output when the sclose is called.

That patch works for both implicit and explicit closing of the file.

Regression tested on x86-64-Gnu/Linux.

Test cases attached.

OK for trunk?

Regards,

Jerry
2007-03-31  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>

	PR libgfortran/31207
	* io/unit.c (close_unit_1): If there are bytes previously written from
	ADVANCE="no", move to the end before closing.

Index: unit.c
===================================================================
*** unit.c	(revision 123355)
--- unit.c	(working copy)
*************** close_unit_1 (gfc_unit *u, int locked)

[patch, libgfortran] PR31366 last record truncated for read after short write, direct access file

:ADDPATCH fortran:

The attached patch was approved off list in IRC by Thomas.  I will commit to 4.3 
soon, along with the test case.  The patch is trivial and consistent with 
comments received on c.l.f .

Regression tested on x86-64-Gnu/Linux

Regards,

Jerry

2007-04-01  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>

	PR libgfortran/31366
	* io/transfer.c (read_block_direct): Do not generate error when reading
	past EOF on a short record that is less than the RECL= speified.

Index: transfer.c
===================================================================
*** transfer.c	(revision 123355)
--- transfer.c	(working copy)
*************** read_block_direct (st_parameter_dt *dtp,
*** 411,417 ****
  	  /* Short read, e.g. if we hit EOF.  Apparently, we read
  	   more than was written to the last record.  */
  	  *nbytes = to_read_record;
- 	  generate_error (&dtp->common, ERROR_SHORT_RECORD, NULL);
  	  return;

Re: [patch, libgfortran] PR31207 Last record truncated for read after short write, direct access file

:REVIEWMAIL:

> 2007-03-31  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>
>
> 	PR libgfortran/31207
> 	* io/unit.c (close_unit_1): If there are bytes previously written  
> from
> 	ADVANCE="no", move to the end before closing.

OK.

Re: [patch, libgfortran] PR31366 last record truncated for read after short write, direct access file

> :ADDPATCH fortran:
>
> The attached patch was approved off list in IRC by Thomas.  I will  
> commit to 4.3 soon, along with the test case.  The patch is trivial  
> and consistent with comments received on c.l.f .

If it was approved, then:

:REVIEWMAIL:

Re: [libgfortran,patch] Protect uses of {f,l,}stat with autoconf macros

FX Coudert wrote:
> Attached patch fixes PR libfortran/31335: we have unconditional calls to 
> fstat, lstat and stat in libgfortran/intrinsics/stat.c. I simply propose 
> to follow the pattern laid in the rest of the library, and only define 
> the FSTAT and STAT library functions when fstat() and stat() library 
> calls are available. LSTAT is a bit different, because on systems that 
> don't support it, it is equivalent to stat() and thus can be provided 
> anyway.
> 
> This bug prevented libgfortran from building as a DLL. With this fix, 
> and Steve Ellcey's libtool patch, it will be possible to build 
> libgfortran as a DLL on windows with as little as  a two-lines patch 
> (adding -no-undefined to libgfortran_LT_FLAGS in Makefile.am, and adding 
> LT_INIT([shared static win32-dll dlopen]) to configure.ac
> 
> Built and tested on i386-pc-mingw32 and x86_64-unknown-linux-gnu. OK for 
> mainline?
> 
> Thanks,
> FX
:REVIEWMAIL:

This is OK.

Re: [patch, libgfortran] PR31052 Bad IOSTAT values when readings NAMELISTs past EOF

:ADDPATCH fortran:

I forgot the little detail above.
Jerry DeLisle wrote:
> Jerry DeLisle wrote:
>>
>> Here is a final installment with test case.  I eliminated the 
>> test_endfile function.  Then I added a new function is_special () that 
>> returns true if the special file bit is set in the stream structure.
>>
> The attached patch is identical to my first patch that fixed this bug 
> but failed sixtrack in SPEC with the exception of the last hunk.
> 
> The last hunk adds the test for end file to st_read where it belongs.
> 
> Regression tested on x86-64 and SPEC tested by Seongbae Park.
> 
> Also tested with Harald Anlauf's new test case, modified and attached as 
> well.
> 
> I want to especially thank Seongbae and Harald for their assistance 
> testing and finding the test cases.
> 
> I hope this settles it with this bug. (humbly)
> 
> OK for Trunk?
> 
> Regards,
> 
> Jerry

Re: [patch, libgfortran] PR31052 Bad IOSTAT values when readings NAMELISTs past EOF

> 2007-03-30  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>
>
>     PR libgfortran/31052
>     * io/file_position (st_rewind): Remove use of
>     test_endfile. Don't seek if already at 0 position.  Use new  
> is_special
>     function to set endfile state.
>     * io/open.c (test_endfile): Delete this function.
>     (edit_modes): Delete call to test_endfile.
>     (new_unit): Likewise.
>     * io/io.h: Delete prototype for test_endfile.  Add prototype
>     for is_special.
>     * io/transfer.c (next_record_r): Remove use of test_endfile.
>     (st_read):  Add test for end file condition and adjust status.

OK for mainline.

Re: [gfortran,patch] Fix simplification and code generation for REPEAT

:REVIEWMAIL:

FX,
>
> Bootstrapped and regtested on i686-linux, OK for mainline ?
OK - just a couple of tiny niggles:

(i) I would have preferred that you use the scalarizer in 
gfc_conv_intrinsic_repeat, as I suggested off-list.  However, what you 
have submitted is perfectly correct - maybe we should add a function for 
generating simple loops, where the counter  is known and the loop body 
is ready to go?

(ii)  simplify.c:2794 -
  /* If NCOPIES isn't a contant, there's nothing we can do.  */

Thanks!

Paul