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).