headers
Paul Thomas | 1 Jan 10:39
Picon

Re: Are type-bound procedures and classes supported yet by gfortran?

Richard,
> Hi all,
>
> Thank you for your work on gfortran!  I was wondering if type-bound
> procedures and classes supported yet?
>   
No - just a few compilers do support them right now;  xlf and nag5.1 are 
the ones that I know about.
> This is a subset of the module I'm writting that still shows the
> errors I've included below.  I've been trying to find my errors for
> some time.  Is it simply something that has just gone into my
> programming 'blind spot' or are the features not yet supported?  If
> they aren't supported are there suggestions as to what I should use to
> support them?
>
>   
I'm afraid that you will just have to remove the contains section in the 
derived types and call the functions F95 style.

Paul
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Jan 13:21
Picon

Re: Draft 2007 gfortran annual report

Steve Kargl wrote:
>>  4) Janus Weil was gfortran's first Google SoC student.  He worked
>>     on the Fortran 2003 PROCEDURE feature.
>>     
>
> Has this been completely implemented?  
>   
To my knowledge, everything is implemented - except procedure pointers
(which seems to be one of the most missed Fortran 2003 feature in
gfortran) and PASS etc. attributes, used for type-bound procedures
(which are not implemented).

Tobias
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 2 Jan 00:16
Picon

FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test

This fails for me on i686-pc-linux-gnu.  Anyone else seeing this?

I am investigating and will post a PR.

Jerry
Permalink | Reply | 2 comments |
headers
Thomas Koenig | 2 Jan 00:35
Picon
Favicon

Re: FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test

On Tue, 2008-01-01 at 15:16 -0800, Jerry DeLisle wrote:
> This fails for me on i686-pc-linux-gnu.  Anyone else seeing this?
> 
> I am investigating and will post a PR.

Hi Jerry,

this is PR 34168.

Happy new year, everybody :-)

	Thomas
Permalink | Reply | 1 comment |
headers
Jerry DeLisle | 2 Jan 02:47
Picon

Re: FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test

Thomas Koenig wrote:
> On Tue, 2008-01-01 at 15:16 -0800, Jerry DeLisle wrote:
>> This fails for me on i686-pc-linux-gnu.  Anyone else seeing this?
>>
>> I am investigating and will post a PR.
> 
> Hi Jerry,
> 
> this is PR 34168.
> 
> Happy new year, everybody :-)
> 
> 	Thomas
> 
> 
Thanks Thomas,

This showed up recently on my i686 machine.  I just bumped it to Fedora 8 which 
uses glibc-2.7.

Jerry
Permalink | Reply | 0 comments |
headers
Paul Thomas | 2 Jan 08:32
Picon

Gfortran annual report for 2008

Gfortran maintainers have kept up the momentum of 2006 and the number
of known F95 bugs has gone down sharply, the diagnostic capability
has increased and new F2003/8 features added.

Hopefully, the contributors can continue to move forward with bug
fixes, conformance to Fortran 95 standard, and the implementation of
Fortran 2003/8 features.  However, this needs new blood in the ranks,
particularly since Steve Kargl and Bud Davis have hung up their
maintainer hats and some of the other regulars are struggling with
competition between gfortran and daytime jobs or moves between
countries.

If you have any interest in helping out, please do not hestitate to
contact one of us or to mail the gfortran list, for help on how to
get started.

An important source of help to us is bug reporting.  Best of all is for
bugs to be posted in Bugzilla with well reduced testcases.  There is a
group of regulars out there whose efforts are really appreciated. It is
noticable that threads on comp.lang.fortran are becoming increasingly
important; particularly to resolve thorny issues of Standard
interpretation but also for picking up bugs. A favourite was "Most
elegant syntax for inverting a permutation?" which led to corrections
of problems with assignment and FORALL.

As an aside, it should be noted that the main part of this report
was written by Steve Kargl.  Many thanks, Steve!  Thank you for all
your contributions over the years and, should you change your mind,
we all look forward to you rejoining us.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gerald Pfeifer | 2 Jan 09:24

[wwwdocs] PATCH for Re: Gfortran annual report for 2008

On Wed, 2 Jan 2008, Paul Thomas wrote:
> Gfortran maintainers have kept up the momentum of 2006 and the number
> of known F95 bugs has gone down sharply, the diagnostic capability
> has increased and new F2003/8 features added.

