headers
Steve Kargl | 1 Jan 2006 03:10
Picon

gfortran 2005 year end stats

The following stats do not capture the numerous hours of 
code review, emails, bug chasing and reduction, and IRC
discussions that concern gfortran.  Although the stats
suggest that a majority of the commits and patches are due
to the effort of a small handful of individuals, in fact over
50 different individuals are credited with a patch.  In 2005,
gfortran has made tremendous strides in becoming a full
feature Fortran 95 compiler.  If the development effort can
be sustained, 2006 promises to be a significant year for 
gfortran.

Gfortran 2005 Year End Stats

374 commits in gcc/fortran
126 commits in libgfortran
350 PR's closed

(The above may not reflect all PR's related to gfortran.  For
example, middle and back end bugs reported against gfortran
may not be properly counted here.)

The condense list of commits and the PRs in gcc/fortran are:

  55  Tobias Schlueter
        16907, 18525, 18990, 19182, 19194, 19195, 19479, 19543,
        19673, 20059, 20178, 20323, 20361, 20467, 21260, 21912,
        22010, 23420, 23661, 23765, 24008, 24404, 24643
  50  Steven G. Kargl
        17792, 19168, 19589, 19754, 19936, 20058, 20786, 21257,
        21375, 23065, 23516, 24005, 24636, 24917, 25055, 25078,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Jan 2006 18:19
Picon

FYI: fortran and libgfortran ChangeLog split into years.

FYI

As discussed on IRC yesterday, I've split the gcc/fortran and
libgfortran ChangeLog into years, ie., ChangeLog-2002, etc.
This is somthing like a 37000 line diff.  I see no point in
submitting the diff to the mail lists.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Steve Kargl | 2 Jan 2006 02:04
Picon

Re: [patch, fortran] PR25029 unbounded assumed size array references

On Sat, Dec 31, 2005 at 08:08:14AM +0100, Paul Thomas wrote:
> 
> It responds in the same way as ifort and DF5.0, so I think that all is 
> well. However, that is what I thought before, so I would be grateful if 
> Toon and Steve would put the patch through through its paces.
> 

I've bootstrapped and regression tested this patch on i386-*-freebsd.
My private testsuite, which includes LAPACK that revealed the problem
with the original patch, also passed.

I think the patch is ready for committing, but give Tobi a chance
to respond.  Oh, please check your white space.  Some of the 
patch seemed misaligned in my mailer.

--

-- 
Steve
Permalink | Reply | 5 comments |
headers
Erik Edelmann | 2 Jan 2006 03:07
Picon
Picon
Favicon

[gfortran, patch] PR 23675: Character function of module-variable length

:ADDPATCH fortran:

Here's a patch for PR 23675.  The problem is in short this:  When
translating the call to the function IntToChar2 in the code

--------------------
module cutils
  implicit none
  private

  integer :: maxStringLength = 25
  public :: IntToChar2

contains

  function IntToChar2(integerValue)
    integer, intent(in) :: integerValue
    character(len=maxStringLength)  :: IntToChar2

    write(IntToChar2, *) integerValue
  end function IntToChar2

end module cutils

program test

    use cutils

    implicit none
    character(25) :: str
(Continue reading)

Permalink | Reply | 21 comments |
headers
Richard Henderson | 2 Jan 2006 05:39

Re: [PATCH] Fix libgfortran compilation on Tru64

On Fri, Dec 30, 2005 at 09:55:47PM -0800, Steve Kargl wrote:
> IIRC, rth was/is a Tru64 maintainer.

Nope.  I've never had access to Tru64, only alpha-linux.

r~
Permalink | Reply | 0 comments |
headers
Paul Thomas | 2 Jan 2006 08:44
Picon

Re: [patch, fortran] PR25029 unbounded assumed size array references

Steve

>I've bootstrapped and regression tested this patch on i386-*-freebsd.
>My private testsuite, which includes LAPACK that revealed the problem
>with the original patch, also passed.
>  
>
Many thanks.

>I think the patch is ready for committing, but give Tobi a chance
>to respond.  Oh, please check your white space.  Some of the 
>patch seemed misaligned in my mailer.
>  
>
I'll have a look, when I reapply the patch.  It looks OK to me but maybe 
I am missing something in the offset first tabs in the diff.  The 
ChangeLog is misaligned because it was copied and pasted into the message.

