public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77
@ 2013-03-16 19:46 ncc1701zzz at gmail dot com
  2013-03-17  1:24 ` [Bug fortran/56638] " kargl at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: ncc1701zzz at gmail dot com @ 2013-03-16 19:46 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638

             Bug #: 56638
           Summary: Linker uses a lot of memory in Fortran 77
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ncc1701zzz@gmail.com


Hi.

I hope this is not a repeated bug. I haven't found a similar bug.

I'm using gfortran 4.6.3 in a Raspberry Pi (ARM architecture).

When compiling a Fortran 77 file, I've noticed that in the linking process, it
uses as much RAM as declared in all the variables. The executable generated is
small and the execution doesn't uses so much RAM if the full array is not
addressed. 

I have a software that reserves a lot of RAM (because Fortran 77 doesn't
support dynamically assigned memory) but it won't address the entire range. I
cannot compile it in the Raspberry Pi, but it compiles fine in a x86 linux and
in Cygwin.

Example program:

      PROGRAM BUG
      IMPLICIT NONE

      INTEGER LARGE(100000000)
      LARGE(1)=1

      END


Compile the object, this works fine:
gfortran -c program.f

Generate the executable. This uses over 400 MB of RAM (100.000.000 elements of
4 bytes):
gfortran -o program program.f

If you increase the length of the array LARGE in the code, it will use more and
more RAM.

Full output of the compiler version:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6
--with-fpu=vfp --with-float=hard --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)



Is this considered a bug? 

Thanks!
Best regards.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56638] Linker uses a lot of memory in Fortran 77
  2013-03-16 19:46 [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77 ncc1701zzz at gmail dot com
@ 2013-03-17  1:24 ` kargl at gcc dot gnu.org
  2013-03-17  9:11 ` ncc1701zzz at gmail dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: kargl at gcc dot gnu.org @ 2013-03-17  1:24 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #1 from kargl at gcc dot gnu.org 2013-03-17 01:24:10 UTC ---
(In reply to comment #0)

> I have a software that reserves a lot of RAM (because Fortran 77 doesn't
> support dynamically assigned memory) but it won't address the entire range.

gfortran is a Fortran 95 compiler.  Learn to use dynamic memory
allocation or lower expectations with regards to declaring arrays
that consume a large amount of memory.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56638] Linker uses a lot of memory in Fortran 77
  2013-03-16 19:46 [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77 ncc1701zzz at gmail dot com
  2013-03-17  1:24 ` [Bug fortran/56638] " kargl at gcc dot gnu.org
@ 2013-03-17  9:11 ` ncc1701zzz at gmail dot com
  2013-03-17  9:14 ` pinskia at gcc dot gnu.org
  2013-03-17  9:31 ` ncc1701zzz at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: ncc1701zzz at gmail dot com @ 2013-03-17  9:11 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638

--- Comment #2 from ncc1701zzz at gmail dot com 2013-03-17 09:11:03 UTC ---
I think you are completely missing the point because 1) the example program I
wrote is also F95, 2) static memory allocation is part of the language, and 3)
it works perfectly in other platforms.

Thank you anyway. 
Bye.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56638] Linker uses a lot of memory in Fortran 77
  2013-03-16 19:46 [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77 ncc1701zzz at gmail dot com
  2013-03-17  1:24 ` [Bug fortran/56638] " kargl at gcc dot gnu.org
  2013-03-17  9:11 ` ncc1701zzz at gmail dot com
@ 2013-03-17  9:14 ` pinskia at gcc dot gnu.org
  2013-03-17  9:31 ` ncc1701zzz at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-03-17  9:14 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-17 09:13:50 UTC ---
(In reply to comment #2)
> I think you are completely missing the point because 1) the example program I
> wrote is also F95, 2) static memory allocation is part of the language, and 3)
> it works perfectly in other platforms.

One extra reason why this is not a gfortran bug: the linker is not part of GCC
but rather binutils. You should report this bug to your distro first anyways. 
If you test the FSF binutils you should use the latest release and then report
it to sourceware.org/bugzilla .


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56638] Linker uses a lot of memory in Fortran 77
  2013-03-16 19:46 [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77 ncc1701zzz at gmail dot com
                   ` (2 preceding siblings ...)
  2013-03-17  9:14 ` pinskia at gcc dot gnu.org
@ 2013-03-17  9:31 ` ncc1701zzz at gmail dot com
  3 siblings, 0 replies; 5+ messages in thread
From: ncc1701zzz at gmail dot com @ 2013-03-17  9:31 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56638

--- Comment #4 from ncc1701zzz at gmail dot com 2013-03-17 09:31:25 UTC ---
Dear Andrew,

Thanks for your answer.  I didn't know that the linker was not part of GCC.
I'll try to report it to the bugzilla you say.

The truth is that I personally don't need it solved. It is a software running
in a big machine and I just wanted to try some particular features in the
Raspberry. I did as kargl suggested, lowering the static arrays, and it works
fine. I wanted to report it for the sake of the community :) 

Regards.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-03-17  9:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-16 19:46 [Bug fortran/56638] New: Linker uses a lot of memory in Fortran 77 ncc1701zzz at gmail dot com
2013-03-17  1:24 ` [Bug fortran/56638] " kargl at gcc dot gnu.org
2013-03-17  9:11 ` ncc1701zzz at gmail dot com
2013-03-17  9:14 ` pinskia at gcc dot gnu.org
2013-03-17  9:31 ` ncc1701zzz at gmail dot com

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