Nabble - gcc - fortran

Re: Need higher resolution times for linpack benchmark

2009-12-19T02:58:20Z

On Fri, Dec 18, 2009 at 20:50, Steve Kargl
<sgk@...> wrote:
> On Fri, Dec 18, 2009 at 07:24:20PM +0200, Janne Blomqvist wrote:
>> Ping.
>>
>
> The patch looks ok to me. You need a ChangeLog
> entry.

Thanks, committed as r155359.

> Also, gfortran.info should probably mention
> the resolution that one might expect to have with
> your change, or perhap that system_clock() is typically
> implemented upon the POSIX gettimeofday() system call.

Yes, good idea. This is now PR 42434.

--
Janne Blomqvist

Re: Need higher resolution times for linpack benchmark

2009-12-18T10:50:58Z

On Fri, Dec 18, 2009 at 07:24:20PM +0200, Janne Blomqvist wrote:
> Ping.
>

The patch looks ok to me. You need a ChangeLog
entry. Also, gfortran.info should probably mention
the resolution that one might expect to have with
your change, or perhap that system_clock() is typically
implemented upon the POSIX gettimeofday() system call.

--
Steve

Re: Need higher resolution times for linpack benchmark

2009-12-18T09:24:20Z

Ping.

On Sat, Dec 12, 2009 at 18:55, Janne Blomqvist
<blomqvist.janne@...> wrote:

> On Sat, Dec 12, 2009 at 02:19, Tobias Burnus <burnus@...> wrote:
>> In principle, SYSTEM_CLOCK would, if count_rate is/were large enough,
>> cf. http://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html
>>
>> Internally, it uses POSIX's clock_gettime (when available), which in
>> principle provides sub-ms resolution.
>
> Actually, it doesn't. It prefers to use gettimeofday() which provides
> 1 us resolution, falling back to time() with 1s resolution. In
> practice, I believe gettimeofday() is available more or less
> everywhere. With clock_gettime() we could get in principle up to 1 ns
> resolution (With Linux 2.6.31 I got around 60 -> 800 ns depending in
> which timer I used), however the downside of that is that it's not as
> ubiquitous and if it exists it lives in librt or libposix depending on
> platform, so we'd need some configure magic to handle that and link in
> those libraries.
>
>> However, I think for INTEGER(4) and
>> for INTEGER(8) the clock_rate should be the same; if so, one cannot make
>> it too high, otherwise count wraps round all the time for INTEGER(4).
>
> I disagree. Code which assumes some specific value for clock_rate is
> broken anyway, as can be seen by the fact that other compilers use
> different values.
>
> Hence, see the attached patch, which makes clock_rate = 1e6 for the
> integer(8) version, giving 1 us resolution. As mentioned above, if we
> need more, we need to use clock_gettime(). Also, it removes an unused
> argument from the gettimeofday() call. Ok for trunk (with a ChangeLog,
> of course)?
>
>> I think we should consider to change the rate from 1000 (->25d) to 10000
>> (->60h).
>
> I don't know; 60h is pretty easy to overflow for some long-running calculation.
>
>>(And finally support non-integer clock_rates, cf. PR 28484.)
>
> Yes. However since the actual implementation has no need for real
> clock rates, this is IMHO best achieved by having the frontend use a
> temporary integer variable and then copying back the result to the
> real variable.
>
> Similarly, F2003 allows any integer kinds in any combination, and to
> support that without a combinatorial explosion of library functions,
> we need to use temp variables and copying in the frontend. Of course,
> this applies to a lot of other intrinsics as well.
>
> Also, see the attached C++ file for a simple test for different timing
> functions. For me, a typical runs looks like
>
> Testing clock()
> avg/min/max: 10/10/10 ms.
> Testing times()
> _SC_CLK_TCK: 100
> Real time Avg/Min/Max: 8.7/0/10 ms.
> User time Avg/Min/Max: 2.8/0/10 ms.
> Sys time Avg/Min/Max: 3.5/0/10 ms.
> Testing getrusage()
> User time Avg/min/max: 9.7/0/10 ms.
> System time avg/min/max: 33.8/0/210 ms.
> Testing gettimeofday()
> Wall time avg/min/max: 1/1/1 us.
> Testing clock_gettime() with CLOCK_MONOTONIC
> Clock avg/min/max: 74.48/67/752 ns.
> Testing clock_gettime() with CLOCK_REALTIME
> Clock avg/min/max: 66.31/65/91 ns.
> Testing clock_gettime() with CLOCK_PROCESS_CPUTIME_ID
> Clock avg/min/max: 171.33/169/381 ns.
> Testing clock_gettime() with CLOCK_THREAD_CPUTIME_ID
> Clock avg/min/max: 157.73/156/217 ns.
>
> As can be seen, the CPU time accounting functions give around 10 ms
> resolution. One thing we could consider would be using times() instead
> of getrusage() in order to avoid the large system time overhead of
> getrusage(). clock_gettime() with *CPUTIME_ID provides rather better
> CPU time resolution, but unfortunately suffers from the usual problems
> associated with using rdtsc on SMP systems.
>
>
> --
> Janne Blomqvist
>

--
Janne Blomqvist

Re: Errors with optional arguments

2009-12-18T05:50:52Z

On Dec 18 2009, Ignacio Fernández Galván wrote:
>
> Ah! Thanks, I knew there had to be something. This fixes the "memory"
> problem too. But I still get the segmentation fault with OMP (which is
> what made me write the test files at first).

