GCC/gfortran 4.7.0 release approaching - request for testing

[Tobias Burnus]

Dear all,

Executive summary: GCC 4.7 will be soon released. It has better
polymorphism/object-oriented programming support, OpenMP 3.1,
generates faster code - and on the C++ side there are new
C++ 2011 features. Please test to ensure it won't regress
on your code.


The GNU Compiler Collection (GCC) and thus also gfortran
is in the stabilization phase which will lead to the
release of 4.7.0 in a couple of weeks.* (Stage 4, regression
and documentation fixes only.) Thus, the current development
version should be rather stable and regressions are likely to
be fixed quickly. Hence, it makes sense to check whether your
favourite software still compiles and runs - but you can also
play with the new features or run some benchmarks. Especially
welcome is feedback to the polymorphism support, which has
been extended and many bugs have been fixed. However, it still
have several known issues and lacks finalization subroutines
and unlimited polymorphism.

(* The release will be done when "it is ready". The release
date is currently planed for around mid-March. The exact date
depends on the number and severity of the regressions. But
the release manager also want to give the users some time to
actually find regressions before the release.)


Highlights of GCC 4.7.0 - general part:

* Improved performance, especially with -fstack-arrays. (This
Fortran flag is enabled by -Ofast, but can always be used
- if the system has a large enough stack.)
A good benchmark setting is: -Ofast -march=native -funroll-loops
A more conservative setting is
-O2 -march=native -funroll-loops -fstack-arrays
You may need to replace -march= by something different if you
use several different CPUs. You might also want to specify
-finline-limit=n (e.g. with n = 600) as GCC's inliner is not
yet well tuned for Fortran procedures (which tend to be larger
than C or C++ functions).
* Improved link-time optimization (LTO), i.e. optimization
across multiple .o files (compiled with gcc, g++, gfortran, ...).
With linker support also optimizing procedures called in
static libraries (.a). You need to use -flto both at compile
and at link time and you might want to combine it with
-fwhole-program.
* OpenMP 3.1 support
* Some new C 2011 features
* Several new C++ 2011 features


Fortran part:

* Fortran 2003: Much better support for object-oriented programming
and polymorphism. In particular: "Constructors", i.e. generic
functions which have the same name as derived types, are now
implemented. Additionally, polymorphic ("CLASS(dt)") arrays are
now supported - and many bugs have been fixed.
* Fortran 2008:
- DO CONCURRENT is supported
- Coarrays: Nearly full support for a single image (-fcoarray=single)
with some issues with polymorphic coarrays remaining. (Preparations
have been done to support multi-image coarrays, but this feature
is not yet functional.)
* Technical Specification (TS) 29113 on further interoperability
of Fortran with C (candidate draft)
- OPTIONAL is now allowed with BIND(C)
- RANK intrinsic
- ASYNCHRONOUS is compatible with TS 29113 (since 4.6)
- New compiler flag -std=f2008ts for Fortran 2008 plus technical
specifications
* Better backtracing - especially on non-GLIBC systems.
* Some new flags, see release notes


There were several other changes: Bug fixes, improved support for
embedded systems, improved compile-time diagnostic. Compared with
4.6, the number of new gfortran features is smaller, but the number
of patch commits only slightly dropped: In 2010 there were 557 commits
for the Fortran front end, in 2011 it slightly reduced to 478.

Latest 4.7 status email:
http://gcc.gnu.org/ml/gcc/2012-01/msg00337.html

Release notes:
http://gcc.gnu.org/gcc-4.7/changes.html
New Fortran features (for all releases):
http://gcc.gnu.org/wiki/GFortran#news

Binary versions (partially nightly builds):
http://gcc.gnu.org/wiki/GFortranBinaries
Some Linux distributions have also 4.7 build available, see e.g.
http://gcc.gnu.org/wiki/GFortranDistros


Like always, we are happy to hear about success stories, but
also bug reports and other comments are highly welcome.


And like nearly all open-source projects: New contributors are
highly welcome. There are many projects available - from simple
to fancy; they consist of documentation, multi-image coarray support,
polymorphism, IEEE support, better compile-time and run-time
diagnostic, small bug fixes, other remaining Fortran 2003/2008
and TS29113 features.

If you are interested in contributing or writing any comment, simply
reply - or send an email to the gfortran mailing list or a private
email. You can also join the #gfortran IRC channel at irc.oftc.net,
but it usually rather quiet there.

