HDTenEightyP/NetNews huggingface dataset:
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: Legal optimization?
Date: 23 Nov 92 17:49:40 GMT
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


|>   >>>>> "Per" == Per Steinar Iversen <iversen@vsfys1.fi.uib.no> writes:
|>
|>     Per> One of the students here uses VAX FORTRAN to calculate various things for his
|>     Per> thesis. Recently he had some problems, which were traced down to a real bug.
|>     Per> However: A result of the bug was that a square root of a negative REAL occurred.
|>     Per> Yet this never made the program crash! When either a WRITE statement was 
|>     Per> inserted on the next line after the SQRT or the optimization was turned off,
|>     Per> then the program crashed properly... Presumably the optimizer transforms the
|>     Per> code into something which is OK if the values are *not* negative. At least in 
|>     Per> this program however the results were just garbage if the negative root occurred.
|>
|>   Welcome to the world of code optimization!  I don't think that the standard
|>   has any meaning once the optimizer has gotten hold of it. Rule: the optimizer
|>   is only as good as the person that wrote it. Some of them are damn good.  Most
|>   are good at local 10-20 line optimization.  It is when higher level
|>   optimization (i.e., so-called global optimization and inlining) is attempted
|>   that things can go wrong.
|>

I didn't see the original of this, but I think I can figure out what happened,
and it's simpler and less sinister than some seem to think.

The VAX FORTRAN compiler can remove code whose results are unused.  If a
SQRT of a negative value was computed but the result never used, the SQRT itself
would also be removed.  Adding the WRITE of the value caused the result to
be used and hence the error occurred.   This is a classic optimization
technique and perfectly valid.

It is true the Fortran standard doesn't say much about exceptions.  I like what
the Ada standard has to say in this regard.  Summarizing, section 11.6 says:

	1.  If the "canonical" order of operations does not produce an
	    exception, the reordered operations must not produce an exception.

	2.  A "predefined operation" (ie. an intrinsic or operator) doesn't
	    have to be performed if its only effect is to cause an
	    exception.

I take exception to the comment that "the standard [has no] meaning once the
optimizer has gotten hold of it", and I believe my sentiment would be shared
by any reputable compiler developer.  You might be able to ask for optimizations
which make assumptions contrary to or unspecified in the standard, but a 
standard-conforming program should execute in a standard-conforming manner no 
matter what optimizations are applied to it.  The most clever optimizations in
the world are worthless if you end up with wrong results.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.lang.fortran
From: paspro@.ic.ac.uk (Mr P.N. Asproulis)
Subject: Re: Print characters on one line without newline...???
Organization: Imperial College
Date: Mon, 23 Nov 92 14:02:39 GMT


The following subroutine will do the job 

        SUBROUTINE PrintX(XCOUNT)
        INTEGER XCOUNT

        INTEGER i

        PRINT *, ('X',i=1,XCOUNT)

        RETURN
        END

---------------------------------------------------           / \
 Department of Aeronautics                                    | |
 Imperial College of Science, Technology & Medicine   ________| |________
 Prince Consort Road, London SW7 2AY, U.K.           |________| |________|
 Room E355, Tel. : (071) 589 5111 Ext. 4028                   | |
 E-mail: p.asproulis@uk.ac.ic.ae                           ___| |___
---------------------------------------------------       |___\_/___|
 P. N. Asproulis

Newsgroups: comp.lang.fortran
From: iversen@dsfys1.fi.uib.no (Per Steinar Iversen)
Subject: Legal optimization?
Reply-To: iversen@vsfys1.fi.uib.no
Organization: Department of Physics, University of Bergen, Norway
Date: Sat, 21 Nov 92 11:41:31 GMT



One of the students here uses VAX FORTRAN to calculate various things for his
thesis. Recently he had some problems, which were traced down to a real bug.
However: A result of the bug was that a square root of a negative REAL occurred.
Yet this never made the program crash! When either a WRITE statement was 
inserted on the next line after the SQRT or the optimization was turned off,
then the program crashed properly... Presumably the optimizer transforms the
code into something which is OK if the values are *not* negative. At least in 
this program however the results were just garbage if the negative root occurred.

The compiler is VAX FORTRAN V5.8-155 under VMS 5.5. So far I always felt safe
if my programs compiled and ran with 
FORTRAN/CHECK=ALL/STANDARD=ALL/WARNING=(GENERAL,DECLARATIONS), but I guess I
should add /NOOPTIMIZE too.