Given the number of "gotchas" in OpenMP, I am not surprised you have
fallen into a hole. I am currently writing a course on it; please Email
me if you would like to see a (crude, early, partial) draft of the slides.

>By the way, are array variables allowed in OMP Reduction clauses?

Theoretically, yes. In practice, don't ask for trouble. That area of
OpenMP is an ungodly mess.

Regards,
Nick Maclaren.

Re: Errors with optional arguments

2009-12-18T02:18:48Z

--- On Fri, 18/12/09, Salvatore Filippone <salvatore.filippone@...> wrote:

> Your code is wrong. You CANNOT use optional arguments
> without an INTERFACE.

Ah! Thanks, I knew there had to be something. This fixes the "memory" problem too. But I still get the segmentation fault with OMP (which is what made me write the test files at first).

By the way, are array variables allowed in OMP Reduction clauses?

Ignacio

Re: Errors with optional arguments

2009-12-18T01:56:13Z

Ignacio Fernández Galván <jellby at yahoo dot com> wrote:
I encountered a couple of errors when trying to use optional arguments
in subroutines. First, this one happens when the optional argument is
the last of three, but not the only one or the last of two:

==========================================

$ cat test.f90

program test
implicit none
real :: a,b,c

call one(a)
write(6,*) a
call one()
write(6,*) a

call two(a,b)
write(6,*) b
call two(a)
write(6,*) b

call three(a,b,c)
write(6,*) c
call three(a,b)
write(6,*) c

end program test
-----------------------------------

Your code is wrong. You CANNOT use optional arguments without an INTERFACE.
One solution would be to put the code into a module, as follows

module foo
contains

subroutine one(a)
implicit none
real,optional :: a

if (present(a)) a=0.0

end subroutine one

subroutine two(a,b)
implicit none
real :: a
real,optional :: b

if (present(b)) b=0.0

end subroutine two

subroutine three(a,b,c)
implicit none
real :: a,b
real,optional :: c

if (present(c)) c=0.0

end subroutine three
end module foo

program test
use foo
implicit none
.......
end program test

HTH
Salvatore

Errors with optional arguments

2009-12-18T01:26:03Z

Hi all,

I encountered a couple of errors when trying to use optional arguments in subroutines. First, this one happens when the optional argument is the last of three, but not the only one or the last of two:

==========================================

$ cat test.f90

program test
implicit none
real :: a,b,c

call one(a)
write(6,*) a
call one()
write(6,*) a

call two(a,b)
write(6,*) b
call two(a)
write(6,*) b

call three(a,b,c)
write(6,*) c
call three(a,b)
write(6,*) c

end program test

subroutine one(a)
implicit none
real,optional :: a

if (present(a)) a=0.0

end subroutine one

subroutine two(a,b)
implicit none
real :: a
real,optional :: b

if (present(b)) b=0.0

end subroutine two

subroutine three(a,b,c)
implicit none
real :: a,b
real,optional :: c

if (present(c)) c=0.0

end subroutine three

$ $ gfortran test.f90 ; ./a.out
0.0000000
0.0000000
0.0000000
0.0000000
0.0000000
Violación de segmento

==========================================

This other error occurs when using an optional argument in an OMP Reduction clause (is this allowed, anyway?):

==========================================

$ cat test2.f90

program test
implicit none
real :: aa,bb

aa=1.0
bb=0.0

call one(aa)
write(6,*) aa,bb

bb=0.0

call one(aa,bb)
write(6,*) aa,bb

bb=0.0

call one(aa)
write(6,*) aa,bb

end program test

subroutine one(a,b)
implicit none
real :: a
real, optional :: b
integer :: i

a=0.0
if (present(b)) b=1.0
!$omp parallel private(i) reduction(+:a,b)
!$omp do
do i=1,1000000
a=a+1.0
if (present(b)) b=b+1.0
end do
!$omp end do
!$omp end parallel

end subroutine one

$ gfortran -fopenmp test2.f90 ; ./a.out
Violación de segmento

$ gfortran test2.f90 ; ./a.out
1000000.0 0.0000000
1000000.0 1000001.0
1000000.0 1000001.0

==========================================

... and, as you see, when not using OMP, the optional argument is somehow being "remembered" the third time the subroutine is called, it should have printed 0.0000000 instead of 1000001.0.

All this was done with the latest binary build in a linux system:

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/todos/Programas/gfortran-20091206/bin/../libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/jerry/gcc/trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --disable-shared
Thread model: posix
gcc version 4.5.0 20091205 (experimental) [trunk revision 155016] (GCC)

Is this a known or expected behaviour? Am I doing something wrong? Should I file a bug report?

Thanks,
Ignacio

Re: Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-18T01:01:18Z

On 17 Dec 2009, at 20:54, Matt Fago wrote:

