public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/23889] New: non intuitive behaviour of gfortran
@ 2005-09-14 22:27 kamaraju at gmail dot com
2005-09-14 22:29 ` [Bug libfortran/23889] " pinskia at gcc dot gnu dot org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: kamaraju at gmail dot com @ 2005-09-14 22:27 UTC (permalink / raw)
To: gcc-bugs
consider the following program
program random
implicit none
real :: x
call random_seed();
call random_number(x);
write(*,*) x
end program random
When I run this program, I want to output different random numbers for
each run. This does not happen with gfortran.
$gfortran random.f90
$./a.out
0.1264991
$./a.out
0.1264991
$./a.out
0.1264991
I agree that the current gfortran's behaviour is standard conforming. But it is
counter intuitive. Most of the other compilers (see below) do not exhibit this
behaviour. It would be nice if this functionality is provided by gfortran also.
I tried intel compiler (ifort 8.1). It does what I want to
do.
$ifort random.f90
$./a.out
0.3770227
$./a.out
0.7290102
$./a.out
8.0997661E-02
$./a.out
0.1369602
This is what I get with g95 (2005 Sep 13) build.
% ./a.out
0.5556493
% ./a.out
0.3600861
% ./a.out
0.7311671
% ./a.out
0.3920767
Absoft 8.0 exhibits this behaviour
% f90 random.f90
% ./a.out
0.139087
% ./a.out
0.139087
% ./a.out
0.139087
% ./a.out
0.139087
So absoft, intel, g95 compilers generate different sequences on subsequent runs.
I hope gfortran also uses this methodology just to be consistent with the
common practice if not for anything else.
--
Summary: non intuitive behaviour of gfortran
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kamaraju at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
@ 2005-09-14 22:29 ` pinskia at gcc dot gnu dot org
2005-09-15 0:16 ` kargl at gcc dot gnu dot org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-09-14 22:29 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|fortran |libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
2005-09-14 22:29 ` [Bug libfortran/23889] " pinskia at gcc dot gnu dot org
@ 2005-09-15 0:16 ` kargl at gcc dot gnu dot org
2005-09-15 2:12 ` kamaraju at gmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-09-15 0:16 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From kargl at gcc dot gnu dot org 2005-09-15 00:15 -------
(In reply to comment #0)
> consider the following program
> program random
> implicit none
> real :: x
> call random_seed();
> call random_number(x);
> write(*,*) x
> end program random
>
> When I run this program, I want to output different random numbers for
> each run. This does not happen with gfortran.
>
> I agree that the current gfortran's behaviour is standard conforming.
Enough said.
> But it is counter intuitive.
It is counter intuitive to you not me.
> Absoft 8.0 exhibits this behaviour
>
> % f90 random.f90
> % ./a.out
> 0.139087
> % ./a.out
> 0.139087
> % ./a.out
> 0.139087
> % ./a.out
> 0.139087
>
>
> So absoft, intel, g95 compilers generate different sequences on
> subsequent runs.
What is Absoft's behavior? It appears to agree with gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
2005-09-14 22:29 ` [Bug libfortran/23889] " pinskia at gcc dot gnu dot org
2005-09-15 0:16 ` kargl at gcc dot gnu dot org
@ 2005-09-15 2:12 ` kamaraju at gmail dot com
2005-09-15 3:44 ` sgk at troutmask dot apl dot washington dot edu
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kamaraju at gmail dot com @ 2005-09-15 2:12 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From kamaraju at gmail dot com 2005-09-15 02:11 -------
Subject: Re: non intuitive behaviour of gfortran
On 15 Sep 2005 00:15:27 -0000, kargl at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> ------- Additional Comments From kargl at gcc dot gnu dot org 2005-09-15 00:15 -------
> (In reply to comment #0)
> > consider the following program
> > program random
> > implicit none
> > real :: x
> > call random_seed();
> > call random_number(x);
> > write(*,*) x
> > end program random
> >
> > When I run this program, I want to output different random numbers for
> > each run. This does not happen with gfortran.
> >
>
> > I agree that the current gfortran's behaviour is standard conforming.
>
> Enough said.
>
> > But it is counter intuitive.
>
> It is counter intuitive to you not me.
>
Dont know what to say. Well if the original authors want it that way
there is really nothing I can do about it.
Would it atleast be possible to implement it as an extension?
Something like if the user gives an option in the compiling command,
then the random numbers generated across different runs will be
different.
> > Absoft 8.0 exhibits this behaviour
> >
> > % f90 random.f90
> > % ./a.out
> > 0.139087
> > % ./a.out
> > 0.139087
> > % ./a.out
> > 0.139087
> > % ./a.out
> > 0.139087
> >
> >
> > So absoft, intel, g95 compilers generate different sequences on
> > subsequent runs.
>
> What is Absoft's behavior? It appears to agree with gfortran.
Sorry that was my bad. Absoft's and gfortran's behaviour are indeed
the same. But g95 and intel's behaviour are different than gfortran
(in this issue).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
` (2 preceding siblings ...)
2005-09-15 2:12 ` kamaraju at gmail dot com
@ 2005-09-15 3:44 ` sgk at troutmask dot apl dot washington dot edu
2005-09-16 16:09 ` kargl at gcc dot gnu dot org
2005-09-17 18:23 ` fxcoudert at gcc dot gnu dot org
5 siblings, 0 replies; 7+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2005-09-15 3:44 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-09-15 03:43 -------
(In reply to comment #2)
> >
> > > I agree that the current gfortran's behaviour is standard conforming.
> >
> > Enough said.
> >
> > > But it is counter intuitive.
> >
> > It is counter intuitive to you not me.
> >
>
> Dont know what to say. Well if the original authors want it that way
> there is really nothing I can do about it.
(1) Supply a patch if you want something else.
(2) There are several real bugs that need squishing. The current behavior
conforms to the standard. We have limited time and resources.
(3) Even if gfortran changed its behavior, you are depending
on processor-dependent behavior. Are you going to ask
Absoft (and ever other vendor) to change their random_seed()
behavior to suit your needs.
(4) A portable solution exist. I hacked this up in about 1 minute.
I'm sure your can wrap this in a subroutine, enhance it, and
call that subroutine instead of random_seed().
integer size, values(8)
real, allocate :: put(:)
call random_seed(size=size)
allocate(put(size))
call date_and_time(values=values)
if (any(values) == 0) values = 7
if (size <= 8) then
put(1:size) = values(1:size)
else
put = 10
put(1:8) = values
end if
call random_seed(put=put)
deallocate(put)
> Would it atleast be possible to implement it as an extension?
> Something like if the user gives an option in the compiling command,
> then the random numbers generated across different runs will be
> different.
I believe you can do this on mainline. The patch to pass compile time flags
to the runtime library may not be available in 4.0.2. I'll changed your
PR to an enhancement request when I get a chance (although I doubt anyone
will get to this in the near future).
> Sorry that was my bad. Absoft's and gfortran's behaviour are indeed
> the same. But g95 and intel's behaviour are different than gfortran
> (in this issue).
Clearly, you are looking at processor-dependent behavior. I advocate
that you investigate the portable solution that I've outlined above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
` (3 preceding siblings ...)
2005-09-15 3:44 ` sgk at troutmask dot apl dot washington dot edu
@ 2005-09-16 16:09 ` kargl at gcc dot gnu dot org
2005-09-17 18:23 ` fxcoudert at gcc dot gnu dot org
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-09-16 16:09 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 16:09 -------
Switch Severity to enhanacement (although I disagree the basic premise).
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2005-09-16 16:09:00
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libfortran/23889] non intuitive behaviour of gfortran
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
` (4 preceding siblings ...)
2005-09-16 16:09 ` kargl at gcc dot gnu dot org
@ 2005-09-17 18:23 ` fxcoudert at gcc dot gnu dot org
5 siblings, 0 replies; 7+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2005-09-17 18:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-17 18:23 -------
Summary of compilers behaviour on that one:
+ Absoft, Portland, MIPS-Pro, NEC SX and IBM exhibit behaviour similar to
gfortran (generating same RN sequences)
+ Sun, Intel, g95 generate different RN sequences
While I don't have an opinion on the topic (apart from: "you should not depend
on any of those behaviours"), it clearly seems a low-priority enhancement. We're
in very good company!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-09-17 18:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-14 22:27 [Bug fortran/23889] New: non intuitive behaviour of gfortran kamaraju at gmail dot com
2005-09-14 22:29 ` [Bug libfortran/23889] " pinskia at gcc dot gnu dot org
2005-09-15 0:16 ` kargl at gcc dot gnu dot org
2005-09-15 2:12 ` kamaraju at gmail dot com
2005-09-15 3:44 ` sgk at troutmask dot apl dot washington dot edu
2005-09-16 16:09 ` kargl at gcc dot gnu dot org
2005-09-17 18:23 ` fxcoudert at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).