My question is more philosophical perhaps: Are such transformations of the 
code actually legal, is the compiler performing within the standard?

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5212770                            !
! N-5007 Bergen          ! Fax:         +47 5318334                            !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: froehle@pepper.ra.anl.gov (P Froehle RE/207/xxx 4882)
Subject: Re: Data initialization: FORTRAN program called as SUBROUTINE
Organization: Argonne National Laboratory, Argonne IL
Date: Sat, 21 Nov 1992 17:13:15 GMT

In article <1992Nov18.025912.13187@netcom.com> jchauvin@netcom.com (John H. Chauvin) writes:
>
>I am currently working on a mix language program in which a C program 
>calls a large FORTRAN program ( 15,000 lines , 100+ SUBROUTINES, 
>and extensive use of COMMON blocks). I have converted the main routine 
>from the FORTRAN into a SUBROUTINE and am calling the routine from 
>the C code. I pass file information from the C program to the FORTRAN 
>program using C data structures to FORTRAN common blocks. The 
>general program flow is: C calls FORTRAN , waits, FORTRAN updates C, 
>FORTRAN returns to C, C calls FORTRAN ,etc.. The C and FORTRAN 
>routines are linked into one large binary program. All FORTRAN variables 
>required SAVE status. The main advantage to the above approach is the 
>ease to which I can exchange data between the C (graphics front end) and 
>the FORTRAN (number crunchier).
>
>Everything works great until I try and call the FORTRAN a second time. 
>The variables and COMMON blocks still retain values from the first call. 
>(Not surprisingly) How can I reinitialize all the COMMON blocks and 
>variables to the state that existed at the beginning of the first call?  
>Normally the FORTRAN would be executed as a stand alone program 
>from the command line , loaded into memory and the variables initialized 
>each time it is used. This is the behavior I want to achieve with each call to 
>the FORTRAN. Initializing all the variables myself is out of the questions 
>because of the size of the code and the fact that all the variables have 
>been SAVEd. Is there a way to do this?  Any help or suggestions would be 
>GREATLY appreciated.
>
Another way is to pass the data in a file and have the c program spawn
the fortran program.  That way the fortran program initializes each time.
..paul ... phfroehle@anl.gov
Newsgroups: comp.lang.fortran
From: crosby@titan.trl.OZ.AU (David Crosby)
Subject: help with D1MACH subroutine
Keywords: D1MACH
Organization: Telecom Research Labs, Melbourne, Australia
Date: Tue, 24 Nov 1992 01:03:46 GMT

Hi,
	I'm trying to run a program which uses double precision bessel
functions (dbesj0.f and dbesj1.f) on a dec machine (MIPS processor) with
a dec fortran compiler. The problem is that even though the program
compiles o.k it returns a floating point error when run. I assume that
this is because I have the wrong machine constants in the required
D1MACH subroutine. I have tried both the big-endian and little-endian
machine constants given in this subroutine but get the same result. Can
anybody help me? 

	Thanks
		Dave Crosby
	
Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: passing a string constant to a subroutine
Organization: MacNeal-Schwendler Corp.
Date: Fri, 20 Nov 92 21:19:38 GMT

In article <EJH.92Nov19160031@khonshu.colorado.edu> ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
>When I want to pass a string constant to a subroutine, what size do I
>declare the character variable to be in the subprogram. For example
>I have a subroutine:
>
>      subroutine ask_data_type(prog, typenum)
>
>This is intended to be called from one of several programs, and the
>program name is to be passed in as the first parameter. Inside the
>subroutine I have:
>      character*20 prog
>
>And when I called if from program atob.f this is what the call looked
>like:
>	call ask_data_type('atob',typenum)
>
>I assumed that it would put 'atob' in prog and blank fill the rest.
>What it did instead was fill the rest with grabage, not blanks. I
>avoid this problem now by doing this in the calling program:
>
>      character*20 prog
>      parameter (prog = 'atob')
>c
>      write(*,*) 'about to call ask_data_type'
>      call ask_data_type(prog,typenum)
>
>But I'm just wondering if what I did was non-standard or what.
>
Perfectly standard, just incorrect!  Your declaration:
	character*20 prog

can (and was in your example) the problem.  As a rule, *always*
declare all character dummy arguments as:
	character*(*) prog

