Bug 48912 - [C++0x] Compiler abort silently
[C++0x] Compiler abort silently
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: c++
4.6.0
: P3 normal
: 4.6.1
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-06 06:17 UTC by sscrisk
Modified: 2011-05-06 13:52 UTC (History)
2 users (show)

See Also:
Host:
Target: i686-pc-mingw32
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sscrisk 2011-05-06 06:17:46 UTC
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
Comment 1 Paolo Carlini 2011-05-06 09:47:40 UTC
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.
Comment 2 sscrisk 2011-05-06 10:58:39 UTC
(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!
Comment 3 Paolo Carlini 2011-05-06 11:17:31 UTC
Oh well, your target is completely different the mine, let's add the info. Anyway, the substance of the matter doesn't change much.
Comment 4 Tomohiro Kashiwada 2011-05-06 13:29:45 UTC
(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.
Comment 5 Jason Merrill 2011-05-06 13:46:36 UTC
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.
Comment 6 Paolo Carlini 2011-05-06 13:52:12 UTC
Thanks Jason for the clarification.