[Bug c/56344] New: ICE for program with larger automatic structs

[Bug c/56344] New: ICE for program with larger automatic structs

[georggcc at googlemail dot com]

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

             Bug #: 56344
           Summary: ICE for program with larger automatic structs
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: georggcc@googlemail.com


Created attachment 29467
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29467
artificial test program, COLS set suitably

The program attached makes the compiler fail with ICE or otherwise misbehave in
a few ways. The behavior depends at least on the value of COLS and optimization
being on (-O2) or off. The program's arrays would be huge, but the compiler's
behavior does not vary "monotonically" with the value defined for COLS.

At 24000L, I get, with or without -O2,

Compilation started at Fri Feb 15 14:45:59

gcc -std=c99 -pedantic  -W -c big.c
big.c: In function 'main':
big.c:36:10: internal compiler error: Segmentation fault: 11
   result = mulm(m1, m2);
          ^

big.c:36:10: internal compiler error: Abort trap: 6
gcc: internal compiler error: Abort trap: 6 (program cc1)

Compilation abort trap: 6 at Fri Feb 15 14:46:02

At 22000L (i.e., smaller), or 100000L (i.e., larger), the
compiler's memory consumption stays at ~14MB and ~80MB of
physical and virtual memory, resp; kernel_task and cc1
seem busy, but nothing happens for several minutes.

At 20000L, and with -O2, I get

Compilation started at Fri Feb 15 15:37:28

gcc -pedantic  -W -c -O2 big.c
In file included from big.c:1:0:

gcc: internal compiler error: Abort trap: 6 (program cc1)

Compilation abort trap: 6 at Fri Feb 15 15:37:28

Dropping -O2 results in the same apparent behavior as
for 22000L and 100000L.

With some other sizes, like 15000L, cc1 uses around
1.6 GB and 3.0 GB of physical and virtual memory,
respectively, and occasionally some CPU; after 5 min(!),
and not too much VM swapping,

Compilation started at Fri Feb 15 15:41:03

gcc -pedantic  -W -c big.c

Compilation finished at Fri Feb 15 15:46:11

(What is the compiler doing with all this memory?)

At 150000L, the compiler finishes in no time and everything
is fine, with or without -O2. (Of course, the resulting program
will not run without segfault.) I noticed that in these large
value of COLS, manipulation of %rsp changes, from

  subq    $0x35a4e928,%rsp    ; COLS 15000L

in _mulm, to

  movq    $0xffffffeb0b94fbe0,%r11  ; COLS 150000L
  addq    %r11,%rsp

(As an aside, a gcc-avr in a different environment says this:
error: size of array 'data' is too large.)

(I notices #46119 but don't know whether it is related.)

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/bauhaus/mine/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: /Users/bauhaus/src/gcc/configure --prefix=/Users/bauhaus/mine
--disable-nls --disable-multilib --disable-libstdcxx-pch
--enable-languages=c,ada,c++ CC=gcc
Thread model: posix
gcc version 4.8.0 20130212 (experimental) [trunk revision 195968] (GCC) 

4 GiB of physical RAM.

[Bug c/56344] ICE for program with larger automatic structs

[georggcc at googlemail dot com]

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

Georg <georggcc at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29467|0                           |1
        is obsolete|                            |

--- Comment #1 from Georg <georggcc at googlemail dot com> 2013-02-15 15:15:39 UTC ---
Created attachment 29468
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29468
same artificial test program, hopefully text/plain

Try circumventing browser's, or OS's, or Bugzilla's autodetection of file
type...

[Bug middle-end/56344] ICE for program with very large structs returned by value

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-18
            Summary|ICE for program with larger |ICE for program with very
                   |automatic structs           |large structs returned by
                   |                            |value
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-18 11:09:32 UTC ---
Confirmed.  Returning a struct of size > 2^31 by value ICEs like the following:

t.c: In function 'main':
t.c:34:10: internal compiler error: Segmentation fault
   result = mulm(m1, m2);
          ^
0xad765d crash_signal
        /space/rguenther/src/svn/trunk/gcc/toplev.c:332
0x6d405b store_one_arg
        /space/rguenther/src/svn/trunk/gcc/calls.c:4707
0x6ceba4 expand_call(tree_node*, rtx_def*, int)
        /space/rguenther/src/svn/trunk/gcc/calls.c:3042
0x7f3634 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
        /space/rguenther/src/svn/trunk/gcc/expr.c:10207

Program received signal SIGSEGV, Segmentation fault.
0x000000000065b81f in store_one_arg (arg=0x7fffffffaf20, 
    argblock=0x7ffff5ac2560, flags=0, variable_size=0, reg_parm_stack_space=0)
    at /space/rguenther/src/svn/gcc-4_7-branch/gcc/calls.c:4675
4675          stack_usage_map[i] = 1;
(gdb) p i
$1 = -1990967296

my advice: don't do it ;) (it won't work at runtime anyway)

I think the middle-end should sorry (), the frontends eventually warn
(or reject if possible).

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-22 14:28:02 UTC ---
Richi, for the middle-end part, do you mean something like this?  I've used
error () instead of sorry (), but of course I can change that back.

--- gcc/calls.c.mp    2013-02-22 15:24:58.655086818 +0100
+++ gcc/calls.c    2013-02-22 15:25:09.737117963 +0100
@@ -3037,6 +3037,12 @@ expand_call (tree exp, rtx target, int i
         {
           rtx before_arg = get_last_insn ();

+          if (adjusted_args_size.constant >= (1 << 31))
+            {
+              error ("passing too large argument on stack");
+          break;
+        }
+
           if (store_one_arg (&args[i], argblock, flags,
                  adjusted_args_size.var != 0,
                  reg_parm_stack_space)

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-22 14:33:37 UTC ---
Or probably s/break/continue/, in that case we'd issue error () on every
ill-sized parameter.  And of course, it's completely untested.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |mpolacek at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.8.0

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-26 18:28:53 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01183.html

[Bug middle-end/56344] ICE for program with very large structs returned by value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:45:18 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.8.2

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.1 has been released.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Tue Dec  3 12:11:36 2013
New Revision: 205628

URL: http://gcc.gnu.org/viewcvs?rev=205628&root=gcc&view=rev
Log:
    PR middle-end/56344
    * calls.c (expand_call): Disallow passing huge arguments
    by value.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/calls.c

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[georggcc at googlemail dot com]

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

--- Comment #11 from Georg <georggcc at googlemail dot com> ---
(In reply to Marek Polacek from comment #10)
> Fixed.

For clarity, just asking: Does this mean that

1.  if I compile a program on HOST with bit size N,
for a TARGET with bit size M, then gcc will sorry()
just in case the object passed is larger than 1<<30,
irrespective of N and M?

2. Would this need to be documented per implementation?