[Bug c++/105565] New: [11 Regression] constexpr function with bigger integral cause internal compiler error

[Bug c++/105565] New: [11 Regression] constexpr function with bigger integral cause internal compiler error

[chenzhipeng02 at agora dot io]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

            Bug ID: 105565
           Summary: [11 Regression] constexpr function with bigger
                    integral  cause internal compiler error
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chenzhipeng02 at agora dot io
  Target Milestone: ---

Created attachment 52954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52954&action=edit
isPrimeConstexpr for 1073741789 compiled successfully but 2147483647 fail

The following code is bugInConstexpr.cpp in the Attachment

#include <iostream>
using LL = long long;

constexpr bool isPrimeR(LL n, LL c) {
  return (c * c > n) ? true : (n % c == 0) ? false : isPrimeR(n, c + 2);
}

constexpr bool isPrimeConstexpr(LL n) {
  return (n <= 1) ? false : n < 4 || (n % 2 == 1 && isPrimeR(n, 3));
}

int main() {
  {
    constexpr LL m = 1073741789LL;  // prime
    constexpr bool x = isPrimeConstexpr(m);
    std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  }

  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
  // {
  //   constexpr LL m = 44657LL * 44683LL;  // 1995408731
  //   constexpr bool x = isPrimeConstexpr(m);
  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  // }

  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
  // {
  //   constexpr LL m = 2147483647LL;  // prime 2^31 - 1
  //   constexpr bool x = isPrimeConstexpr(m);
  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
  // }

  return 0;
}

It is used to check whether the constexpr number is prime or not.

$ g++-11 bugInConstexpr.cpp -std=c++17 -fconstexpr-depth=100000

will compile successfully, but if m changes to be 2147483647, it will compile
fail
with message

g++-11: internal compiler error: Segmentation fault: 11 signal terminated
program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew-core/issues> for instructions.

!!! But Work fine in gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

$ g++-11 -v

Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.1.0_1/libexec/gcc/aarch64-apple-darwin20/11.1.0/lto-wrapper
Target: aarch64-apple-darwin20
Configured with: ../configure --prefix=/opt/homebrew/Cellar/gcc/11.1.0_1
--libdir=/opt/homebrew/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp
--with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc
--with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd
--with-pkgversion='Homebrew GCC 11.1.0_1'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--build=aarch64-apple-darwin20 --with-system-zlib --disable-multilib
--with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Homebrew GCC 11.1.0_1) 

MacOS Monterey 12.3.1

---------------------------------------------------------------------------

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

Ubuntu 22.04

[Bug c++/105565] [11 Regression] constexpr function with bigger integral cause internal compiler error

[chenzhipeng02 at agora dot io]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

--- Comment #1 from chenzhipeng <chenzhipeng02 at agora dot io> ---
Comment on attachment 52954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52954
isPrimeConstexpr for 1073741789 compiled successfully but 2147483647 fail

>#include <iostream>
>
>using LL = long long;
>
>constexpr bool isPrimeR(LL n, LL c) {
>  return (c * c > n) ? true : (n % c == 0) ? false : isPrimeR(n, c + 2);
>}
>
>constexpr bool isPrimeConstexpr(LL n) {
>  return (n <= 1) ? false : n < 4 || (n % 2 == 1 && isPrimeR(n, 3));
>}
>
>int main() {
>  {
>    constexpr LL m = 1073741789LL;  // prime
>    constexpr bool x = isPrimeConstexpr(m);
>    std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  }
>
>  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated program cc1plus
>  // {
>  //   constexpr LL m = 44657LL * 44683LL;  // 1995408731
>  //   constexpr bool x = isPrimeConstexpr(m);
>  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  // }
>
>  // g++-11: internal compiler error: Segmentation fault: 11 signal terminated program cc1plus
>  // {
>  //   constexpr LL m = 2147483647LL;  // prime 2^31 - 1
>  //   constexpr bool x = isPrimeConstexpr(m);
>  //   std::cout << m << " is " <<  (x ? "prime" : "not prime") << '\n';
>  // }
>
>  return 0;
>}

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |compile-time-hog,
                   |                            |memory-hog, needs-reduction
            Summary|[11 Regression] constexpr   |[10/11/12/13 Regression]
                   |function with bigger        |constexpr function with
                   |integral  cause internal    |bigger integral  cause
                   |compiler error              |internal compiler error
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |10.4
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-05-11

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed, I think.  We've started to run out of memory with r278775.  It'd be
nice to understand why, and perhaps do something about it, if possible.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Seems we're hitting a stack overflow due to the excessive recursion, same with
Clang.  Not sure if we can realistically do much about that..

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #3)
> Seems we're hitting a stack overflow due to the excessive recursion, same
> with Clang.  Not sure if we can realistically do much about that..

Not sure, either.  But it looks like r278775 exacerbated the problem somehow,
the test reliably fails/compiles after/before that revision.  I wonder why,
it's a concepts patch.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
I suspect the changes to cxx_eval_call_expression and/or
cxx_eval_constant_expression caused these functions to use more stack space per
recursive call, and this marginal increase was enough to overflow the stack
during constexpr evaluation for this testcase.

[Bug c++/105565] [10/11/12/13 Regression] constexpr function with bigger integral cause internal compiler error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105565

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(Now actually looking at the patch...)

I think you're right, it's likely those concept_check_p calls that did that. 
Doesn't look like we can avoid that.  Thus closing.