home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / hp / 10079 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.3 KB
  1. Path: sparky!uunet!europa.asd.contel.com!emory!kd4nc!hpuercc.atl.hp.com!hpuerca.atl.hp.com!aaa
  2. From: aaa@hpuerca.atl.hp.com (Simon Fowler)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: executable sizes in fortran
  5. Message-ID: <Bu2BvF.8Aw@atl.hp.com>
  6. Date: 4 Sep 92 16:45:13 GMT
  7. References: <lee.715546990@ceg.uiuc.edu>
  8. Sender: news@atl.hp.com
  9. Organization: Hewlett-Packard Company, Atlanta GA
  10. Lines: 26
  11.  
  12. In article <lee.715546990@ceg.uiuc.edu>, lee@ceg.uiuc.edu (Chris Lee) writes:
  13. > One of our users has a question:
  14. > 
  15. > Why are the fortran executables SOOOOOO  BIIIIIIIIIIG?
  16. > It seems that "all" of the data is being allocated at
  17. > compile/link time, and he would like to know if there is a 
  18. > way to force the compiler/linker to allocate it at runtime.
  19. > 
  20. > We are running HPUX 8.07 on 9000/700s.
  21.  
  22. Typically this is caused by large (should say LARGE) arrays that are statically allocated.
  23. I usually see this when code is ported from another machine and then compiled with the -K
  24. option to force all data to static storage (instead of being put on the stack). If this is
  25. the case, you can declare the array as being in COMMON, e.g.
  26.  
  27. change
  28.  
  29.        DIMENSION BIG(1000000)
  30. to
  31.  
  32.        DIMENSION BIG(1000000)
  33.        COMMON /BIGCOM/BIG
  34.  
  35. and don't compile with -K. You'll have to figure out which modules you can use this on.
  36.  
  37. simon
  38.