There will likely be again a Summer of Code program from April/May
to August/September - thus, if you are a student (bachelor, master,
Ph.D or similar) - or if you know such a student, this might be an
option to improve a widely used, well known program.

Tobias

[Tim Prince]

On 02/02/2012 08:09 AM, Tobias Burnus wrote:

> Highlights of GCC 4.7.0 - general part:

> * Fortran 2008:
> - DO CONCURRENT is supported

Thanks, works well.

[Tobias Burnus]

Admittedly, it doesn't do much. It is currently transformed into an
ordinary DO loop. That's not bad as normal DO loops are already handled
pretty well.


However, it can be extended in two ways:

a) Loop optimization

I think in terms of the compiler front end, it is difficult to do; I expect
that most expressions are either too complicated or are already covered by
the normal loop optimization. One longer-term plan is to tell the
middle-end of the compiler that the loop order does not matter. My current
plan is to piggyback on the infrastructure added for Cilk+ [1]. I haven't
checked whether the current Cilk+ implementation supports it. However,
Cilk+ is not yet part of GCC. (An incomplete work-in-progress implementation
exists in a branch.) Forward porting would be possible, but currently other
items rank higher on gfortran's development agenda.

([1] Cilk is a C extension to allow thread-based parallelization; Cilk+ is
a split-off for C and C++. Cilk(+) targets similar needs as OpenMP.
Cf. https://en.wikipedia.org/wiki/Cilk and
https://en.wikipedia.org/wiki/Intel_Cilk_Plus )


b) (Auto)parallelization

As CONCURRENT implies, one could run the loop concurrently in multiple
threads. One could simply add an OpenMP call of the kind "!OMP$ parallel do".
However, not always a forking/joining is profitable. (The overhead might be
larger than the time saved.) Nor do users wish that such a loop is always
run in parallel. Adding OpenMP calls might also interact with manually added
!OMP$ statements. GCC has some autoparallelization support as well, but my
feeling is that it does not work well (in all compilers) and, thus,
autoparallelization is not widely used. (Besides, the infrastructure to tell
the middle end that it may autoparallelize the loop as there is no order
dependence does not exist, yet.)

As a longer plan, one could add some kind of parallelization, supported by
some flag (-fdo-concurrent=...) and make use of this information for
autoparallelization and OpenMP-based parallelization. However, as it is
unclear how it should be done and as manual "!OMP$ do" tagging works, it
has a low priority.

Tobias

PS: For gfortran, the development focus is currently on polymorphism and
object-oriented programming as defined in Fortran 2003 (mostly) and Fortran
2008 (some additions). And, of course, fixing regressions and other bugs.

[Richard Maine]

Tobias Burnus <bur...@net-b.de> wrote:

> ....polymorphic ("CLASS(dt)") arrays are now supported

I'm just curious about the "arrays" there. I'm not sure whether

1. that's a slip of the finger and really means "variables",

2. polymorphism is supported ony for arrays, but not scalars, or

3. polymophism was supported for scalars before, but now also is
supported for arrays.

I'm sort of guessing (1), but the other two possibilities do occur,
particularly as I do recall from several years ago having a compiler
that supported some parts of polymorphism only for arrays (in
particular, it supported allocatable polymorphics, but still required
that allocatables be arays).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Paul Anton Letnes]

> As a longer plan, one could add some kind of parallelization, supported by
> some flag (-fdo-concurrent=...) and make use of this information for
> autoparallelization and OpenMP-based parallelization. However, as it is
> unclear how it should be done and as manual "!OMP$ do" tagging works, it
> has a low priority.

Out of casual curiosity: are there ever "safe choices" that would always
work for the OpenMP statements private(a) shared(b) and so forth?
Because I assume that the -fdo-concurrent=openmp option would then have
to set these "automagically"?

Paul

[Tobias Burnus]

Richard Maine wrote:

> Tobias Burnus wrote:
>
>> ....polymorphic ("CLASS(dt)") arrays are now supported
>
> I'm just curious about the "arrays" there. I'm not sure whether
> 1. that's a slip of the finger and really means "variables",
>
> 2. polymorphism is supported ony for arrays, but not scalars, or
>
> 3. polymophism was supported for scalars before, but now also is
> supported for arrays.
>
> I'm sort of guessing (1)

Sorry, wrong guess. It's (3). Polymorphism support - for scalars - exists
since GCC 4.5 and is since 4.6 rather usable. During the development, it
turned out that polymorphic arrays had a large number of issues of their
own, thus, a "Sorry, not yet implemented" error was added - and the
development concentrated on fixing the issues for scalars (which mostly
were nonscalar-specific issues).

