public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/31244]  New: data initialization with more than 2**32 elements
@ 2007-03-17 15:00 tkoenig at gcc dot gnu dot org
  2007-04-18  5:57 ` [Bug fortran/31244] " fxcoudert at gcc dot gnu dot org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-03-17 15:00 UTC (permalink / raw)
  To: gcc-bugs

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


-- 
           Summary: data initialization with more than 2**32 elements
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tkoenig at gcc dot gnu dot org


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
@ 2007-04-18  5:57 ` fxcoudert at gcc dot gnu dot org
  2007-09-18 17:56 ` kargl at gcc dot gnu dot org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-04-18  5:57 UTC (permalink / raw)
  To: gcc-bugs



-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-04-18 06:56:55
               date|                            |


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
  2007-04-18  5:57 ` [Bug fortran/31244] " fxcoudert at gcc dot gnu dot org
@ 2007-09-18 17:56 ` kargl at gcc dot gnu dot org
  2007-09-18 18:02 ` sgk at troutmask dot apl dot washington dot edu
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-09-18 17:56 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from kargl at gcc dot gnu dot org  2007-09-18 17:56 -------
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.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
  2007-04-18  5:57 ` [Bug fortran/31244] " fxcoudert at gcc dot gnu dot org
  2007-09-18 17:56 ` kargl at gcc dot gnu dot org
@ 2007-09-18 18:02 ` sgk at troutmask dot apl dot washington dot edu
  2007-09-18 19:16 ` sgk at troutmask dot apl dot washington dot edu
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2007-09-18 18:02 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from sgk at troutmask dot apl dot washington dot edu  2007-09-18 18:02 -------
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.


-- 


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (2 preceding siblings ...)
  2007-09-18 18:02 ` sgk at troutmask dot apl dot washington dot edu
@ 2007-09-18 19:16 ` sgk at troutmask dot apl dot washington dot edu
  2007-09-18 19:26 ` sgk at troutmask dot apl dot washington dot edu
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2007-09-18 19:16 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from sgk at troutmask dot apl dot washington dot edu  2007-09-18 19:16 -------
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?


-- 


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (3 preceding siblings ...)
  2007-09-18 19:16 ` sgk at troutmask dot apl dot washington dot edu
@ 2007-09-18 19:26 ` sgk at troutmask dot apl dot washington dot edu
  2007-09-18 20:08 ` sgk at troutmask dot apl dot washington dot edu
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2007-09-18 19:26 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from sgk at troutmask dot apl dot washington dot edu  2007-09-18 19:26 -------
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.


-- 


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (4 preceding siblings ...)
  2007-09-18 19:26 ` sgk at troutmask dot apl dot washington dot edu
@ 2007-09-18 20:08 ` sgk at troutmask dot apl dot washington dot edu
  2007-09-19 18:48 ` kargl at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2007-09-18 20:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from sgk at troutmask dot apl dot washington dot edu  2007-09-18 20:07 -------
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


-- 


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (5 preceding siblings ...)
  2007-09-18 20:08 ` sgk at troutmask dot apl dot washington dot edu
@ 2007-09-19 18:48 ` kargl at gcc dot gnu dot org
  2007-10-22 22:11 ` kargl at gcc dot gnu dot org
  2007-10-22 22:34 ` kargl at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-09-19 18:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from kargl at gcc dot gnu dot org  2007-09-19 18:48 -------
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.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-04-18 06:56:55         |2007-09-19 18:48:35
               date|                            |


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (6 preceding siblings ...)
  2007-09-19 18:48 ` kargl at gcc dot gnu dot org
@ 2007-10-22 22:11 ` kargl at gcc dot gnu dot org
  2007-10-22 22:34 ` kargl at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-10-22 22:11 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from kargl at gcc dot gnu dot org  2007-10-22 22:10 -------
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


-- 


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


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

* [Bug fortran/31244] data initialization with more than 2**32 elements
  2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
                   ` (7 preceding siblings ...)
  2007-10-22 22:11 ` kargl at gcc dot gnu dot org
@ 2007-10-22 22:34 ` kargl at gcc dot gnu dot org
  8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-10-22 22:34 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from kargl at gcc dot gnu dot org  2007-10-22 22:33 -------
Fixed on trunk.

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


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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


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

end of thread, other threads:[~2007-10-22 22:34 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-17 15:00 [Bug fortran/31244] New: data initialization with more than 2**32 elements tkoenig at gcc dot gnu dot org
2007-04-18  5:57 ` [Bug fortran/31244] " fxcoudert at gcc dot gnu dot org
2007-09-18 17:56 ` kargl at gcc dot gnu dot org
2007-09-18 18:02 ` sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:16 ` sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:26 ` sgk at troutmask dot apl dot washington dot edu
2007-09-18 20:08 ` sgk at troutmask dot apl dot washington dot edu
2007-09-19 18:48 ` kargl at gcc dot gnu dot org
2007-10-22 22:11 ` kargl at gcc dot gnu dot org
2007-10-22 22:34 ` kargl at gcc dot gnu dot org

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