>> I've seen similar confusing errors when the configure process
>> picked up old versions of the libraries that were installed in some
>> unexpected places. As, say, mpfr requires gmp, both (using a
>> hopefully obvious notation) $WITH_GMP_DIR/include and
>> $WITH_MPFR_DIR/include will be passed to the compiler as parts of
>> the include search path (i.e. -I). So if you have an old version of
>> mpfr in $WITH_GMP_DIR, this will be picked up instead of the newer
>> version of $WITH_MPFR_DIR (or vice versa, depending of the ordering
>> of the command line). So I guess you should try uninstalling any
>> old versions of these libraries that are lying around, or try
>> installing all new versions in one place, and then simply using --
>> with-gmp to point to them once and for all.
>
>
> Unless you know exactly what you are doing I would very strongly
> suggest doing in-tree builds of gmp, mpfr, and mpc. This will let
> gcc compile these three libraries for you and link gcc/gfortran
> statically to these libraries. This way you never have to worry
> about them at all, really.
>
> See http://gcc.gnu.org/install/prerequisites.html
>
> The key lines are:
>
> "...if a GMP source distribution is found in a subdirectory of your
> GCC sources named gmp, it will be built together with GCC."
> "...if a MPFR source distribution is found in a subdirectory of your
> GCC sources named mpfr, it will be built together with GCC."
> "...if an MPC source distribution is found in a subdirectory of your
> GCC sources named mpc, it will be built together with GCC. "
>
> So just unpack the sources into the top of the gcc source tree and
> change the directory names appropriately.
>
> Yes, this is quite hidden, and completely overlooked by 99.9% of
> everyone. But at least it's documented somewhere now.
>
> IMHO, this should be more obvious, and the recommended practice.

This is a great idea (and I was doing it all the time until approx. 6
months ago).

however, in-tree builds are broken right now on darwin and i686-pc-
linux-gnu (PR42424) and have been broken on & off since the move to
make c++ compat.
I lost enthusiasm since earlier PRs provoked no response at all (from
which I infer not many people are using the in-tree method).

.... Notwithstanding this, if one is doing a one-off build it's a
great idea.

However, for repeated build/regtest the gmp/mpfr/mpc builds and checks
start to chew up a fair amount of time.

Darwin GMP/MPFR build requires some finessing - see the comment(s) on
the GMP site:

I build GMP/MPFR as 4-way fat static libraries (scripts attached,
you'll need Apple's Developer tools installed so that the SDKs can be
found - free download). [there are no instructions and I've nowhere
to host them - so if you want/need help have to contact me off list].

... this method means that there's no issue with having to supply/
locate the dylibs for gmp/mpfr/mpc...

The resulting trees can be placed anywhere (I put them on the same
partition as I use for building gcc). One then refers to them with --
with-{gmp,mpfr}=/wherever/you/put/them.

MPC in-tree build is then working (although its make check fails
because it can't find the gmp lib).

The scripts are NOT user-friendly nor generic - you have to edit them
to your requirements ;
I don't recommend trying to build the objects in the source directory
- it will get immensely confusing (might not even work..) ;-)

cheers,
Iain

gmp-cover.h (1K) Download Attachment
make-gmp-431-x5.sh (9K) Download Attachment
make-mpfr-241-x5.sh (7K) Download Attachment

Re: RFC: PR 22552 and PR 39171

2009-12-17T14:14:43Z

Hi Daniel,

Daniel Kraft wrote:
> Here are two bugs I'd like "group opinion" on (I wanted to mention
> this on the meeting, so here is the late version).
> [...]

> PR 22552:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
> This is about adding a warning (presumably -Wimplicit-procedure) when a
> "undeclared" procedure is called.

I once had wished I had such a warning. As IMPLICIT NONE does not apply
to procedures, it could be handy, sometimes. As the
implementation/documentation/maintainance effort is low, I think one can
add it.

+Warn if a procedure is called that has not been declared explicitly (either by
+having an explicit interface, being a module procedure or declaring it
+@code{EXTERNAL}).

I don't not 100% like the explanation; for instance a host or use
associated provides also an explicit interface and being a module
procedure in a different scope does not help. PROCEDURE() is another
possibility but as this also marks a symbol as EXTERNAL, I think that
can be regarded as covered by "declaring it EXTERNAL". How about:

"Warn if a procedure is called that has neither an explicit interface
nor has been declared as EXTERNAL."?

> PR 39171:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39171
> When something like CHARACTER(LEN=-1) (negative charlength) is declared,
> there's currently a warning which is quite misleading, though (as it
> states the character length is zero; for actual zero length however, no
> warning is issued at all). From a standard's point of view, a negative
> charlength is fine and will be treated like LEN=0; but I think a warning
> is a good idea in this case; and we should in any case fix the old
> misleading warning. Do you think we should warn always or only with
> some -W... flag? I'm willing to work out a patch for this if we get an
> agreement on what exactly to do here.