As for why the *garbage*, read 15.9.3.1 (pg 15-17) from the standard:
	If a dummy argument is of type character, the associated 
	actual argument must be of type character and the length of
	the dummy argument must be less than or equal to the length
	of the actual argument.  If the length _len_ of a dummy
	argument of type character is less than the length of an
	associated actual argument, the leftmost _len_ characters of
	the actual argument are associated with the dummy argument.

Translation: the subroutine must use a smaller length than the
calling routine.  If the subroutine's length is less, the subroutine
cannot see the characters beyond the subroutine's declared length.
The vendor clearly did something like: you told me *prog* was 20 characters,
and by golly, I'm going to use twenty characters!

That's why you should always use the "*(*)" length specifier whenever
you declare a character in the argument list.

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.lang.fortran
From: ctrbdo@iapa.uucp%mailhost.ecn.uoknor.edu (bryan d oakley)
Subject: ENTRY in main
Organization: FAA / Mike Monroney Aeronautical Center
Date: Mon, 23 Nov 1992 20:10:41 GMT

Robert Corbett writes:

> In any case, a main program cannot contain an ENTRY statement.
> Section 14.2 of X3.9-1978 states
> 
>     A main program may contain any other statement except a
>     BLOCK DATA, FUNCTION, SUBROUTINE, ENTRY, or RETURN
>     statement.

right you are!  Further, Section 15.7 (ENTRY statement) states 

    ... [an ENTRY statement] may appear anywhere within a function
    subprogram after the FUNCTION statement or within a subroutine
    subprogram after the SUBROUTINE statement, ...

... but says nothing about allowing one in a main program. 

I should'a looked in the standard in the first place.  I looked in my
favorite hardware vendor's FORTRAN reference and didn't see the
exclusion.  Big suprise ... :-) Sure enough, the Sun compiler
complains about a 'misplaced entry statement'.  Too lazy to see what
my DG compiler does.  ... Just goes to show -- you can always learn
something new about FORTRAN.


-- 
----------------------------------------------------------------------
Instrument Approach Procedures Automation              DOT/FAA/AMI-230
----------------------------------------------------------------------
Bryan D. Oakley                    ctrbdo%iapa@mailhost.ecn.uoknor.edu
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: a question on ATAN function
Organization: Los Alamos National Laboratory
Date: Tue, 24 Nov 1992 00:35:07 GMT

In article <dedmunds.722548228@sfu.ca>, dedmunds@selkirk.sfu.ca (Darran Edmundson) writes:
|> I'd like to pose a neophyte question on using the arctan function to
|> calculate the phase angle of a complex variable (i.e. \theta = atan(v/u)
|> where u and v are the real and complex parts of my imaginary number
|> respectively).  Is it sufficient to test for u=0 (i.e. \theta = \pm \pi)
|> to avoid problems?  What happens if the ratio exceeds range allowed
|> for doubles or reals?  How do you avoid this problem?
|> 
|> (Now that I think about it, is it better to use arcsin or arccos?)

What you should use is ATAN2(AIMAG(Z), REAL(Z)).  You needn't even
test for the real part being zero.  If the second argument is zero
and the first argument is not, the answer will have absolute value
equal to PI/2 (the sign depending on the sign of the imaginary
part of Z).  In fact, this function should work for any pair of
floating point numbers provided they aren't *both* zero and neither
is out of range.

-- 
J. Giles
From: pmontgom@math.orst.edu (Peter Montgomery)
Newsgroups: comp.lang.fortran
Subject: Re: How does one return a logical value...???
Date: 22 Nov 92 00:04:39 GMT
Organization: Oregon State University Math Department
NNTP-Posting-Host: lab12.math.orst.edu

In article <1992Nov20.210324.3906@draco.macsch.com>
dnl@convex.is.macsch.com (David Lombard) writes:

>The following statement is fairly clear:

>	IF( A.EQ.B .EQV. C.EQ.D ) ...

>What would you do with this phantom?

>	IF( A.EQ.B .EQ. C.EQ.D ) ...


	There is no ambiguity if A, B, C, D are all type logical,
since logical equality is an associative operation
(A .EQV. (B .EQV. C))  is equivalent to  ((A .EQV. B) .EQV. C).
If the operands are numeric, they can be paired off starting from the left.



