Re: [fortran-dev] constructor work, part I and II, updated

On Wednesday 30 December 2009 07:34:36 Daniel Franke wrote:
> As the initial patch and the update did not get a formal review yet, I
> continued to work on it. Here's the whole of (a), (b) and (c) in one big
> changeset. It bootstraps and regtests fine up to one regression where I'm
>  not sure it's a real regression or not a latent bug uncovered by the
>  changes (char_component_initializer_1.f90). Either way, I didn't manage
>  yet to get rid of it yet. There are also issues with this testcase in
>  trunk as well (see PR42526).

Please find an updated version of the patch attached.

There are four changes:
 1. Update decl.c (add_init_expr_to_sym) to use init as first value, as
    Tobias S. mentioned this may lead to problems otherwise. This now reads:

+               gfc_constructor_append_expr (&array->value.constructor,
+                                            n == 0
+                                               ? init
+                                               : gfc_copy_expr (init),
+                                            &init->where);
+

 2. removed a piece of junk code that was left over from reg-hunting
 3. fixed the last regresssion on char_component_initializer_1.f90
    The relevant section for both changes in decl.c (build_struct) now reads:

-             for (; ctor; ctor = ctor->next)
+             for ( ; ctor; ctor = gfc_constructor_next (ctor))
+               if (ctor->expr->expr_type == EXPR_CONSTANT)
                {

[ANNOUNCEMENT] New fortran-exp branch created

I have created a new branch, fortran-exp, to allow Daniel Franke to commit his 
substantial constructor refactoring patch.  The patch passes all regression 
testing and polyhedron tests.  (The fortran-experimental branch was too messed 
up to use)

Daniel has already found a few additional improvements and I also have at least 
one add-on patch, so this is the cleanest way to get this all captured and not 
create any issues with OOP development on fortran-dev branch.

I have approved Daniel to commit too the new branch.

Best regards,

Jerry

Re: [ANNOUNCEMENT] New fortran-exp branch created

Jerry DeLisle wrote:
> I have created a new branch, fortran-exp, to allow Daniel Franke to 
> commit his substantial constructor refactoring patch.  The patch passes 
> all regression testing and polyhedron tests.  (The fortran-experimental 
> branch was too messed up to use)
> 
> Daniel has already found a few additional improvements and I also have 
> at least one add-on patch, so this is the cleanest way to get this all 
> captured and not create any issues with OOP development on fortran-dev 
> branch.
> 
> I have approved Daniel to commit too the new branch.
> 
> Best regards,
> 
> Jerry
> 
oops, I named it gfortran.exp and not fortran.exp

Jerry

Re: [ANNOUNCEMENT] New fortran-exp branch created

Dave Korn wrote:
> Jerry DeLisle wrote:
>> Jerry DeLisle wrote:
>>> I have created a new branch, fortran-exp, to allow Daniel Franke to
> 
>> oops, I named it gfortran.exp and not fortran.exp
>>
>> Jerry
> 
>   EMORSE! 
> 
>     cheers,
>       DaveK
> 
I have svn moveed it to fortran-exp. I egret my eeror.  :)

Jerry

Re: [ANNOUNCEMENT] New fortran-exp branch created

Gerald Pfeifer wrote:
> On Sat, 2 Jan 2010, Jerry DeLisle wrote:
>> I have created a new branch, fortran-exp, to allow Daniel Franke to 
>> commit his substantial constructor refactoring patch.  The patch passes 
>> all regression testing and polyhedron tests.  (The fortran-experimental 
>> branch was too messed up to use)
> 
> Would you mind documenting this at http://gcc.gnu.org/svn.html?  See
> the existing list of branches there for examples.
> 
> Gerald
> 
Will do.

Jerry

Re: [PATCH] Update gfortran.info intrinsic procedure descriptions