I think that by default no warning should be printed. It is a bit
unusual usage, but perfectly valid. Maybe -Wsurprising could be an
option ('Produce a warning when "suspicious" code constructs are
encountered. While technically legal these usually indicate that an
error has been made.')

Printing no warning at all would also be fine with me. Thus: In any
case, one should do something about it. But I am agnostic with regards
to no warning vs. improved wording + only with -W*.

Tobias

PS: I will have only a dialup internet connection for a fortnight.

PPS: Before I forget it: Seasonal greeting, merry Christmas, and a happy
new year to all of you!

Re: FW: Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-17T12:54:47Z

> I've seen similar confusing errors when the configure process picked
> up old versions of the libraries that were installed in some
> unexpected places. As, say, mpfr requires gmp, both (using a
> hopefully obvious notation) $WITH_GMP_DIR/include and $WITH_MPFR_DIR/
> include will be passed to the compiler as parts of the include
> search path (i.e. -I). So if you have an old version of mpfr in
> $WITH_GMP_DIR, this will be picked up instead of the newer version
> of $WITH_MPFR_DIR (or vice versa, depending of the ordering of the
> command line). So I guess you should try uninstalling any old
> versions of these libraries that are lying around, or try installing
> all new versions in one place, and then simply using --with-gmp to
> point to them once and for all.

Unless you know exactly what you are doing I would very strongly
suggest doing in-tree builds of gmp, mpfr, and mpc. This will let gcc
compile these three libraries for you and link gcc/gfortran statically
to these libraries. This way you never have to worry about them at
all, really.

See http://gcc.gnu.org/install/prerequisites.html

The key lines are:

"...if a GMP source distribution is found in a subdirectory of your
GCC sources named gmp, it will be built together with GCC."
"...if a MPFR source distribution is found in a subdirectory of your
GCC sources named mpfr, it will be built together with GCC."
"...if an MPC source distribution is found in a subdirectory of your
GCC sources named mpc, it will be built together with GCC. "

So just unpack the sources into the top of the gcc source tree and
change the directory names appropriately.

Yes, this is quite hidden, and completely overlooked by 99.9% of
everyone. But at least it's documented somewhere now.

IMHO, this should be more obvious, and the recommended practice.

HTH,
Matt

[patch, testsuite, libgomp.fortran] darwin no longer requires static linkage to access TLS.

2009-12-17T12:33:25Z

Hi All,

As discussed on IRC last night, Darwin targets no longer need -static-
libgcc to provide TLS. Consequently, the two tests that force this
(libgomp.fortran/crayptr2.f90 and libgomp.fortran/pr32550.f90) can be
tidied.

in each case:
-! { dg-options "-static-libgcc" { target *-*-darwin* } }
+! { dg-require-effective-target tls_runtime }

this is (IMO) the correct situation in any event - it seems misleading
to force non-standard options to make a target pass a few tests.
checked on darwin9 ppc/i686 and darwin10 (thanks to Dominique).

cheers,
Iain

====

2009-12-17 Iain Sandoe <iain.sandoe@...>

*libgomp/testsuite/libgomp.fortran/crayptr2.f90 remove forced static
linkage for darwin, protect the test with require-effective-target
tls_runtime
*libgomp/testsuite/libgomp.fortran/pr32550.f90 remove forced static
linkage for darwin, protect the test with require-effective-target
tls_runtime

====

Index: libgomp/testsuite/libgomp.fortran/crayptr2.f90
===================================================================
--- libgomp/testsuite/libgomp.fortran/crayptr2.f90 (revision 155320)
+++ libgomp/testsuite/libgomp.fortran/crayptr2.f90 (working copy)
@@ -1,6 +1,6 @@
! { dg-do run }
! { dg-options "-fopenmp -fcray-pointer" }
-! { dg-options "-fopenmp -fcray-pointer -static-libgcc" { target *-*-darwin* } }
+! { dg-require-effective-target tls_runtime }

use omp_lib
integer :: a, b, c, d, p
Index: libgomp/testsuite/libgomp.fortran/pr32550.f90
===================================================================
--- libgomp/testsuite/libgomp.fortran/pr32550.f90 (revision 155320)
+++ libgomp/testsuite/libgomp.fortran/pr32550.f90 (working copy)
@@ -1,6 +1,6 @@
! PR fortran/32550
! { dg-do run }
-! { dg-options "-static-libgcc" { target *-*-darwin* } }
+! { dg-require-effective-target tls_runtime }

integer, pointer, save :: ptr
integer, target :: targ

Re: FW: Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-17T07:50:56Z

Hi Damian,

Rouson, Damian wrote:

> I have now downloaded mpc 0.8.1 and installed it. Now make, make install,
> and make check all go through fine and configure finds mpc.h, but I think
> it¹s failing to find the mpc executable:
>
> checking for correct version of gmp.h... yes
> checking for correct version of mpfr.h... yes
> checking for the correct version of mpc.h... yes
> checking for the correct version of the gmp/mpfr/mpc libraries... no
> configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.2+ and MPC
> 0.8.0+.
> Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
> their locations. Source code for these libraries can be found at
> their respective hosting sites as well as at
> ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
> http://gcc.gnu.org/install/prerequisites.html for additional info. If
> you obtained GMP, MPFR and/or MPC from a vendor distribution package,
> make sure that you have installed both the libraries and the header
> files. They may be located in separate packages.
>
> I have gmp 4.3.1 and mpfr 2.4.1. Thoughts?

I've seen similar confusing errors when the configure process picked up
old versions of the libraries that were installed in some unexpected
places. As, say, mpfr requires gmp, both (using a hopefully obvious
notation) $WITH_GMP_DIR/include and $WITH_MPFR_DIR/include will be
passed to the compiler as parts of the include search path (i.e. -I).
So if you have an old version of mpfr in $WITH_GMP_DIR, this will be
picked up instead of the newer version of $WITH_MPFR_DIR (or vice versa,
depending of the ordering of the command line). So I guess you should
try uninstalling any old versions of these libraries that are lying
around, or try installing all new versions in one place, and then simply
using --with-gmp to point to them once and for all.

Hope this helps,
- Tobi

>
> Cheers,
> Damian
>
>
>
> On 12/17/09 6:37 AM, "Janus Weil" <janus@...> wrote:
>
>> Hi Damian,
>>
>>> I just did an svn update and also tried a fresh checkout, but both fail to
>>> configure because configure can't find mpc.h. Is this a new requirement? I
>>> never needed it before.
>> Yes, it is new, see http://gcc.gnu.org/ml/gcc/2009-11/msg00823.html.
>>
>>
>>> I'm on Mac OS 10.5.8. My configure line and the
>>> tail of the output are below. I installed mpc via macports, but it didn't
>>> seem to install mpc.h.
>> I think the 'mpc' that you find in macports is a different thing than
>> what GCC requires (namely some kind of audio tool). Try 'port info
>> mpc'. I have not been able to find mpc (the multi-precision library
>> for complex numbers) in the macports repo.
>>
>> You should consider building mpc from source (available from
>> http://www.multiprecision.org/).
>>
>> Cheers,
>> Janus
>>
>>
>
> ------ End of Forwarded Message
>
>

--
Tobias Schlüter
Am Coulombwall 1, Zi. 326
85748 Garching b. München
Tel.: +49/89/289-14139

Re: [Patch, Fortran] PR 42144: [OOP] deferred TBPs do not work

2009-12-17T07:43:37Z

Hi Tobias,

> I have now merged the trunk into the fortran-dev branch

thanks a bunch.

> (a) I ignored the trans-expr.c change as it does not apply
> to the vtable.

Yes, that's correct.

> (b) I have included the test case. Thus, you will
> probably get a FAIL when regtesting the branch.

I don't think so. The vtable implementation should be able to handle
deferred TBPs already.

Cheers,
Janus

Re: [Patch, Fortran] PR 42353: [OOP] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

2009-12-17T07:38:35Z

> the attached patch fixes a small OOP problem, where under certain
> circumstances one would get 'ambiguous reference' errors for the
> vtypes. The easiest thing I could think of to fix this is to make the
> vtypes private, which means that each module which uses a vtype will
> have its own private copy (which in principle should not be a problem,
> should it?).

In contrast to the patch I sent earlier, the version attached here
also fixes the second error in the PR, which I almost forgot about
("Error: The element in the derived type constructor at (1), for
pointer component '$extends', is DERIVED but should be DERIVED").

Although the patch obviously works, I'm not sure if it may have any
negative consequences and if it's the best thing to do. At least it
fixes the test case and regtests cleanly.

Comments? Suggestions? Ok for trunk?

Cheers,
Janus

pr42353_2.diff (670 bytes) Download Attachment

Re: [Patch, Fortran] PR 42144: [OOP] deferred TBPs do not work

2009-12-17T07:37:41Z

On 12/17/2009 10:41 AM, Janus Weil wrote:
>>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>>
>> OK for trunk.
>>
> Thanks. Committed as r155305.
>

I have now merged the trunk into the fortran-dev branch; that means for
this patch: (a) I ignored the trans-expr.c change as it does not apply
to the vtable. (b) I have included the test case. Thus, you will
probably get a FAIL when regtesting the branch. (And I did some
renaming; as this patch's testfile name was the same as an existing one
on the branch, I have renamed the branch one and updated
ChangeLog.fortran-dev.)

Transmitting file data
..........................................................................................................
Committed revision 155317.

Tobias

FW: Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-17T07:19:02Z

I forgot to turn off the HTML formatting again. Here¹s a resend:

------ Forwarded Message
From: Damian Rouson <rouson@...>
Date: Thu, 17 Dec 2009 07:16:58 -0800
To: Janus Weil <janus@...>
Cc: gfortran <fortran@...>
Conversation: Configuring fails on missing mpc.h on Mac OS 10.5.8
Subject: Re: Configuring fails on missing mpc.h on Mac OS 10.5.8

Thanks, Janus.

I have now downloaded mpc 0.8.1 and installed it. Now make, make install,
and make check all go through fine and configure finds mpc.h, but I think
it¹s failing to find the mpc executable:

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.2+ and MPC
0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.

I have gmp 4.3.1 and mpfr 2.4.1. Thoughts?

Cheers,
Damian

On 12/17/09 6:37 AM, "Janus Weil" <janus@...> wrote:

> Hi Damian,
>
>> I just did an svn update and also tried a fresh checkout, but both fail to
>> configure because configure can't find mpc.h. Is this a new requirement? I
>> never needed it before.
>
> Yes, it is new, see http://gcc.gnu.org/ml/gcc/2009-11/msg00823.html.
>
>
>> I'm on Mac OS 10.5.8. My configure line and the
>> tail of the output are below. I installed mpc via macports, but it didn't
>> seem to install mpc.h.
>
> I think the 'mpc' that you find in macports is a different thing than
> what GCC requires (namely some kind of audio tool). Try 'port info
> mpc'. I have not been able to find mpc (the multi-precision library
> for complex numbers) in the macports repo.
>
> You should consider building mpc from source (available from
> http://www.multiprecision.org/).
>
> Cheers,
> Janus
>
>

------ End of Forwarded Message

Re: Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-17T06:37:14Z

Hi Damian,

> I just did an svn update and also tried a fresh checkout, but both fail to
> configure because configure can't find mpc.h. Is this a new requirement? I
> never needed it before.

Yes, it is new, see http://gcc.gnu.org/ml/gcc/2009-11/msg00823.html.

> I'm on Mac OS 10.5.8. My configure line and the
> tail of the output are below. I installed mpc via macports, but it didn't
> seem to install mpc.h.

I think the 'mpc' that you find in macports is a different thing than
what GCC requires (namely some kind of audio tool). Try 'port info
mpc'. I have not been able to find mpc (the multi-precision library
for complex numbers) in the macports repo.

You should consider building mpc from source (available from
http://www.multiprecision.org/).

Cheers,
Janus

Configuring fails on missing mpc.h on Mac OS 10.5.8

2009-12-17T05:34:46Z

I just did an svn update and also tried a fresh checkout, but both fail to
configure because configure can't find mpc.h. Is this a new requirement? I
never needed it before. I'm on Mac OS 10.5.8. My configure line and the
tail of the output are below. I installed mpc via macports, but it didn't
seem to install mpc.h.

Configure line:

/Users/rouson/fortran-dev/configure --program-suffix=-4.5 \
--enable-checking=release --prefix=/usr/local/gfortran \
--enable-languages=c,fortran --enable-version-specific-runtime-libs \
--build=x86_64-apple-darwin9 --host=x86_64-apple-darwin9 \
--target=x86_64-apple-darwin9 --disable-bootstrap --disable-multilib \
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local \
--with-libiconv-prefix=/opt/local

Output tail:

checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.2+ and MPC
0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also
http://gcc.gnu.org/install/prerequisites.html for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.

Any advice?

Damian

Re: Bugs in gfortran-4.3, gfortran-4.4 and gfortran-4.5

2009-12-17T04:15:35Z

On Thursday 17 December 2009 13:06:03 Jean-Baptiste FAURE wrote:
> Le 17.12.2009 11:09, Stefano Simonucci a écrit :
> > I have compiled a program (with many arrays) with the openmp flag
> > (-fopenmp). The program segfaults immediately. I have experienced this
> > behavior with gfortran-4.3, gfortran-4.4 and gfortran-4.5 (for AMD64).
> > If I compile the program with gfortran-4.2, I get a running binary.
> > I have downloaded also the binaries from the gnu site (before I have
> > used the Debian packages), but I get the same results.

You tried `ulimit -s unlimited` prior to running your application?

> I have the same problem if I compile with -fopenmp *and* -static.
> Without -static no problem.

Maybe an issue with (implicit) static linking of libpthreads?
See also comment #7 in here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
or, more generally, here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400

HTH

Daniel

Re: Bugs in gfortran-4.3, gfortran-4.4 and gfortran-4.5

2009-12-17T04:06:03Z

Le 17.12.2009 11:09, Stefano Simonucci a écrit :

> Hi!
> I have compiled a program (with many arrays) with the openmp flag
> (-fopenmp).
> The program segfaults immediately. I have experienced this behavior with
> gfortran-4.3, gfortran-4.4 and gfortran-4.5 (for AMD64). If I compile
> the program with gfortran-4.2, I get a running binary.
> I have downloaded also the binaries from the gnu site (before I have
> used the Debian packages), but I get the same results.
> Thank you
> Stefano Simonucci
>

I have the same problem if I compile with -fopenmp *and* -static.
Without -static no problem.

Regards

--
Jean-Baptiste FAURE
Cemagref - Unité de Recherche Hydrologie-Hydraulique
Tel: 04 72 20 87 76 - Fax: 04 78 47 78 75 - Web: www.lyon.cemagref.fr
Cemagref-Lyon 3bis, quai Chauveau C.P.220 69336 Lyon cedex09 FRANCE
Seuls des formats ouverts peuvent assurer la pérennité de vos documents

Re: Bugs in gfortran-4.3, gfortran-4.4 and gfortran-4.5

2009-12-17T02:18:21Z

Hi Stefano,

> I have compiled a program (with many arrays) with the openmp flag
> (-fopenmp).
> The program segfaults immediately. I have experienced this behavior with
> gfortran-4.3, gfortran-4.4 and gfortran-4.5 (for AMD64). If I compile
> the program with gfortran-4.2, I get a running binary.

thanks for reporting this. However, if you don't show us your code
(preferably a small test case), we won't be able to help you.

Cheers,
Janus

Bugs in gfortran-4.3, gfortran-4.4 and gfortran-4.5

2009-12-17T02:09:22Z

Hi!
I have compiled a program (with many arrays) with the openmp flag
(-fopenmp).
The program segfaults immediately. I have experienced this behavior with
gfortran-4.3, gfortran-4.4 and gfortran-4.5 (for AMD64). If I compile
the program with gfortran-4.2, I get a running binary.
I have downloaded also the binaries from the gnu site (before I have
used the Debian packages), but I get the same results.
Thank you
Stefano Simonucci

Re: [Patch, Fortran] PR 42144: [OOP] deferred TBPs do not work

2009-12-17T01:41:49Z

>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> OK for trunk.

Thanks. Committed as r155305.

Btw, when it comes to OOP, one of the bugs that we should definitely
fix for 4.5 is PR42385. This is another one of those wrong-code
nasties, where everything goes fine at compile time, but at runtime
you silently get wrong results (the other OOP-wrong-code PR is 41829,
which probably won't get fixed for 4.5, but at least it has a runtime
error message).

Cheers,
Janus

Re: [Patch, Fortran] PR 42144: [OOP] deferred TBPs do not work

2009-12-16T14:31:13Z

Dear Janus,

> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

OK for trunk.

Many thanks for the patch.

Paul

PS It's a pity that it will not be so easy with vtables....

[Patch, Fortran] PR 42144: [OOP] deferred TBPs do not work

2009-12-16T12:14:00Z

Hi all,

here is a patch which fixes dynamic dispatch with deferred type-bound
procedures. On trunk, dynamic dispatch is currently handled such that
a TBP call on a CLASS variable is translated into a SWITCH statement,
which decides at runtime which version of the TBP to call, depending
on the dynamic type.

Now, if the base type is abstract, we can just skip it when building
the switch statement, since the dynamic type can never be abstract.
This also prevents us from calling deferred TBPs (which previously
resulted in linking failures, see PR).

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus

gcc/fortran/
2009-12-16 Janus Weil <janus@...>

PR fortran/42144
* trans-expr.c (select_class_proc): Skip abstract base types.

gcc/testsuite/
2009-12-16 Janus Weil <janus@...>

PR fortran/42144
* gfortran.dg/dynamic_dispatch_6.f03: New test.

pr42144.diff (762 bytes) Download Attachment
dynamic_dispatch_6.f03 (2K) Download Attachment

RFC: PR 22552 and PR 39171

2009-12-16T07:11:19Z

Hi all,

first of all sorry that I could not attend the online meeting on Sunday;
I was in hospital, but am now back home (and hopefully everything is fine).

Here are two bugs I'd like "group opinion" on (I wanted to mention this
on the meeting, so here is the late version).

Thanks a lot!

Daniel

-------- Original Message --------
Subject: RFC: PR 22552 and PR 39171
Date: Mon, 10 Aug 2009 13:07:55 +0200
From: Daniel Kraft <d@...>
To: Fortran List <fortran@...>

Hi all,

PR 22552 and PR 39171 are two reports I just stumbled upon again, and I
think we could try to find a result... Comments welcome!

PR 22552:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
This is about adding a warning (presumably -Wimplicit-procedure) when a
"undeclared" procedure is called. Similar to -Wimplicit-interface, but
this warning would also be content with an EXTERNAL declaration or
defining the type for a function, even if no interface is explicitly
given. FX provided a patch and I did develop it further to a state
where it can, if you think this warning reasonable, checked-in directly.
What do you think, should we do this? Otherwise I'll mark the PR as
WONTFIX.

PR 39171:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39171
When something like CHARACTER(LEN=-1) (negative charlength) is declared,
there's currently a warning which is quite misleading, though (as it
states the character length is zero; for actual zero length however, no
warning is issued at all). From a standard's point of view, a negative
charlength is fine and will be treated like LEN=0; but I think a warning
is a good idea in this case; and we should in any case fix the old
misleading warning. Do you think we should warn always or only with
some -W... flag? I'm willing to work out a patch for this if we get an
agreement on what exactly to do here.