-- 
        Peter L. Montgomery              Internet: pmontgom@math.orst.edu
        Dept. of Mathematics, Oregon State Univ, Corvallis, OR 97331-4605 USA
From: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Multiple returns (was: Jumping from nested subs to main directly)
Date: 23 Nov 92 11:08:26
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
NNTP-Posting-Host: apple-gunkies.gnu.ai.mit.edu
In-reply-to: jchauvin@netcom.com's message of Mon, 23 Nov 1992 02:10:53 GMT

In article <1992Nov23.021053.11218@netcom.com> jchauvin@netcom.com (John H. Chauvin) writes:

   PROGRAM EXAMPLE
   CALL SUB1
   .
   .
   .
   STOP
   END
   SUB1
   CALL SUB2
   A=A+1
   END
   SUB2
   CALL SUB3
   END
   SUB3

   EXIT 2 (Returned to statement A=A+1 in one call)

   END

Why won't RETURN work?  It'll return to the END in SUB2, which'll return
to A=A+1 in SUB1.

Now, if you meant to imply that SUB2's call to SUB3 might be followed by
other stuff you don't want to happen...try this:

   PROGRAM EXAMPLE
   CALL SUB1
   .
   .
   .
   STOP
   END
   SUBROUTINE SUB1
   CALL SUB2
   A=A+1
   END
   SUBROUTINE SUB2
   CALL SUB3(*99)
   ...other stuff I don't want to happen if SUB3 wants to "jump" back to SUB1
99 END
   SUBROUTINE SUB3(*)

   RETURN 1  (Return to statement label passed for first "*" in arglist)

   END

I hope this helps.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF) lpf@uunet.uu.net
Newsgroups: comp.lang.fortran
From: glenn@ug.cs.dal.ca (Glenn McCarville)
Subject: 3d to 2d mapping
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Distribution: na
Date: Wed, 18 Nov 1992 22:19:40 GMT

I want to take a 3 dimensional array and map it onto a 2d array.
i.e. Set B(i,j)=A(x,i,j) for all i,j and x is some constant. Can this
be done easily? 

The purpose of this is to hopefully allow blas routines to work on 3d
arrays. Any ideas would be greatly appreciated.

Email responses to glenn@cs.dal.ca
Thanks
Glenn McCarville

-- 
glenn@cs.dal.ca
glenn@ug.cs.dal.ca
01glenn@ac.dal.ca
Newsgroups: comp.lang.fortran
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: How does one return a logical value...???
Organization: College of Marine Studies, U. Del.
Date: Wed, 18 Nov 1992 14:18:49 GMT

In article <BxwrJC.GME@cs.uiuc.edu> ctaylor@cs.uiuc.edu (Conrad W Taylor) writes:
>         I have written a function which returns a logical
>value, CheckActivity(previous, ROWS, COLS), previous is an
>array.  I'm using it like this:
>
>        IF (CheckActivity(previous, ROWS, COLS) .EQ.  .TRUE.) THEN
>          uncontrol = uncontrol + 1
>        ENDIF
>
>My compiler says that I have mixed types when I use .TRUE. 

This is a very common mistake.  The FORTRAN-77 standard only allows
numeric and string operands for the .EQ. operator.   You must use
the .EQV. operator for logical operands.   

Of course, there is no need for an operator at all here, since you can
just omit the predicate and use:

	IF (CheckActivity(previous, ROWS, COLS)) THEN
	    uncontrol = uncontrol + 1
	ENDIF


The use of .EQ. for logical operands is a fairly common extension.
Sun and Silicon Graphics allow it.  IBM (xlf) disallows it with a
surprisingly clear error message.  Cray (cft77) disallows it with
a rather obscure error message.


P.S. Conrad, you should get your news posting software fixed!
Your e-mail address ctaylor@cs.uiuc.edu is not recognized by
cs.uiuc.edu.
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
From: v087mxgb@ubvmsb.cc.buffalo.edu (Shawn E Thompson)
Newsgroups: comp.lang.fortran
Subject: easy character printing on one line (no CR/LF)
Date: 17 Nov 92 13:42:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41


I use this regularly....

200 format('+',3x,f6.7,i3,...etc)



the '+' character tells the output device to suppress
the line feed (but *NOT* the carriage return)

to you will have to vary the spacing if you don't
want to overwrite the previous output string





regards


                             Shawn E. Thompson           