In a way, there is also some truth in (1): It took quite some time to
implement a stable polymorphism support and some programs which
use scalars can only be compiled with GCC 4.7.

There are still issues with the current implementation. In particular,
unlimited polymorphism and finalization have not been implemented.
For the latter, I have already seen multiple requests, but also one for
unlimited polymorphism.
And there are still many bugs and smaller missing features. For instance,
there are still issues with polymorphic coarrays; intrinsic assignment
to an allocatable polymorphic variable is not implemented and VALUE does
not work with polymorphic variables. There are diagnostics missing,
internal compiler errors occur, issues with elemental procedures and
lots of other bugs.


By the way, I have the impression that 2012 will be the year in which
Fortran's polymorphism gets more widely deployed in real-world application.
While in the last two years (and even earlier), it was deployed by early
adopters, the current compiler support seems to be finally robust enough
and compilers widely enough available that the usage has (and will)
increase. At least that's my impression based on the recent influx of
bug report, the discussions with users and own experience with a couple
of compilers.

> I do recall from several years ago having a compiler
> that supported some parts of polymorphism only for arrays (in
> particular, it supported allocatable polymorphics, but still required
> that allocatables be arays).

I think the reason was that the compiler in general didn't support
allocatable scalars. Thus, it makes sense that it didn't have allocatable
polymorphic scalar variables either. In case of gfortran, support for
allocatable scalars was added in 4.5, thus, supporting polymorphic scalars
from the beginning made sense.

(One could argue that the other compiler should have first implemented
allocatable scalars before polymorphism, but one somehow has to prioritize
the development.)

Tobias

[Tobias Burnus]

I have to admit that I have not really thought about it in detail. I think
some problems simply do not occur due to the definition of DO CONCURRENT.
Others probably can be solved in specific but not in all cases. Like with
the current autoparallelization, the compiler might not optimize a loop if
it cannot determine that it is safe to do so. I think the first step will
be to pass more information to the middle end of the compiler such that it
is more likely that the loop is autoparallelized (with
-ftree-parallelize-loops). I think that's also what other compilers do.

But as written, there are no near-term plan to augment the current
implementation. Only when the ideas start to materialize, one has to think
about those issues.

Tobias

[Richard Maine]

Tobias Burnus <bur...@net-b.de> wrote:

> Richard Maine wrote:

> > I do recall from several years ago having a compiler
> > that supported some parts of polymorphism only for arrays (in
> > particular, it supported allocatable polymorphics, but still required
> > that allocatables be arays).
>
> I think the reason was that the compiler in general didn't support
> allocatable scalars. Thus, it makes sense that it didn't have allocatable
> polymorphic scalar variables either.

Yes, I'm sure of it. It was NAG, by the way, but from some time ago.

> (One could argue that the other compiler should have first implemented
> allocatable scalars before polymorphism, but one somehow has to prioritize
> the development.)

Indeed. I can't fault the decision. I just found it frustrating to
discover that it pretty much made the polymorphism useless for me, as
almost everything I wanted to do with polymorphism involved allocatable
scalars. I coud have substituted pointers, but that would have brought
with it all the increased opportunities for bugs that come with using
pointers as substitutes for allocatables. Seemed like the wrong
direction for me to go. I dropped back to wait for the allocatable
scalar support instead (which turned out not to come until after I was
no longer actively working).

[Damian Rouson]

Bravo for gfortran! The pace of progress on the latest version has been
truly impressive. From my perspective, 4.7.0 is rock solid: nearly all
of the OOP features of Fortran 2003 have been implemented correctly at
least for my purposes. This is a big step forward. My greatest hope is
that gfortran will start to become the "reference implementation,"
assuming the leadership role in the Fortran community that g++ did in
the C++ community 10-15 years ago.

If anyone does go after a Summer of Code position, I'd like to put in a
plug for two unimplemented features: deferred-length character
components and final subroutines. If anyone wants to submit a Summer of
Code application related to these topics, I'd be glad to assist with
connecting the person with a mentor. I know a several people in
government laboratories and universities who would be appropriate
mentors (both in the U.S. and abroad).

Damian

[Damian Rouson]

[John Harper]

Will gfortran 4.7 support the IEEE intrinsic modules as in the f2003
standard?

--
John Harper

[steve]

No.

--
steve