[patch, libgfortran] PR36676 Namelist Comments Problems

I will commit the following patch as obvious and simple.

Regression tested on x86-64.

On my patch for PR36657 I should have used eat_separator instead of eat_line.

Regards,

Jerry

2008-06-30  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>

	PR fortran/36676
	* io/list_read.c (find_nml_name): Use eat_separator instead of eat_line.

Index: list_read.c
===================================================================
--- list_read.c (revision 137236)
+++ list_read.c (working copy)
@@ -2922,8 +2922,8 @@ find_nml_name:
        goto find_nml_name;
      }

-  if (c == '!')
-    eat_line (dtp);
+  unget_char (dtp, c);
+  eat_separator (dtp);

    /* Ready to read namelist objects.  If there is an error in input
       from stdin, output the error message and continue.  */

Re: [PATCH, Fortran] Derived type finalization: Already somewhat useable...

Daniel,

I've made a bit of progress on your patch:

(i) The "write_symbol(): bad module symbol" error is fixed by adding
the last line in:

static gfc_expr* build_intrinsic_call (const char* name, ...)
{
  gfc_expr* result;
  gfc_actual_arglist** args_out;
  va_list args_in;

  /* Build the basic function expression.  */
  result = gfc_get_expr ();
  result->expr_type = EXPR_FUNCTION;
  result->ts.type = BT_UNKNOWN;
  gfc_get_sym_tree (name, NULL, &result->symtree);
  gfc_commit_symbols (); /* XXX: Need this here?  */
  gfc_set_sym_referenced (result->symtree->n.sym);
  result->symtree->n.sym->attr.flavor = FL_PROCEDURE;

(ii) finalize_exec_5.f03 winds up with cnt_single being 3 short for two reasons:

      - neither function result is finalized
      - the structure constructor is not finalized

I take it that you are sure that these finalizations should happen?

Should 'var' and 'vect' not be finalized at the end of the main program?

[patch, fortran] Fix PR 36670, bounds check on product and sum

Hello world,

this rather self-explanatory patch fixes the missing bounds check
on the product and sum intrinsics.

Regression-tested on i686-pc-linux-gnu.

OK for trunk?

	Thomas

2008-07-01  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/36670
	* iresolve.c (gfc_resolve_product):  Set shape of return
	value from array.
	(gfc_resolve_sum):  Likewise.

2008-07-01  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/36670
	* gfortran.dg/product_sum_bounds_1.f90:  New test case.

Index: /home/ig25/gcc/trunk/gcc/fortran/iresolve.c
===================================================================
--- /home/ig25/gcc/trunk/gcc/fortran/iresolve.c	(revision 137255)
+++ /home/ig25/gcc/trunk/gcc/fortran/iresolve.c	(working copy)

Re: Read the middle-end array expression paper by Richard Guenther !

Paul Richard Thomas wrote:

> I had already spotted the paper and Richard and I have exchanged
> messages about it.  I was concerned not to do any work on
> trans-array.c before I knew what was coming

Good !

> Richard would like some gfortran help, which I am going to find hard
> to provide him with for some months due to pressure of work. This is
> going to be quite a big job, so if any body else can help.... please
> feel free!

Note that we can contemplate on *any* scalarization loop in isolation - 
there is no need to convert them all at once (as Richard pointed out to 
me at the Summit).

We can leasurily convert the Front End until we are entirely satisfied 
that the whole clean-up has been done.

Kind regards,

--

-- 
Toon Moene - e-mail: toon <at> moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg00009.html

[patch, libfortran] Fix PR 36341, run-time part

Hello world,

this patch implements the run-time part of the array bounds checking for
matmul.

The number of test cases is a bit large because I wanted to test all
code paths, and you can only check for a single run-time error with
each test 

Regression-tested on i686-pc-linux-gnu.

OK for trunk?

	Thomas

2008-07-02  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/36341
	PR fortran/34670
	* m4/matmul.m4:  Add bounds checking.
	* m4/matmull.m4:  Likewise.
	* generated/matmul_c10.c: Regenerated.
	* generated/matmul_c16.c: Regenerated.
	* generated/matmul_c4.c: Regenerated.
	* generated/matmul_c8.c: Regenerated.
	* generated/matmul_i1.c: Regenerated.
	* generated/matmul_i16.c: Regenerated.
	* generated/matmul_i2.c: Regenerated.
	* generated/matmul_i4.c: Regenerated.
	* generated/matmul_i8.c: Regenerated.

[patch, committed] Fix PR 36681 and 36590

Hello world,

the following was committed after Jerry's approval in the PR.

Thanks!

	Thomas

2008-07-02  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/36590
	PR fortran/36681
	* iresolve.c (resolve_mask_arg):  Don't convert mask to
	kind=1 logical if it is of that type already.

2008-07-02  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/36590
	PR fortran/36681
	* gfortran.dg/count_mask_1.f90:  New test.

Index: /home/ig25/gcc/trunk/gcc/fortran/iresolve.c
===================================================================
--- /home/ig25/gcc/trunk/gcc/fortran/iresolve.c	(revision 137255)
+++ /home/ig25/gcc/trunk/gcc/fortran/iresolve.c	(working copy)
@@ -106,7 +106,7 @@ resolve_mask_arg (gfc_expr *mask)
       /* In the library, we access the mask with a GFC_LOGICAL_1
 	 argument.  No need to waste memory if we are about to create

Re: [PATCH, Fortran] Derived type finalization: Already somewhat useable...

Hi,

I sent this from gmail today's morning but it bounced.  Sorry if this 
gets duplicated...

Daniel Kraft wrote:
> 2008/7/1 Paul Richard Thomas <paul.richard.thomas <at> gmail.com 
> <mailto:paul.richard.thomas <at> gmail.com>>:
> 
>     Daniel,
> 
>     I've made a bit of progress on your patch:
> 
>     (i) The "write_symbol(): bad module symbol" error is fixed by adding
>     the last line in:
> 
>     static gfc_expr* build_intrinsic_call (const char* name, ...)
>     {
>      gfc_expr* result;
>      gfc_actual_arglist** args_out;
>      va_list args_in;
> 
>      /* Build the basic function expression.  */
>      result = gfc_get_expr ();
>      result->expr_type = EXPR_FUNCTION;
>      result->ts.type = BT_UNKNOWN;
>      gfc_get_sym_tree (name, NULL, &result->symtree);
>      gfc_commit_symbols (); /* XXX: Need this here?  */
>      gfc_set_sym_referenced (result->symtree->n.sym);
>      result->symtree->n.sym->attr.flavor = FL_PROCEDURE;

Re: Procedure Pointers: a first patch

Hi Janus, hi all,

Janus Weil wrote:
> thanks a lot for taking care of this. I'm sorry have not yet managed
> to look into this myself, but my diploma thesis is keeping me insanely
> busy at the moment.
>   
Now in revised order: Sorry for not replying earlier. A report and my 
doctoral defense kept me busy last week.

> So, now that procptrs as actual arguments are working, do you think we
> can dare to commit the patch?
Yes, see minor comments below.

> Some things which are still
> missing are: procptr components, functions returning procptrs,
> procptrs in COMMON, some checking etc.
Shall I open PRs for the missing items? (COMMON is PR 36592.)
On which of the items you want to work first?
Procedure pointers in components is probably the more interesting item 
for most users, but fixing some loose ends is also not a bad idea.

Your patch is OK for the trunk - after fixing the minor nits below.

+	    if (attr->proc_pointer) break;
should be:
+	    if (attr->proc_pointer)
+             break;

-  if (lvalue->symtree->n.sym->ts.type == BT_UNKNOWN)

Re: Procedure Pointers: a first patch

> Now in revised order: Sorry for not replying earlier. A report and my
> doctoral defense kept me busy last week.

Not a problem. And congratulations to your newly acquired scientific degree!

>> Some things which are still
>> missing are: procptr components, functions returning procptrs,
>> procptrs in COMMON, some checking etc.
>
> Shall I open PRs for the missing items? (COMMON is PR 36592.)
> On which of the items you want to work first?
> Procedure pointers in components is probably the more interesting item for
> most users, but fixing some loose ends is also not a bad idea.

If you care to do so, you're welcome to open some PRs. Otherwise I can
also do it myself. I haven't really decided yet where to continue.
Procedure pointer components are surely interesting, but the other
stuff needs to be fixed too.

> Your patch is OK for the trunk - after fixing the minor nits below.

Thanks. Committed with your corrections as rev 137386.

Cheers,
Janus

User define derived type I/O

Hi,

Now that derived type finalization and procedure pointers are getting close if 
not done, we need to start thinking about user defined derived type I/O.

I took some time today to read up a bit on this.  I think there is a lot of 
similarity to finalization in the sense that we associate a user defined 
subroutine with a particular derived type.  The "standard" defines four methods 
of I/O:

write(formatted)
read(formatted)
write(unformatted)
read(unformatted)

Each of these four items are essentially procedure pointers pointing to the user 
defined subroutines with a standard defined interface. If I am not mistaken, I 
think this can fall right into place.

I plan to start working on this after I get UTF-8 encoding done.  If anyone else 
is interested working on derived type I/O, please let me know.

The first step will be parsing the declarations and establishing the function 
pointers in the front end.  We also need to handle the DT format descriptor in 
the frontend and in the runtime library.  There are several places in the 
library where we add in the "hooks" for BT_DERIVED.

I wonder, are we going to have a BT_CLASS eventually?

Any other thoughts on this?