Bug 31244 - data initialization with more than 2**32 elements
Summary: data initialization with more than 2**32 elements
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: kargls
URL:
Keywords: rejects-valid
Depends on:
Blocks: 31392 33056
  Show dependency treegraph
 
Reported: 2007-03-17 15:00 UTC by Thomas Koenig
Modified: 2007-10-22 22:33 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-09-19 18:48:35


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2007-03-17 15:00:32 UTC
$ cat data.f90
program main
  integer(kind=1), dimension(4294967296_8) :: i
  data i /4294967296_8 * 1_1/
  print *,i(1)
end program main
$ gfortran data.f90
data.f90:3.24:

  data i /4294967296_8 * 1_1/
                       1
Error: Integer value too large in expression at (1)

This is probably due to the use of gfc_match_int() in
top_val_list.
Comment 1 kargls 2007-09-18 17:56:35 UTC
confirmed.

The problem is found in decl.c(top_val_list) at lines 404-411, which
are 

	  signed int tmp;
	  msg = gfc_extract_int (expr, &tmp);
	  gfc_free_expr (expr);
	  if (msg != NULL)
	    {
	      gfc_error (msg);
	      return MATCH_ERROR;
	    }

gfc_extract_int is trying to put 4294967296_8 into a signed int.
This probably needs to be changed to accommodate the type of
an array index.
Comment 2 Steve Kargl 2007-09-18 18:02:03 UTC
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 05:56:36PM -0000, kargl at gcc dot gnu dot org wrote:
> 
> The problem is found in decl.c(top_val_list) at lines 404-411, which
> are 
> 
>           signed int tmp;
>           msg = gfc_extract_int (expr, &tmp);
>           gfc_free_expr (expr);
>           if (msg != NULL)
>             {
>               gfc_error (msg);
>               return MATCH_ERROR;
>             }
> 
> gfc_extract_int is trying to put 4294967296_8 into a signed int.
> This probably needs to be changed to accommodate the type of
> an array index.

For completeness, the line 412 is 'tail->repeat = tmp'
where tail->repeat is an unsigned int.

Comment 3 Steve Kargl 2007-09-18 19:16:42 UTC
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 06:02:03PM -0000, sgk at troutmask dot apl dot washington dot edu wrote:
> > 
> > The problem is found in decl.c(top_val_list) at lines 404-411, which
> > are 
> > 
> >           signed int tmp;
> >           msg = gfc_extract_int (expr, &tmp);
> >           gfc_free_expr (expr);
> >           if (msg != NULL)
> >             {
> >               gfc_error (msg);
> >               return MATCH_ERROR;
> >             }
> > 
> > gfc_extract_int is trying to put 4294967296_8 into a signed int.
> > This probably needs to be changed to accommodate the type of
> > an array index.
> 

Ugh.  I have a patch that would allow a repeat count of
2**32-1.  For this program:

  program main
  integer(kind=1), dimension(4294967294_8) :: i
  data i /4294967294_8 * 1_1/
  print *,i(1)
  end program main

and 'gfc4x -o z -O p.f90', I see 

51879 sgk           1 121    0   554M   554M RUN    1   5:48 92.24% as

in top(1).  Do we really want to support this large of a repeat count?



Comment 4 Steve Kargl 2007-09-18 19:26:22 UTC
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 07:16:42PM -0000, sgk at troutmask dot apl dot washington dot edu wrote:
> 
> Ugh.  I have a patch that would allow a repeat count of
> 2**32-1.  For this program:
> 
>   program main
>   integer(kind=1), dimension(4294967294_8) :: i
>   data i /4294967294_8 * 1_1/
>   print *,i(1)
>   end program main
> 
> and 'gfc4x -o z -O p.f90', I see 
> 
> 51879 sgk           1 121    0   554M   554M RUN    1   5:48 92.24% as
> 
> in top(1).  Do we really want to support this large of a repeat count?
> 

Ugh**2.

If I'm not mistaken, this will create an executable with
4 GB of static data in it.  I think we should but a sane
limit on the value.  Btw,  I'm sitting at

51879 sgk           1 122    0  1302M  1304M CPU1   1  14:17 93.41% as
51878 sgk           1  -8    0 17684K 12924K pipewr 0   7:58 48.78% f951

in top(1).  So, it memory grows to rough 4GB, then it will take
about an hour to compile this program.

Comment 5 Steve Kargl 2007-09-18 20:07:58 UTC
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 07:26:22PM -0000, sgk at troutmask dot apl dot washington dot edu wrote:
> 
> If I'm not mistaken, this will create an executable with
> 4 GB of static data in it.  I think we should but a sane
> limit on the value.  Btw,  I'm sitting at
> 
> 51879 sgk           1 122    0  1302M  1304M CPU1   1  14:17 93.41% as
> 51878 sgk           1  -8    0 17684K 12924K pipewr 0   7:58 48.78% f951
> 
> in top(1).  So, it memory grows to rough 4GB, then it will take
> about an hour to compile this program.
> 

:)

Mem: 5365M Active, 1779M Inact, 222M Wired, 341M Cache, 214M Buf, 10M Free
Swap: 17G Total, 17G Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
51879 sgk           1 117    0  4254M  4261M CPU1   1  53:25 96.53% as
51878 sgk           1 104    0 17684K 12860K RUN    1  26:01 39.45% f951

troutmask:sgk[312] gfc4x -o z -pipe -O p.f90

/tmp: write failed, filesystem is full
/tmp/ccdu52FQ.o: No space left on device
{standard input}: Assembler messages:
{standard input}:87: FATAL: Can't write /tmp/ccdu52FQ.o: No space left on device



Comment 6 kargls 2007-09-19 18:48:35 UTC
I have a patch that in theory allows the repeat count
to be unlimited.  I'll note that having a large repeat
count is a rather illogical thing to do, based on my
previous posts about compile time and size of executable.
Comment 7 kargls 2007-10-22 22:10:56 UTC
Subject: Bug 31244

Author: kargl
Date: Mon Oct 22 22:10:42 2007
New Revision: 129561

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129561
Log:
2007-10-22  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/31244
        * gfortran.h (gfc_data_value): Change repeat from unsigned int
        to mpz_t.
        * decl.c(top_val_list): Remove msg variable.  Use mpz_t for
        repeat count.
        * resolve.c (values):  Change left from unsigned int to mpz_t.
        (next_data_value): Change for mpz_t.
        (check_data_variable): Change ??? to FIXME in a comment.  Use
        "mpz_t left".
        (resolve_data ): Use "mpz_t left".


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/resolve.c

Comment 8 kargls 2007-10-22 22:33:41 UTC
Fixed on trunk.

Note, this patch does not fix the enormous compile times needed
on code with such outlandish data statements.