Prev: do loop error in compiling?
Next: Help!! end-of-file during read, unit 1...
From: Tobias Burnus on 14 Apr 2010 08:03
Hello all,

contrary to IBM I cannot announce full Fortran 2003 support (gfortran is
not yet there) nor can I announce the addition of OpenMP 3.0 (as 4.4.0
already supports it), but I can announce the following regarding today's
GCC 4.5.0 release and regarding 4.6.


--- GCC 4.6 ---

Since Tuesday, 6 April there is a GCC 4.5.0 release candidate, which
means that GCC 4.6.0 development has started on that day. Highlights of
GCC/gfortran 4.6 so far:

* Much improved compile time for large array constructors

* Experimental, single-image coarray support
(about 75% of the work has been done; full multi-image parallelization
is also planned; cf.
http://users.physik.fu-berlin.de/~tburnus/coarray/README.txt)


--- GCC 4.6.0 ---

Today, GCC 4.5.0 has been released; it offers:
- Link time optimization (e.g. inlining a C++ function in Fortran)
- More Fortran 2003/2008 support, especially: experimental polymorphism
support

See http://gcc.gnu.org/gcc-4.5/changes.html for details.

Excerpt:

-----------------------------------------------------------------

* A new link-time optimizer has been added (-flto). When this option is
used, GCC generates a bytecode representation of each input file and
writes it to special ELF sections in each object file. When the object
files are linked together, all the function bodies are read from these
ELF sections and instantiated as if they had been part of the same
translation unit. This enables interprocedural optimizations to work
across different files (and even different languages), potentially
improving the performance of the generated code. To use the link-timer
optimizer, -flto needs to be specified at compile time and during the
final link. If the program does not require any symbols to be exported,
it is possible to combine -flto and the experimental -fwhopr with
-fwhole-program to allow the interprocedural optimizers to use more
aggressive assumptions.

* [Improved and extended evaluation of complex arithmetic at compile time]

* Support for the Intel Atom processor [...]


Windows (Cygwin and MinGW)

* GCC now installs all the major language runtime libraries as DLLs when
configured with the --enable-shared option.

* Numerous other minor bugfixes and improvements, and substantial
enhancements to the Fortran language support library.


C++

* Improved experimental support for the upcoming C++0x ISO C++ standard,
including support for raw strings, lambda expressions and explicit type
conversion operators.


Fortran

* The COMMON default padding has been changed � instead of adding the
padding before a variable it is now added afterwards, which increases
the compatibility with other vendors and helps to obtain the correct
output in some cases. Cf. also the -falign-commons option (added in 4.4).

* The -finit-real= option now also supports the value snan for
signalling not-a-number; to be effective, one additionally needs to
enable trapping (e.g. via -ffpe-trap=). Note: Compile-time optimizations
can turn a signalling NaN into a quiet one.

* The new option -fcheck= has been added with the options bounds,
array-temps, do, pointer, and recursive. The bounds and array-temps
options are equivalent to -fbounds-check and -fcheck-array-temporaries.
The do option checks for invalid modification of loop iteration
variables, and the recursive option tests for recursive calls to
subroutines/functions which are not marked as recursive. With pointer
pointer association checks in calls are performed; however, neither
undefined pointers nor pointers in expressions are handled. Using
-fcheck=all enables all these run-time checks.

* The run-time checking -fcheck=bounds now warns about invalid string
lengths of character dummy arguments. Additionally, more compile-time
checks have been added.

* The new option -fno-protect-parens has been added; if set, the
compiler may reorder REAL and COMPLEX expressions without regard to
parentheses.

* GNU Fortran no longer links against libgfortranbegin. As before,
MAIN__ (assembler symbol name) is the actual Fortran main program, which
is invoked by the main function. However, main is now generated and put
in the same object file as MAIN__. For the time being, libgfortranbegin
still exists for backward compatibility. For details see the new
Mixed-Language Programming chapter in the manual.

* The I/O library was restructured for performance and cleaner code.

* Array assignments and WHERE are now run in parallel when OpenMP's
WORKSHARE is used.

* The experimental option -fwhole-file was added. The option allows
whole-file checking of procedure arguments and allows for better
optimizations. It can also be used with -fwhole-program, which is now
also supported in gfortran.
[Remark: -flto implies -fwhole-file]

* More Fortran 2003 and Fortran 2008 mathematical functions can now be
used as initialization expressions.

* Some extended attributes such as STDCALL are now supported via the
GCC$ compiler directive.

* For Fortran 77 compatibility: If -fno-sign-zero is used, the SIGN
intrinsic behaves now as if zero were always positive.

* For legacy compatibiliy: On Cygwin and MinGW, the special files
CONOUT$ and CONIN$ (and CONERR$ which maps to CONOUT$) are now supported.

* Fortran 2003 support has been extended:
o Procedure-pointer function results and procedure-pointer components
(including PASS),
o allocatable scalars (experimental),
o DEFERRED type-bound procedures,
o the ERRMSG= argument of the ALLOCATE and DEALLOCATE statements have
been implemented.
o The ALLOCATE statement supports type-specs and the SOURCE= argument.
o OPERATOR(*) and ASSIGNMENT(=) are now allowed as GENERIC type-bound
procedure (i.e. as type-bound operators).
o Rounding (ROUND=, RZ, ...) for output is now supported.
o The INT_FAST{8,16,32,64,128}_T kind type parameters of the intrinsic
module ISO_C_BINDING are now supported, except for the targets listed
above as ones where GCC does not have <stdint.h> type information.
o Extensible derived types with type-bound procedure or procedure
pointer with PASS attribute now have to use CLASS in line with the
Fortran 2003 standard; the workaround to use TYPE is no longer supported.
o Experimental, incomplete support for polymorphism, including CLASS,
SELECT TYPE and dynamic dispatch of type-bound procedure calls. Some
features do not work yet such as unlimited polymorphism (CLASS(*)).

* Fortran 2008 support has been extended:
o The OPEN statement now supports the NEWUNIT= option, which returns a
unique file unit, thus preventing inadvertent use of the same unit in
different parts of the program.
o Support for unlimited format items has been added.
o The INT{8,16,32} and REAL{32,64,128} kind type parameters of the
intrinsic module ISO_FORTRAN_ENV are now supported.
o Using complex arguments with TAN, SINH, COSH, TANH, ASIN, ACOS, and
ATAN is now possible; the functions ASINH, ACOSH, and ATANH have been
added (for real and complex arguments) and ATAN(Y,X) is now an alias for
ATAN2(Y,X).
o The BLOCK construct has been implemented.
-----------------------------------------------------------------


Tobias
From: FX on 14 Apr 2010 08:28
> - Link time optimization (e.g. inlining a C++ function in Fortran)

It should be mentionned that this new link-time optimization is not
supported on non-ELF targets, which notably include Windows and Mac OS.

--
FX
From: Tobias Burnus on 14 Apr 2010 09:00
On 04/14/2010 02:28 PM, FX wrote:
>> - Link time optimization (e.g. inlining a C++ function in Fortran)
>
> It should be mentionned that this new link-time optimization is not
> supported on non-ELF targets, which notably include Windows and Mac OS.

That's true - but at least Windows (PE-COFF) will have it soon -
presumably in version 4.5.1. I do not know how soon Darwin/MacOS X will
get it, but I expect it also will have it soon.

Cf. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html

Tobias
From: FX on 14 Apr 2010 09:23
> but at least Windows (PE-COFF) will have it soon
> [...]
> Cf. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html

I missed that. Excellent news!

--
FX
From: James Van Buskirk on 14 Apr 2010 10:27
"Tobias Burnus" <burnus(a)net-b.de> wrote in message
news:4BC5AF17.2000300(a)net-b.de...

> * GNU Fortran no longer links against libgfortranbegin. As before,
> MAIN__ (assembler symbol name) is the actual Fortran main program, which
> is invoked by the main function. However, main is now generated and put
> in the same object file as MAIN__. For the time being, libgfortranbegin
> still exists for backward compatibility. For details see the new
> Mixed-Language Programming chapter in the manual.

There is also a new section in the manual: 5.2 Internal representation
of logical variables that contains information that, according to my
experience from the last time I tilted at this particular windmill, is
incorrect. I can't seem to find that thread today via Google; in fact
I can't get Google to find posts containing the word "end" in
comp.lang.fortran today, maybe you'll have better luck than me.
My suggestion is that you delete the section rather than create a
precedent for the situation described, which is the worst of all
possible worlds.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


 |  Next  |  Last
Pages: 1 2
Prev: do loop error in compiling?
Next: Help!! end-of-file during read, unit 1...