#2195 cc1plus crash compiling method with huge struct as argument

OTHER
unread
nobody
cc1plus (2)
Bug
none
Unknown
False
2015-01-28
2014-03-12
Zaskar
No

cc1plus crashes when trying to compile a class method that receives a very big argument (a 65kb struct). I know that we are not supposed to make so big static variables, but the compiler should compile and let the resulting program crash or complaint about that instead of crashing itself. Here's the minimal code that generates the error:

    struct huge {
        char c[256][256]; 
    };
    class Bar {
        void foo(huge x);
    };
    void Bar::foo (huge x) {
    }

I've noted that there's no problem if the method is implemented inline.

And here are versions and compiler ouput

    C:\Users\usuario\Desktop>g++ --version
    g++ (GCC) 4.8.1
    Copyright (C) 2013 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    C:\Users\usuario\Desktop>ld -v
    GNU ld (GNU Binutils) 2.24

    C:\Users\usuario\Desktop>g++ -c problema_mingw.cpp
    problema_mingw.cpp: In member function 'void GestionMaquina::AgregarMaquina(Maquinas)':
    problema_mingw.cpp:11:1: internal compiler error: Segmentation fault
     }
     ^

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.

    problema_mingw.cpp:11:1: internal compiler error: Aborted

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    g++: internal compiler error: Aborted (program cc1plus)
    libbacktrace could not find executable to open
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <http://gcc.gnu.org/bugs.html> for instructions.

Tested on win7 ultimate 64bits, mingw was mannually installed, just by decompressing the following packages: binutils-2.24-1-mingw32-bin.tar.xz expat-2.1.0-1-mingw32-dll.tar gcc-c++-4.8.1-4-mingw32-bin.tar gcc-c++-4.8.1-4-mingw32-dll.tar gcc-core-4.8.1-4-mingw32-bin.tar gcc-core-4.8.1-4-mingw32-dll.tar gdb-7.6.1-1-mingw32-bin.tar gmp-5.1.2-1-mingw32-dll.tar libiconv-1.14-3-mingw32-dll.tar mingwrt-4.0.3-1-mingw32-dev.tar mingwrt-4.0.3-1-mingw32-dll.tar mpc-1.0.1-2-mingw32-dll.tar mpfr-3.1.2-2-mingw32-dll.tar w32api-4.0.3-1-mingw32-dev.tar

Discussion

  • Keith Marshall

    Keith Marshall - 2014-03-12

    FWIW, your test case compiles just fine, with the native "g++ (Debian 4.8.2-1) 4.8.2" on my Linux box; however, I can reproduce your ICE with a MinGW GCC-4.8.2, (self-built as a Linux hosted cross compiler):

    $ mingw32-g++ -E fubar.cpp
    # 1 "fubar.cpp"
    # 1 "<command-line>"
    # 1 "fubar.cpp"
    struct huge {
      char c[256][256];
    };
    class Bar {
      void foo(huge x);
    };
    void Bar::foo (huge x) {
    }
    
    $ mingw32-g++ -c fubar.cpp
    fubar.cpp: In member function 'void Bar::foo(huge)':
    fubar.cpp:8:1: internal compiler error: Segmentation fault
     }
     ^
    0x8d3b1f crash_signal
        ../../gcc-4.8.2/gcc/toplev.c:332
    0x88c551 copy_rtx(rtx_def*)
        ../../gcc-4.8.2/gcc/rtl.c:235
    0xa866fc ix86_expand_epilogue(int)
        ../../gcc-4.8.2/gcc/config/i386/i386.c:11168
    0xb0816f gen_epilogue()
        ../../gcc-4.8.2/gcc/config/i386/i386.md:11858
    0x7707e2 thread_prologue_and_epilogue_insns
        ../../gcc-4.8.2/gcc/function.c:6458
    0x7707e2 rest_of_handle_thread_prologue_and_epilogue
        ../../gcc-4.8.2/gcc/function.c:6973
    Please submit a full bug report,
    with preprocessed source if appropriate.
    Please include the complete backtrace with any bug report.
    See <http://gcc.gnu.org/bugs.html> for instructions.
    

    An ICE must always be considered to be a compiler bug; you need to refer this directly to the GCC maintainers, as instructed in the diagnostic output.

     
    • Zaskar

      Zaskar - 2014-03-13

      I've posted it here because I wasn't able to reproduce this with other gcc versions (linux), only with MinGW. But I'll send it to GCC maintainers anyway. Thanks.

       
  • Keith Marshall

    Keith Marshall - 2014-03-13

    I've posted it here because I wasn't able to reproduce this with other gcc versions (linux), only with MinGW.

    That doesn't matter. The GCC folks designate MinGW as an officially supported target; we don't develop it ourselves. The bug is in their (probably MinGW specific) support code, so it is their responsibility to fix it.

    But I'll send it to GCC maintainers anyway.

    Thanks.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks