| Summary: | [C++0x] Compiler abort silently | ||
|---|---|---|---|
| Product: | gcc | Reporter: | sscrisk |
| Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jason, kikairoya |
| Priority: | P3 | ||
| Version: | 4.6.0 | ||
| Target Milestone: | 4.6.1 | ||
| Host: | Target: | i686-pc-mingw32 | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
As a matter of fact, with the released 4.6.0 I'm getting an ICE, not a silent miscompilation for the second snippet. In mainline and in the 4_6-branch it's already correctly rejected with something like: ... ... 48912_2.C:3:11: in constexpr expansion of ‘f()’ 48912_2.C:3:11: in constexpr expansion of ‘f()’ 48912_2.C:3:11: in constexpr expansion of ‘f()’ 48912_2.C:8:22: error: constexpr evaluation depth exceeds maximum of 512 (use -fconstexpr-depth= to increase the maximum) The first snippet though, the recursive function alone, is accepted in mainline and 4_6-branch, I'm not 100% sure that's correct, probably it is but let's ask Jason to have a look. (In reply to comment #1) Thanks to replies. > As a matter of fact, with the released 4.6.0 I'm getting an ICE, not a silent > miscompilation for the second snippet. In mainline and in the 4_6-branch it's > already correctly rejected with something like: I use released 4.6.0. Add a infomation. My emvironment is as follows: $ g++4.6 -v Built by Equation Solution <http://www.Equation.com>. Using built-in specs. COLLECT_GCC=C:\cygwin\home\RiSK\gcc4.6\bin\g++.exe COLLECT_LTO_WRAPPER=c:/cygwin/home/risk/gcc4.6/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../gcc-4.6.0-mingw/configure --host=i686-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=i686-p c-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.6.0 --with-gcc --with-gnu-as --with-gnu -ld --with-host-libstdcxx='-lstdc++ -lsupc++ -lm' --with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/ppl --with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog --with-gmp=/home/gfortran/gcc-home/binary/mi ngw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mpc=/home/gfortr an/gcc-home/binary/mingw32/native/x86_32/mpc --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4 .6.0 --disable-shared --disable-nls --disable-tls --disable-win32-registry --enable-languages=c,c++,fortran --enable- libgomp --enable-threads=win32 --enable-lto --enable-static --enable-shared=lto-plugin --enable-plugins --enable-ld=y es --enable-cloog-backend=ppl Thread model: win32 gcc version 4.6.0 (GCC) Thank you! Oh well, your target is completely different the mine, let's add the info. Anyway, the substance of the matter doesn't change much. (In reply to comment #3) > Oh well, your target is completely different the mine, let's add the info. > Anyway, the substance of the matter doesn't change much. This problem only appears with Cygwin or Mingw target, and similar problem occurs on older version (I use 4.5.0 or 4.5.2 in mingw-w64) when compiling very complex template-meta-programming, for example, Boost.Spirit.Qi. I think the default stack size should become huge. Sorry for no test-case nor environment detail. Yes, this will be fixed in 4.6.1 (by http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00848.html) The function definition is ill-formed, no diagnostic required, because there is no set of arguments that will make it a constant expression. But I don't think it's worth trying hard to diagnose it at the point of definition since we'll complain when it's used. Thanks Jason for the clarification. |
There is a infinity recursive constexpr function. constexpr int f() { return f(); } If evaluate f() compile time. Then compiler aborts silently and returns 1 to a console. All codes: constexpr int f() { return f(); } int main() { constexpr int i = f(); } Compile error: (nothing) Console: $ g++4.6 a.cpp $ echo $? 1