This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: timeline?
- From: "Thomas Breuel" <tmbdev at gmail dot com>
- To: "Tobias Burnus" <burnus at net-b dot de>
- Cc: fortran at gcc dot gnu dot org
- Date: Wed, 5 Nov 2008 20:01:30 +0100
- Subject: Re: timeline?
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=K7ihqnXLexflmFXohQ5vF17wviAJVThVpPFNtCE6LKc=; b=WnpdP7En63E1W9PdnCYQi4vEKIAmAVogZcAEjqX7btXjUgdLYgByzD38dWmWbl0v12 JPF+/YwOF3YxBmf/XvuPh61M1pDjtw0dmEIXAuoGqH6r2oVu62T6XXqXNlRU4FO/0BZ9 b2uPe4wB5qzBm3lh1gVVr5zTr5CJe0vWEWCiI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HcsS0//2nFOOUQP9ee0Nmk4o4cqnm1oFcGp+Z+JeKsj67ZbOFsbzazRK42bEuZ9hAj dDutI3Klr1zyK2PazJ85Nyk7CnuGB+JOGUQvNrQDfklZ0OiBDNyUABx+EATT8jw6qRcw rJzdM2oAaGYq05gSEScI95KY0hju1oaIB9J8k=
- References: <7e51d15d0811050926r75d2414fsc65729a62fa5b08b@mail.gmail.com> <7e51d15d0811050933h6c6a8ca0jcc9b3343ec5b63f2@mail.gmail.com> <4911E06F.3090203@net-b.de>
Thanks for the quick response.
> For the Fortran 2003 status, see: http://gcc.gnu.org/wiki/Fortran2003Status
Ah, I hadn't seen that; that's very useful.
>From my point of view (teaching, research, open source projects), the
most important features are (in decreasing order of importance):
- get the debugger to work better
- full, working allocate support (e.g., on assignment)
- ASSOCIATE
After that, the more OOP support there is, the better, because it
means that we can solve more problems in a single-language
environment.
Co-arrays are low priority; OpenMP fits our needs well.
There are a couple of things that are quality-of-implementation issues:
- provide a "-fsafe" mode that implements a combination of runtime and
compile time checks that catch as many array bounds violations,
uninitialized variables, uninitialized pointers, overflows, null
pointers, etc. as reasonably possible
- use realloc or a built-in equivalent behind the scenes for
allocations whenever possible; a = [a,1] should be constant time,
independent of the size of a (it should also not crash :-)
- provide better support for interfaces to C, C++ and Python; for
example, provide C macros for accessing and manipulating GFortran
arrays, allocatable arrays, and pointers
Tom