Nice report, thanks!  Like last year I add a link to this message to
the News section on our main page. :)

Gerald

Add "Gfortran annual report for 2008" to News section.  Rotate news.

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.636
diff -u -3 -p -r1.636 index.html
--- index.html	9 Dec 2007 11:01:48 -0000	1.636
+++ index.html	2 Jan 2008 08:20:39 -0000
@@ -45,6 +45,10 @@ mission statement</a>.</p>

 <dl class="news">

+<dt>January 2, 2008</dt>
+<dd><a href="http://gcc.gnu.org/ml/gcc/2008-01/msg00009.html">Gfortran
+annual report for 2008</a></dd>
+
 <dt>October 7, 2007</dt>
 <dd><a href="gcc-4.2/">GCC 4.2.2</a> has been released.</dd>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Koenig | 2 Jan 11:54
Picon
Favicon

[patch, libfortran] PR 34565, internal write with negative strides

Hello world,

here's a patch for internal I/O with negative array strides.  This was
a bit tricky, due to the separation of stream I/O and the number of
places that needed to be touched.

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

OK for trunk?

	Thomas

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

	PR libfortran/34565
	* io/io.h:  Adjust protoypes for open_internal(),
	next_array_record() and init_loop_spec().
	* io/list_read.c (next_char):  Use argument "finished"
	of next_array_record to check for end on internal file.
	* io/unit.c:  Calculate the offset for an array
	internal file and supply this informatin to open_internal().
	* io/unix.c (open_internal):  Set the offset for the internal
	file on open.
	* io/transfer.c (init_loop_spec):  Calculate the starting
	record in case of negative strides.  Return size of 0 for
	an empty array.
	(next_array_record):  Use an extra flag to signal that the
	array is finished.
	(next_record_r):  Use the new flag to next_array_record().
	(next_record_w):  Likewise.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Guenther | 2 Jan 15:46
Picon
Favicon

[PATCH][RFC] Add PAREN_EXPR, make flag_associative_math the default for Fortran


This adds a middle-end PAREN_EXPR tree code that acts as re-association
barrier for floating point expressions.  This allows to model the Fortran
semantics that allow re-association for expressions that are not
explicitly wrapped inside parentheses.

This simple patch (not tested yet) for example preserves a + (b - a)
if you build with -ffast-math.

function testarray (a, b)
   implicit none
   real*8 :: a, b, testarray

   testarray = a + (b - a)
end

eventually this allows expansion of rounding functions on the tree
level (those rely on us preserving stuff like (x + 1e-52) - 1e52 and
not constant fold it).

The way the patch 'works' is that nothing handles (looks through)
PAREN_EXPR at the moment, so it is a conservative implementation.  On
the RTL level it just relies on the fact that we do not re-associate
floating point expressions there (we rely on that fact now anyway).

Any thoughts?  (Yes, I thought on using a flag on operands or variants
of the associative tree operators, but these either don't work do not
model the semantics close enough)

Thanks,
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tobias Schlüter | 2 Jan 18:53
Picon
Favicon

Re: [PATCH][RFC] Add PAREN_EXPR, make flag_associative_math the default for Fortran

Richard Guenther wrote:
> This adds a middle-end PAREN_EXPR tree code that acts as re-association
> barrier for floating point expressions.  This allows to model the Fortran
> semantics that allow re-association for expressions that are not
> explicitly wrapped inside parentheses.
> 
> This simple patch (not tested yet) for example preserves a + (b - a)
> if you build with -ffast-math.
> 
> function testarray (a, b)
>    implicit none
>    real*8 :: a, b, testarray
> 
>    testarray = a + (b - a)
> end
> 
> eventually this allows expansion of rounding functions on the tree
> level (those rely on us preserving stuff like (x + 1e-52) - 1e52 and
> not constant fold it).
> 
> The way the patch 'works' is that nothing handles (looks through)
> PAREN_EXPR at the moment, so it is a conservative implementation.  On
> the RTL level it just relies on the fact that we do not re-associate
> floating point expressions there (we rely on that fact now anyway).
> 
> Any thoughts?  (Yes, I thought on using a flag on operands or variants
> of the associative tree operators, but these either don't work do not
> model the semantics close enough)

This matches the original intent when INTRINSIC_PARENTHESES were
(Continue reading)

Permalink | Reply | 7 comments |

Gmane