home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp / 14659 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  2.9 KB
  1. From: bobm@hpfcso.FC.HP.COM (Bob Montgomery)
  2. Date: Fri, 8 Jan 1993 19:14:12 GMT
  3. Subject: Re: Huge executables from f77 on 750's
  4. Message-ID: <7371523@hpfcso.FC.HP.COM>
  5. Organization: Hewlett-Packard, Fort Collins, CO, USA
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpfcso!bobm
  7. Newsgroups: comp.sys.hp
  8. References: <1993Jan8.143012.13078@informatik.uni-wuerzburg.de>
  9. Lines: 69
  10.  
  11. In comp.sys.hp, lemc002@winx03.informatik.uni-wuerzburg.de 
  12. (Franco Trani) writes:
  13.  
  14. > I've a problem with f77 (what /usr/bin/f77: HPUX Fortran/ 9000s700
  15. > 09/19/91 B2408 A08.07). Some code I compile on a 9000s433 gives an
  16. > executable of 336 KB. The same code compiled with the same comp-
  17. > iler options results in a 29 MB monster on the 750 (it can be com-
  18. > pressed to a size of ~ 400 KB !).
  19.  
  20.    At 8.07, there are (at least) two causes of unexpectedly large
  21. FORTRAN executable size.
  22.  
  23.    They occur when using the -K compiler option or when using SAVE.  If
  24. a subroutine with large non-common arrays is compiled -K, *and* that
  25. subroutine also contains a string literal or a DATA statement, then the
  26. large arrays will be placed in the initialized data area (and will
  27. consequently take up space in your executable file).
  28.  
  29. Example 1:
  30.  
  31. C  This program illustrates the case with a large local array and
  32. C  a string literal (check the effect of -K)
  33.  
  34.     program main
  35.     integer a(100000)
  36.     print *, 'hello', a(1), a(100000)
  37.     end
  38.  
  39. Example 2:
  40.  
  41. C  This program illustrates the case with a large array and
  42. C  a data statement (check the effect of -K)
  43.  
  44.     program main
  45.     integer a(100000)
  46.     data ii/1000/
  47.     print *,  ii, a(1), a(100000)
  48.     end
  49.  
  50. Compiled without -K on 8.07 (or before), the executable files are 16384
  51. bytes each.  Compiled with -K, they are 413696 bytes each, because the
  52. files now contain the a(100000) array as an image of 100000 integer
  53. zeros.  This behavior (putting uninitialized saved arrays in the
  54. initialized data area when the routine contains other initialized data)
  55. is considered to be a bug, and is fixed in the HP-UX 9.0 release for the
  56. Series 700.
  57.  
  58. Besides -K, you can also get this behavior by using "SAVE" in your
  59. source files.  This is also fixed in 9.0.
  60.  
  61. If you must use -K or SAVE at 8.07, one workaround (as mentioned
  62. previously, (thanks, Gordon)) is to place the local arrays in a named
  63. common block instead.  As long as nothing in that common block is
  64. initialized by a DATA statement, that common block will be placed in
  65. uninitialized data, and will not consume space in the executable file.
  66. Another workaround is to SAVE only those local variables that must
  67. retain their values (hopefully not the large array), and then not use -K
  68. or the global SAVE statement.
  69.  
  70. And you could always just wait for the 9.0 release (shipping Real Soon if
  71. not Right Now).
  72.  
  73. > The object-files are still 
  74. > small, the problem seems to be the linker.
  75.  
  76. Try looking at the object files with size(1).  If the second number
  77. (initialized data size) is large, you found the file of interest.
  78.  
  79. Bob Montgomery, HP
  80.