Paul
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 2 Jan 2006 09:06
Picon

[patch,fortran] PR24268 gfortran rejects valid format

:ADDPATCH fortran:

This patch revises the earlier fix we came up with to take into account possible
spaces between letters of format specifiers and handles the general situation of
spaces anywhere within a format string.

This is accomplished by adding a new function next_char_not_space to use in
place of next char in the format_lex code.  This function just eats spaces until
it finds something that isn't.

NIST tested, LAPACK tested, regression tested.  I have attached a new test case
that adds an additional typical check.  Agrees with g77 as well.

OK for 4.2 and 4.1 after a day or so?

Regards Jerry

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

	PR fortran/24268
	* io.c (next_char_not_space): New function that returns the next
	character that is not white space.
	(format_lex): Use the new function to skip whitespace within
	a format string.
Attachment (io.diff): text/x-patch, 3414 bytes
Attachment (fmt_white.f): text/x-fortran, 570 bytes
Permalink | Reply | 5 comments |
headers
Jakub Jelinek | 2 Jan 2006 09:52
Picon
Favicon

Re: [gfortran, patch] PR 23675: Character function of module-variable length

On Mon, Jan 02, 2006 at 04:07:23AM +0200, Erik Edelmann wrote:
> 2006-01-02  Erik Edelmann  <eedelman <at> gcc.gnu.org>
> 
>         fortran/PR 23675

Please fix the format of the PR reference, should be
	PR fortran/23675

> 2006-01-02  Erik Edelmann  <eedelman <at> gcc.gnu.org>
> 
>         fortran/PR 23675

Here as well.

	Jakub
Permalink | Reply | 2 comments |
headers
Tobias Schlüter | 2 Jan 2006 11:30
Picon
Favicon

Re: [patch, fortran] PR25029 unbounded assumed size array references

Steve Kargl wrote:
> On Sat, Dec 31, 2005 at 08:08:14AM +0100, Paul Thomas wrote:
> 
>>It responds in the same way as ifort and DF5.0, so I think that all is 
>>well. However, that is what I thought before, so I would be grateful if 
>>Toon and Steve would put the patch through through its paces.
>>
> 
> 
> I've bootstrapped and regression tested this patch on i386-*-freebsd.
> My private testsuite, which includes LAPACK that revealed the problem
> with the original patch, also passed.
> 
> I think the patch is ready for committing, but give Tobi a chance
> to respond.  Oh, please check your white space.  Some of the 
> patch seemed misaligned in my mailer.

I won't have time before wednesday, I haven't looked at the patch in depth
yet, but one case I'm worried about is calling LBOUND(a) where a is an assumed
size array inside an argument list.

- Tobi
Permalink | Reply | 2 comments |
headers
Tobias Schlüter | 2 Jan 2006 11:57
Picon
Favicon

Re: [gfortran, patch] PR 23675: Character function of module-variable length

Erik Edelmann wrote:
> Here's a patch for PR 23675.  The problem is in short this:  When
> translating the call to the function IntToChar2 in the code
...
> we will call gfc_get_symbol_decl() (in trans-decl.c) for the
> symbol of maxStringLength.  Since maxStringLength hasn't been
> (explicitely) referenced in 'program test', it doesn't have
> sym->attr.referenced set, which is why we crash at the line 
> 
>   gcc_assert (sym->attr.referenced);
> 
> in gfc_get_symbol_decl().  My solution is to, from trans-expr.c
> (gfc_conv_function_call), traverse the expression tree of the
> length of the function result, and mark all variables we find as
> referenced.

Although I see there are a few places in trans*.c where sym->attr.referenced
is set, I still think you should do this earlier, specifically the recently
added function resolve_charlen or one of the constant folders seems more
appropriate.

- Tobi

:REVIEWMAIL:

> 2006-01-02  Erik Edelmann  <eedelman <at> gcc.gnu.org>
> 
>         fortran/PR 23675
>         * expr.c (gfc_expr_set_symbols_referenced): New function.
>         * gfortran.h: Add a function prototype for it.
(Continue reading)

Permalink | Reply | 15 comments |

Gmane