On Sun, Dec 27, 2009 at 23:06, Steve Kargl
<sgk <at> troutmask.apl.washington.edu> wrote:
> The patch is somewhat obvious.  I've added the specific
> name of procedures to the list within a description where
> the specific name matches the generic name.  It would
> probably be best to group all specific name information in
> two tables (one for specific names that can be actual arguments
> (AA) and one for specific names that cannot be used as AA).
>
> I also updated ALLOCATED to note that scalar allocatables are
> now included in gfortran.
>
> Checked with "gmake pdf".  OK for trunk?

Ok.

--

-- 
Janne Blomqvist

Re: [PATCH] Update gfortran.info intrinsic procedure descriptions

On Sat, Jan 02, 2010 at 07:00:02PM +0200, Janne Blomqvist wrote:
> On Sun, Dec 27, 2009 at 23:06, Steve Kargl
> <sgk <at> troutmask.apl.washington.edu> wrote:
> > The patch is somewhat obvious. ?I've added the specific
> > name of procedures to the list within a description where
> > the specific name matches the generic name. ?It would
> > probably be best to group all specific name information in
> > two tables (one for specific names that can be actual arguments
> > (AA) and one for specific names that cannot be used as AA).
> >
> > I also updated ALLOCATED to note that scalar allocatables are
> > now included in gfortran.
> >
> > Checked with "gmake pdf". ?OK for trunk?
> 
> Ok.
> 

Thanks.  Unfortunately, I need to rework one of the multitable
entries because it has more than 3 columns.  'make pdf' works
fine, but 'make info' dies a horrible death.

--

-- 
Steve

[Patch, libfortran] PR 42420 Large file capable stat for MingW

Hi,

the attached patch should fix PR 42420.

As usual, I don't have a windows machine to test on, but an earlier
similar patch (see bugzilla) was apparently tested successfully on
MingW. Regtested on x86_64-unknown-linux-gnu, Ok for trunk?

-- 
Janne Blomqvist

diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 07aa4d9..bd2b659 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -42,13 +42,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see

 /* For mingw, we don't identify files by their inode number, but by a
    64-bit identifier created from a BY_HANDLE_FILE_INFORMATION. */
-#if defined(__MINGW32__) && !HAVE_WORKING_STAT
+#ifdef __MINGW32__

 #define WIN32_LEAN_AND_MEAN
 #include <windows.h>

 #define lseek _lseeki64
+#define fstat _fstati64
+#define stat _stati64

[fortran-exp, patch] get_expr code cleanup, part I

Hi all.

There are a batch of function that build expressions and pre-initialize them. 
In particular:

  arith.c (gfc_constant_result (bt type, int kind, locus*))
  constructor.c (gfc_build_array_expr (gfc_typespec*, locus*))
  constructor.c (gfc_build_structure_constructor_expr (gfc_typespec*, locus*))
  expr.c (gfc_int_expr (int))
  expr.c (gfc_logical_expr (int, locus*))

As you can see, not only are they scattered between the files, their naming 
and argument lists are somewhat inconsistent, too. Attached patch moves all 
functions to the beginning of expr.c and names them gfc_get_≤something>_expr. 
Further, all these functions now take 'kind' and 'where' parameters. All other 
changes are fix-ups of the respective function calls.

As a second step, I'll go comb through the sources and replace manual building 
of such expressions by their corresponding function calls, adding 
gfc_get_null_expr and others as required.

Regression tested on i686-pc-linux-gnu. Ok for fortran-exp?

Cheers

	Daniel

2010-01-03  Daniel Franke  <franke.daniel <at> gmail.com>

[patch, wwwdocs] Fortran web page update

The attached file is a proposed update to wwwdocs/fortran/index.html

I tried to clean it up, get all the names right, and make it read clearly and 
succinctly.

If I hear no comments, I will commit in the next day or so.  While folks are 
looking over this, there is a contributors page I will take a shot at as well.

Regards,

Jerry

? index.diff
Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/fortran/index.html,v
retrieving revision 1.27
diff -p -r1.27 index.html
*** index.html	18 Oct 2006 21:42:46 -0000	1.27
--- index.html	3 Jan 2010 16:06:44 -0000
***************
*** 1,139 ****
! <html>
! <head>
! <title>GNU Fortran -- Free number crunching FORALL!</title>
! </head>
! 
! <body>
!