public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: gcc array size limitation problem
@ 2004-06-16 23:45 lrtaylor
  0 siblings, 0 replies; 2+ messages in thread
From: lrtaylor @ 2004-06-16 23:45 UTC (permalink / raw)
  To: fdeng, gcc-help

You have to remember that integers are four bytes long, so you're
actually trying to allocate an array of 4 * 2^29 bytes = 2,147,483,648
bytes.  Note that this is one more than the theoretical maximum of 2^31
- 1 = 2,147,483,647.  So, this does not appear to be a bug in the
compiler, but probably expected behavior on a 32 bit machine.

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of fdeng
Sent: Wednesday, June 16, 2004 5:47 PM
To: gcc-help@gcc.gnu.org
Cc: fdeng@ualberta.ca
Subject: gcc array size limitation problem

Hi all,

I used malloc() to create a large array. 
When array size m=2^28, no problem, 
but when m=2^29, it failed and malloc() returned NULL.

My code is as follows:
B = (unsigned int *)malloc(m*sizeof(unsigned int));

I used gcc 3.2.2 and then tried gcc 3.4.0, all failed.
I searched the archive and found a similar problem of g77 
and its answer. However, it seems not for gcc.

Any ideas? Thanks a lot,

Fan

The similar mail I found is attached below:
/********************************************** 
ignat wrote:

> Using g77 (GNU project Fortran Compiler, v0.5.24) I have encountered a
> problem of array size limitation.
> I found out that size of an array is limited to 2^27 -1 = 134 217 728,
> while integer itself can be 2^31 -1 = 2 147 483 647.
> I actually need an array with 600 000 000 numbers. What can I do?

I fixed this for the 3.1 release, basically by removing a check that I
proved unnecessarily strict.

So you could try out a recent snapshot of gcc/g77 (see our home page at
http://gcc.gnu.org, entry "Snapshots" in the left column).  However, one
shouldn't use snapshot compilers for production work.

Another option is to apply the following patch to a recent release (see
entry "Releases" in the left column) and build that compiler.

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

2001-10-22  Toon Moene  <toon@moene.indiv.nluug.nl>

	* com.c (ffecom_check_size_overflow_): Only check for
TREE_OVERFLOW.

*** com.c.orig	Fri Oct 19 14:59:44 2001
--- com.c	Sun Oct 21 14:17:15 2001
*************** ffecom_check_size_overflow_ (ffesymbol s
*** 2267,2272 ****

    if ((tree_int_cst_sgn (TYPE_SIZE (type)) < 0)
!       || (!dummy && (((TREE_INT_CST_HIGH (TYPE_SIZE (type)) != 0))
! 		     || TREE_OVERFLOW (TYPE_SIZE (type)))))
      {
        ffebad_start (FFEBAD_ARRAY_LARGE);
--- 2267,2271 ----

    if ((tree_int_cst_sgn (TYPE_SIZE (type)) < 0)
!       || (!dummy && TREE_OVERFLOW (TYPE_SIZE (type))))
      {
        ffebad_start (FFEBAD_ARRAY_LARGE);

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

* gcc array size limitation problem
@ 2004-06-16 23:38 fdeng
  0 siblings, 0 replies; 2+ messages in thread
From: fdeng @ 2004-06-16 23:38 UTC (permalink / raw)
  To: gcc-help; +Cc: fdeng

Hi all,

I used malloc() to create a large array. 
When array size m=2^28, no problem, 
but when m=2^29, it failed and malloc() returned NULL.

My code is as follows:
B = (unsigned int *)malloc(m*sizeof(unsigned int));

I used gcc 3.2.2 and then tried gcc 3.4.0, all failed.
I searched the archive and found a similar problem of g77 
and its answer. However, it seems not for gcc.

Any ideas? Thanks a lot,

Fan

The similar mail I found is attached below:
/********************************************** 
ignat wrote:

> Using g77 (GNU project Fortran Compiler, v0.5.24) I have encountered a
> problem of array size limitation.
> I found out that size of an array is limited to 2^27 -1 = 134 217 728,
> while integer itself can be 2^31 -1 = 2 147 483 647.
> I actually need an array with 600 000 000 numbers. What can I do?

I fixed this for the 3.1 release, basically by removing a check that I
proved unnecessarily strict.

So you could try out a recent snapshot of gcc/g77 (see our home page at
http://gcc.gnu.org, entry "Snapshots" in the left column).  However, one
shouldn't use snapshot compilers for production work.

Another option is to apply the following patch to a recent release (see
entry "Releases" in the left column) and build that compiler.

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

2001-10-22  Toon Moene  <toon@moene.indiv.nluug.nl>

	* com.c (ffecom_check_size_overflow_): Only check for TREE_OVERFLOW.

*** com.c.orig	Fri Oct 19 14:59:44 2001
--- com.c	Sun Oct 21 14:17:15 2001
*************** ffecom_check_size_overflow_ (ffesymbol s
*** 2267,2272 ****

    if ((tree_int_cst_sgn (TYPE_SIZE (type)) < 0)
!       || (!dummy && (((TREE_INT_CST_HIGH (TYPE_SIZE (type)) != 0))
! 		     || TREE_OVERFLOW (TYPE_SIZE (type)))))
      {
        ffebad_start (FFEBAD_ARRAY_LARGE);
--- 2267,2271 ----

    if ((tree_int_cst_sgn (TYPE_SIZE (type)) < 0)
!       || (!dummy && TREE_OVERFLOW (TYPE_SIZE (type))))
      {
        ffebad_start (FFEBAD_ARRAY_LARGE);

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

end of thread, other threads:[~2004-06-16 23:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-16 23:45 gcc array size limitation problem lrtaylor
  -- strict thread matches above, loose matches on Subject: below --
2004-06-16 23:38 fdeng

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