Thanks!

Daniel

--
Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri

--
Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri

[patch] fortran/*.texi: Fix typos.

2009-12-15T16:54:59Z

Hi,

Attached is a patch to fix typos.

Committed as obvious.

Kazu Hirata

2009-12-16 Kazu Hirata <kazu@...>

* gfc-internals.texi, gfortran.texi, invoke.texi: Fix typos.
Follow spelling conventions.

Index: fortran/gfc-internals.texi
===================================================================
--- fortran/gfc-internals.texi (revision 155276)
+++ fortran/gfc-internals.texi (working copy)
@@ -425,7 +425,7 @@ the type, rank and, if applicable, shape
tree of which the current structure is the root. @code{where} is the locus of
this expression in the source code.

-Depending on the flavour of the expression being described by the object
+Depending on the flavor of the expression being described by the object
(that is, the value of its @code{expr_type} member), the corresponding structure
in the @code{value} union will usually contain additional data describing the
expression's value in a type-specific manner. The @code{ref} member is used to
Index: fortran/gfortran.texi
===================================================================
--- fortran/gfortran.texi (revision 155276)
+++ fortran/gfortran.texi (working copy)
@@ -1911,7 +1911,7 @@ all C features have a Fortran equivalent
neither C's unsigned integers nor C's functions with variable number
of arguments have an equivalent in Fortran.

-Note that array dimensions are reversely orded in C and that arrays in
+Note that array dimensions are reversely ordered in C and that arrays in
C always start with index 0 while in Fortran they start by default with
1. Thus, an array declaration @code{A(n,m)} in Fortran matches
@code{A[m][n]} in C and accessing the element @code{A(i,j)} matches
Index: fortran/invoke.texi
===================================================================
--- fortran/invoke.texi (revision 155276)
+++ fortran/invoke.texi (working copy)
@@ -761,7 +761,7 @@ check that the declared interfaces are c
Warn if @command{gfortran} finds a procedure named like an intrinsic not
available in the currently selected standard (with @option{-std}) and treats
it as @code{EXTERNAL} procedure because of this. @option{-fall-intrinsics} can
-be used to never trigger this behaviour and always link to the intrinsic
+be used to never trigger this behavior and always link to the intrinsic
regardless of the selected standard.

@item -Wsurprising

Re: GFortran Bug Report: Size of pointer variables

2009-12-15T14:16:37Z

Am 15.12.2009 22:23, schrieb Steve Kargl:
> See Tobias' email for an answer to the above question.
> To add to your confusion, with gfortran mainline I see
>
> 1
> 1
> -6928
>

Well, that's the result of uninitialized memory. As -fdump-tree-original
shows, the bounds will not be initialized only <arraydescriptor>.data,
i.e. all tests except for ALLOCATED() will access invalid memory.

Try the following program. All my compilers print "5" for it: ifort,
gfortran, NAG f95, openf95, g95:

PROGRAM TEST
INTEGER, POINTER :: I(:)
integer, target :: j(5)
I=>j
I=>null()
PRINT *, SIZE(I)
END PROGRAM TEST

Which demonstrates again that size(i) == 0 was probably an artifact of
having no initialization of the bounds.

* * *

> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

I agree with Steve here that you should consider updating. GCC 4.1.2 was
one of the first usable version of gfortran, but several bugs have been
fixed in the meanwhile. The current stable version of GCC is 4.4.2 and
only 4.5, 4.4.2 and 4.3.4 are supported.

Tobias

Re: GFortran Bug Report: Size of pointer variables

2009-12-15T13:23:58Z

On Tue, Dec 15, 2009 at 03:52:50PM -0500, Tink,James [NCR] wrote:
>
> Which compiler is producing the correct output and why?
>

See Tobias' email for an answer to the above question.
To add to your confusion, with gfortran mainline I see

troutmask:sgk[215] gfc4x -o z -O2 fk.f90
troutmask:sgk[216] ./z
1
troutmask:sgk[217] gfc4x -o z -O fk.f90
troutmask:sgk[218] ./z
1
troutmask:sgk[219] gfc4x -o z fk.f90
troutmask:sgk[220] ./z
-6928

> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

If you can, it would be of significant use to you
to upgrade to at least 4.4.2.

--
Steve

Re: GFortran Bug Report: Size of pointer variables

2009-12-15T13:04:54Z

Am 15.12.2009 21:52, schrieb Tink,James [NCR]:

> I tried to compile the following source (in test.f90):
>
> PROGRAM TEST
> INTEGER, POINTER :: I(:)
> I=>NULL()
> PRINT *, SIZE(I)
> END PROGRAM TEST
>
> Using: gfortran [...] I get the following output:
> 1
> [...] using the Portland [...]
> 0
> Which compiler is producing the correct output and why?
>

Both compiler give the correct output. Looking at the current Fortran
standard (Fortran 2003) one finds in "13.7.112 SIZE (ARRAY [, DIM, KIND])":

"Arguments.
"ARRAY may be of any type. It shall not be scalar. It shall not be an
unallocated
allocatable or a pointer that is not associated. [...]"

And your pointer is not associated. As your program is not conforming to
the standard, anything is possible. Solution: Use the ASSOCIATE statement.

(For the Fortran standards, see http://gcc.gnu.org/wiki/GFortranStandards )

Tobias

GFortran Bug Report: Size of pointer variables

2009-12-15T12:52:50Z

I apologize for sending a bug report via e-mail but I don't understand
the bugzilla system, I'll try to submit bugs through it in the future.

I tried to compile the following source (in test.f90):

PROGRAM TEST
INTEGER, POINTER :: I(:)
I=>NULL()
PRINT *, SIZE(I)
END PROGRAM TEST

Using:

gfortran test.f90 -o test.e

When running test.e, I get the following output:

1

I tried to compile the same code using the Portland Group's Fortran 90
compiler:

pgf90 test.f90 -o test.e

And get the following output from running test.e:

0

Which compiler is producing the correct output and why?

I would expect that the size of a pointer variable which is not
associated (and pointing to NULL) would have size 0. This caused many of
my programs compiled with GFortran to produce segmentation faults, where
I assumed that an array with a non-zero size (which could possibly be a
non-associated array in GFortran) has associated values. I realize that
there is the ASSOCIATED intrinsic specifically to avoid this problem,
but GFortran's behaviour is unexpected regardless and no other compilers
that I know of have this same issue.

The output of gfortran -v on my system is:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

I'd be happy to give additional information upon request. Thanks for
your help,

James Tink

test.f90 (116 bytes) Download Attachment

Re: [patch, fortran] Fix PR41235, accepts invalid

2009-12-14T11:20:26Z

On Saturday 12 December 2009 00:18:05 Tobias Burnus wrote:

> Am 10.12.2009 22:52, schrieb Tobias Burnus:
> > I am not sure that the patch is correct. I think one refers to the
> > following item in the standard:
> >
> > "A procedure [...] shall have an explicit interface if it is referenced
> > and [...]
> > (3) The procedure has a result that [...]
> > (c) has a nonassumed type parameter value that is not an
> > initialization expression,"
>
> I updated the patch now:
>
> a) I deleted the current check, which rejected valid programs, where one
> had an implicit interface with non-init-expr character lengths.
> b) I added a check using -fwhole-file, which does prints an error under
> the constraint that gfortran knows that the function is does not have a
> assumed-length type parameter.
>
> Bootstrapped and regtested on x86-64-linux.
> OK for the trunk?

Ok. Thanks for working on this :)

Daniel

Re: Fix for typos in gfortran.dg/boz_15.f90

2009-12-14T10:19:34Z

> I have committed the patch to SVN mainline, ...

Thanks Uros.

Re: Fix for typos in gfortran.dg/boz_15.f90

2009-12-14T09:58:25Z

Hello!

> The test gfortran.dg/boz_15.f90 fails on powerpc*-*-* in 64 bit mode due
> to obvious typos (126 instead of 128 and 255 instead of 256, see
> http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01164.html).
> This is fixed by the following patch. OK for trunk? If yes, please commit
> (I don't have the rights to do it myself).
>
> Dominique
>
>
> gcc/testsuite/
> 2009-12-14 Dominique d'Humieres<dominiq@...>
>
> * gfortran.dg/boz_15.f90: Fix typos.
>

This patch certainly qualifies as obvious.

I have committed the patch to SVN mainline, after I checked that it also
fixes the failure on alphaev68-pc-linux-gnu.

Thanks,
Uros.

Re: A patch to fix the most obvious failures with -fwhole-file (take 2)

2009-12-14T09:49:02Z

On Mon, Dec 14, 2009 at 05:52:30PM +0100, Dominique Dhumieres wrote:

> > > + call gee_i(int(i**(-huge(0_8)-1_8),kind=kind(i)))
> >
> > This is simply code obfuscation with no merit. ...
>
> Had you run the test yourself, you'ld have seen
>
> Warning: Type mismatch in argument 'i' at (1); passed INTEGER(8) to INTEGER(4)
>
> In
>
> subroutine gee_i(i)
> integer :: i
> end subroutine gee_i
>
> gee_i expects an integer, i**(-huge(0_8)-1_8) is integer(8) even if i is
> integer, unless the promotion of i to integer(8) to compute the power
> is a gfortran bug.
>

I've already quoted the Fortran 2003 Standard.

--
Steve