_______________________________________________________________________________
v087mxgb@ubvms.cc.buffalo.edu         |    Senior Engineer & Project Manager
set@autarch.acsu.buffalo.edu          |    Research & Development Department
SUNY @ Buffalo                        |    Optical Products Division       
Grad School of Mechanical Engineering |    Leica, Incorporated
-------------------------------------------------------------------------------
"These days the buck stops nowhere.....no-one takes the blame"    -- Don Henley
Newsgroups: comp.lang.fortran
From: plugge@faxcsl.dcrt.nih.gov
Subject: FORTRAN character strings
Reply-To: plugge@faxcsl.dcrt.nih.gov
Organization: Computer Systems Laboratory, DCRT, NIH
Date: Wed, 18 Nov 1992 15:57:53 GMT

	How gross is the following STRING structure.  I'd like to
	develop some string functions are a structure.  Should I 
	stick with ASCIZ or a character string and length format
	instead of the following -

	Integer		Charlength
	Parameter	(CharLength=132)

	Structure	/String_Type/

	  Union
	    Map
	      Character*(CharLength)	Char
	    End Map
	    Map
	      Byte			Byte(CharLength)
	    End Map
	  End Union
	  Integer			Length

	End Structure


                                Thanks for the input,
				Don
Newsgroups: comp.lang.fortran
From: metcalf@apofort.cern.ch (Michael Metcalf )
Subject: Re: Fortran 90 Examples
Organization: CERN European Lab for Particle Physics
Date: Thu, 19 Nov 1992 07:46:19 GMT

As mentioned in a posting 2 weeks ago, an extended example is now available	
using ftp as follows:

ftp to jkr.cc.rl.ac.uk using anonymous as userid and your name as password.

The directory is /pub/MandR and the file name is appxg.f90. I hope this
helps - the example contains almost everything the enquirer wanted. 

                              Mike Metcalf
                              (metcalf@cernvm.cern.ch)
Newsgroups: comp.lang.fortran
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: Logical operators and operands
Organization: MacNeal-Schwendler Corp.
Date: Fri, 20 Nov 92 20:58:01 GMT

In article <30502@nntp_server.ems.cdc.com> mstemper@ems.cdc.com writes:
>
>#pragma opinions ON
>
>This seems dumb! Why shouldn't the operators for equality and
>inequality be the same, no matter what type of operands are
>used? It seems to me that this is poor language design. Can
>somebody come up with a plausible excuse for this? Is it:
> a) Tradition
> b) History
> c) Easier to optimize compilers
> d) Grandfathered in
>
>#pragma opinions OFF
>

The *problem* with a comparison such as ( _logical_var_ .eq. .TRUE. )
is that you're obfuscating the meaning of the test.  For example,
would you write ( 1.eq.1 )?  Remember, a logical var _already_ has
a value of .TRUE. or .FALSE., an expression such as A.EQ.B is
creating a logical value (i.e., .TRUE. or .FALSE.).  Don't these
comparisons look a little bizarre to you?

	IF( LOGVAR.EQ..TRUE. ) ...
	IF( LOGVAR.NE..TRUE. ) ...
	IF( LOGVAR.EQ..FALSE. ) ...
	IF( LOGVAR.NE..FALSE. ) ...
	IF( .NOT.LOGVAR.EQ..TRUE. ) ...
	IF( .NOT.LOGVAR.NE..TRUE. ) ...
	IF( .NOT.LOGVAR.EQ..FALSE. ) ...
	IF( .NOT.LOGVAR.NE..FALSE. ) ...
	IF( LOGVAR.EQ..NOT..TRUE. ) ...
	IF( LOGVAR.NE..NOT..TRUE. ) ...
	IF( LOGVAR.EQ..NOT..FALSE. ) ...
	IF( LOGVAR.NE..NOT..FALSE. ) ...
	IF( .NOT.LOGVAR.EQ..NOT..TRUE. ) ...
	IF( .NOT.LOGVAR.NE..NOT..TRUE. ) ...
	IF( .NOT.LOGVAR.EQ..NOT..FALSE. ) ...
	IF( .NOT.LOGVAR.NE..NOT..FALSE. ) ...

Aren't the following just a tad cleaner?

	IF( LOGVAR ) ...
	IF( .NOT.LOGVAR ) ...

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES;

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.lang.fortran