[Bug tree-optimization/100102] New: ICE in tsubst, at cp/pt.c:15310

[Bug tree-optimization/100102] New: ICE in tsubst, at cp/pt.c:15310

[schnetter at gmail dot com]

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

            Bug ID: 100102
           Summary: ICE in tsubst, at cp/pt.c:15310
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schnetter at gmail dot com
  Target Milestone: ---

I am using GCC 10.3.0 on x86_64 GNU/Linux. GCC was built via Spack, and is
called from nvcc.

I encounter the following ICE:

cd
/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5/Src
&&
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/cuda-11.2.2-jbyezwujy3vielujb4xz3izwi6q36jnb/bin/nvcc
-forward-unknown-to-host-compiler
-ccbin=/home/eschnetter/src/CarpetX/Cactus/view-cuda-compilers/bin/g++
-Damrex_EXPORTS
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Boundary
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/AmrCore
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Amr
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/MLMG
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/Projections
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Particle
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/openmpi-4.0.5-jl7qr7jpt3fe6z5rdfkgj2n4t5b4xbdn/include
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/hdf5-1.10.7-gkflrn3su7geakoyly56sqebg2pqa2yr/include
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/zlib-1.2.11-dd2emzewyp4o4c22f3niqq3dyhjhqkzs/include
-m64 --expt-relaxed-constexpr --expt-extended-lambda
-Wno-deprecated-gpu-targets -gencode=arch=compute_75,code=sm_75
-maxrregcount=255 -Xcudafe --diag_suppress=esa_on_defaulted_function_ignored
--use_fast_math -Xcudafe --display_error_number --Wext-lambda-captures-this
--Werror ext-lambda-captures-this --Werror cross-execution-space-call
--generate-line-info --source-in-ptx -O2 -g -DNDEBUG -Xcompiler=-fPIC
-Xcompiler=-fopenmp -Xcompiler=-Werror=return-type -Xcompiler -pthread
-std=c++14 -MD -MT Src/CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o -MF
CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o.d -x cu -dc
/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base/AMReX_BlockMutex.cpp
-o CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:
In substitution of 'template<class _Rep, class _Period> template<class
_Period2> using __is_harmonic =
std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))),
((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den,
_Period::den)) * (_Period::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 =
_Period2; _Rep = _Rep; _Period = _Period]':
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:473:154:
  required from here
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:428:27:
internal compiler error: Segmentation fault
  428 |  _S_gcd(intmax_t __m, intmax_t __n) noexcept
      |                           ^~~~~~
0xc5d6af crash_signal
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/toplev.c:328
0x754d6d tsubst(tree_node*, tree_node*, int, tree_node*)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:15310
0x767d76 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13225
0x760766 tsubst_aggr_type
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13428
0x76aa5f tsubst_function_decl
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13816
0x761409 tsubst_decl
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:14267
0x74f3f1 tsubst_copy
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:16512
0x752cea tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:20707
0x751846 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19274
0x751846 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19896
0x750c7d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19274
0x750c7d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19588
0x750c46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19274
0x750c46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19587
0x763224 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19274
0x763224 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:18886
0x767d76 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13225
0x760766 tsubst_aggr_type
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13428
0x750667 tsubst_qualified_id
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:16215
0x75238d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
       
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:19625
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://github.com/spack/spack/issues> for instructions.
Src/CMakeFiles/amrex.dir/build.make:78: recipe for target
'Src/CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o' failed

GCC 10.2.0 compiles the code without problems.

To reproduce, compile the attached preprocessed source code with the options

g++ -std=c++14 -c -x c++ -fPIC -fopenmp -Werror=return-type -pthread -O2 -m64
-g -gdwarf-2 "AMReX_BlockMutex.cpp.ii" -o "AMReX_BlockMutex.cpp.o"

[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310

[schnetter at gmail dot com]

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

--- Comment #1 from Erik Schnetter <schnetter at gmail dot com> ---
Created attachment 50605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50605&action=edit
Compressed preprocessed source code

[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-04-15
             Status|UNCONFIRMED                 |NEW
                 CC|                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase (though invalid):
template <bool> using a = int;
template <long> struct b;
template <class, class> struct c {
  static long m_fn1();
  template <class> using d = a<b<long(c::m_fn1)>::den>;
  class e d<e>;
};

[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in tsubst, at           |[8/9/10/11 Regression] ICE
                   |cp/pt.c:15310               |in tsubst, at cp/pt.c:15310
   Target Milestone|---                         |8.5
           Priority|P3                          |P2
                 CC|                            |jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started to ICE with r8-2724-g88b811bd29063036fd4536ee1312b1269cade6ed

[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another reduction, which is accepted by g++ 7.x and clang++ and ICEs the same
way by 8-trunk:
template <bool> using a = int;
template <class> struct b;
template <class...> struct c;
template <bool> struct i;
template <bool d> using e = typename i<d>::f;
template <class... d> using g = e<c<d...>::h>;
template <long> struct j;
template <class, class> struct k {
  static long o();
  template <class> using n = a<j<int(k::o)>::den>;
  template <class l, class m, g<b<c<n<m>, l>>>> struct q {};
};

[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Erik Schnetter from comment #0)
> I am using GCC 10.3.0 on x86_64 GNU/Linux. GCC was built via Spack, and is
> called from nvcc.
> 
> I encounter the following ICE:
...
> GCC 10.2.0 compiles the code without problems.

I tried plain GCC 10.2.0 with the attached preprocessed source and it ICEs
the same way.  I suppose there might be some header differences?

> To reproduce, compile the attached preprocessed source code with the options
> 
> g++ -std=c++14 -c -x c++ -fPIC -fopenmp -Werror=return-type -pthread -O2
> -m64 -g -gdwarf-2 "AMReX_BlockMutex.cpp.ii" -o "AMReX_BlockMutex.cpp.o"

It already crashes with just g++ -std=c++14 for me (since the crash is inside
the C++ frontend).

[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310

[schnetter at gmail dot com]

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

--- Comment #6 from Erik Schnetter <schnetter at gmail dot com> ---
I looked for the string "GCC" in the user header files, but could not find any
place where things would differ between GCC 10.2 and 10.3. I assume there could
be a difference in GCC-provided header files (the error message mentions
"chrono" and "gcd"), or it could be that nvcc examines the GCC version and
produces different code.

[Bug tree-optimization/100102] [8/9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ed.gcc at pobox dot com]

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

Eduard Rozenberg <ed.gcc at pobox dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ed.gcc at pobox dot com

--- Comment #7 from Eduard Rozenberg <ed.gcc at pobox dot com> ---
The same/similar issue also reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240

In my case no problems with GCC 10.2.0, problems started with GCC 10.3.0.

[Bug c++/100102] [8/9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |c++
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Changing component from tree-opt to c++

[Bug c++/100102] [8/9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[taraba.peter at mail dot com]

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

Peter Taraba <taraba.peter at mail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |taraba.peter at mail dot com

--- Comment #9 from Peter Taraba <taraba.peter at mail dot com> ---
*** Bug 100240 has been marked as a duplicate of this bug. ***

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bowie.owens at gmail dot com

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 100277 has been marked as a duplicate of this bug. ***

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexander.grund@tu-dresden.
                   |                            |de

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 100448 has been marked as a duplicate of this bug. ***

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
cvised reproducer from PR 100448

template <bool> using __bool_constant struct intmax_t;
template <int, int> struct ratio {
  template <class _Period> struct duration {
    static intmax_t _S_gcd();
    template <class>
    using __is_harmonic =
        __bool_constant<ratio<0, _Period(duration ::_S_gcd)>::den>;
    class _Period2 __is_harmonic<_Period2>

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Erik Schnetter from comment #6)
> I looked for the string "GCC" in the user header files, but could not find
> any place where things would differ between GCC 10.2 and 10.3. I assume
> there could be a difference in GCC-provided header files (the error message
> mentions "chrono" and "gcd"), or it could be that nvcc examines the GCC
> version and produces different code.

The difference is r10-9609-g14f8307cf4261efd5ee4475b3c7f7c42c48557d6 in the
<chrono> header, which is in 10.3 and not 10.2

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is an old, latent g++ bug, but it now makes it impossible to use cuda with
GCC (e.g. on Fedora) because of my libstdc++ changes. I will see if I can make
another libstdc++ change to avoid the ICE without having to revert the change
completely, as it was done to fix a non-conformance bug.

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #17 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Reduced valid reproducer:

template<int()> struct ratio;
template<class, class> struct duration {
  static constexpr int _S_gcd();
  template<class> using __is_harmonic = ratio<_S_gcd>;
  using type = __is_harmonic<int>;
};

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mu11 at yahoo dot com

--- Comment #18 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 100599 has been marked as a duplicate of this bug. ***

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

--- Comment #19 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Candidate patch that addresses the ICE in the original testcase and reductions:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571899.html

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:5357ab75dedef403b0eebf9277d61d1cbeb5898f

commit r12-1223-g5357ab75dedef403b0eebf9277d61d1cbeb5898f
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jun 4 13:46:53 2021 -0400

    c++: tsubst_function_decl and excess arg levels [PR100102]

    Here, when instantiating the dependent alias template
    duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
    substituting the function decl _S_gcd.  Since we have more arg levels
    than _S_gcd has parm levels, an old special case in tsubst_function_decl
    causes us to unwantedly reduce args to its innermost level, yielding
    args={int}, which leads to a nonsensical substitution into the decl
    context and eventually a crash.

    The comment for this special case refers to three examples for which we
    ought to see more arg levels than parm levels here, but none of the
    examples actually demonstrate this.  In the first example, when
    defining S<int>::f(U) parms_depth is 2 and args_depth is 1, and
    later when instantiating say S<int>::f<char> both depths are 2.  In the
    second example, when substituting the template friend declaration
    parms_depth is 2 and args_depth is 1, and later when instantiating f
    both depths are 1.  Finally, the third example is invalid since we can't
    specialize a member template of an unspecialized class template like
    that.

    Given that this reduction code seems no longer relevant for its
    documented purpose and that it causes problems as in the PR, this patch
    just removes it.  Note that as far as bootstrap/regtest is concerned,
    this code is dead; the below two tests would be the first to reach it.

            PR c++/100102

    gcc/cp/ChangeLog:

            * pt.c (tsubst_function_decl): Remove old code for reducing
            args when it has excess levels.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/alias-decl-72.C: New test.
            * g++.dg/cpp0x/alias-decl-72a.C: New test.

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ed.gcc at pobox dot com]

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

--- Comment #21 from Eduard Rozenberg <ed.gcc at pobox dot com> ---
@ppalka Huge thanks for this fix - it's working well for me. Very happy to see
the patch applied with no problems to gcc 10.3.0, because it could take several
years until the OS and Nvidia support gcc 11 or 12. Otherwise I would have had
to move back to gcc 10.2.0 and build custom kernels for quite some time.

Tested as follows:
* Rebuilt Slackware gcc 10.3.0 packages with the patch for `pt.c`
* Built Nvidia nccl-tests - build succeeded (was failing before the patch)
* Built latest pytorch git with Nvidia support - build succeeded (was failing
before the patch)

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

--- Comment #22 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Eduard Rozenberg from comment #21)
> @ppalka Huge thanks for this fix - it's working well for me. Very happy to
> see the patch applied with no problems to gcc 10.3.0, because it could take
> several years until the OS and Nvidia support gcc 11 or 12. Otherwise I
> would have had to move back to gcc 10.2.0 and build custom kernels for quite
> some time.
> 
> Tested as follows:
> * Rebuilt Slackware gcc 10.3.0 packages with the patch for `pt.c`
> * Built Nvidia nccl-tests - build succeeded (was failing before the patch)
> * Built latest pytorch git with Nvidia support - build succeeded (was
> failing before the patch)

Thanks a lot for testing the fix.  It'll get backported to the 11 and 10
release branches later today.

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:f1feb74046e0feb0596b93bbb822fae02940a90e

commit r11-8520-gf1feb74046e0feb0596b93bbb822fae02940a90e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jun 4 13:46:53 2021 -0400

    c++: tsubst_function_decl and excess arg levels [PR100102]

    Here, when instantiating the dependent alias template
    duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
    substituting the function decl _S_gcd.  Since we have more arg levels
    than _S_gcd has parm levels, an old special case in tsubst_function_decl
    causes us to unwantedly reduce args to its innermost level, yielding
    args={int}, which leads to a nonsensical substitution into the decl
    context and eventually a crash.

    The comment for this special case refers to three examples for which we
    ought to see more arg levels than parm levels here, but none of the
    examples actually demonstrate this.  In the first example, when
    defining S<int>::f(U) parms_depth is 2 and args_depth is 1, and
    later when instantiating say S<int>::f<char> both depths are 2.  In the
    second example, when substituting the template friend declaration
    parms_depth is 2 and args_depth is 1, and later when instantiating f
    both depths are 1.  Finally, the third example is invalid since we can't
    specialize a member template of an unspecialized class template like
    that.

    Given that this reduction code seems no longer relevant for its
    documented purpose and that it causes problems as in the PR, this patch
    just removes it.  Note that as far as bootstrap/regtest is concerned,
    this code is dead; the below two tests would be the first to reach it.

            PR c++/100102

    gcc/cp/ChangeLog:

            * pt.c (tsubst_function_decl): Remove old code for reducing
            args when it has excess levels.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/alias-decl-72.C: New test.
            * g++.dg/cpp0x/alias-decl-72a.C: New test.

    (cherry picked from commit 5357ab75dedef403b0eebf9277d61d1cbeb5898f)

[Bug c++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:fc930b3010bd0de899a3da3209eab20664ddb703

commit r10-9895-gfc930b3010bd0de899a3da3209eab20664ddb703
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jun 4 13:46:53 2021 -0400

    c++: tsubst_function_decl and excess arg levels [PR100102]

    Here, when instantiating the dependent alias template
    duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
    substituting the function decl _S_gcd.  Since we have more arg levels
    than _S_gcd has parm levels, an old special case in tsubst_function_decl
    causes us to unwantedly reduce args to its innermost level, yielding
    args={int}, which leads to a nonsensical substitution into the decl
    context and eventually a crash.

    The comment for this special case refers to three examples for which we
    ought to see more arg levels than parm levels here, but none of the
    examples actually demonstrate this.  In the first example, when
    defining S<int>::f(U) parms_depth is 2 and args_depth is 1, and
    later when instantiating say S<int>::f<char> both depths are 2.  In the
    second example, when substituting the template friend declaration
    parms_depth is 2 and args_depth is 1, and later when instantiating f
    both depths are 1.  Finally, the third example is invalid since we can't
    specialize a member template of an unspecialized class template like
    that.

    Given that this reduction code seems no longer relevant for its
    documented purpose and that it causes problems as in the PR, this patch
    just removes it.  Note that as far as bootstrap/regtest is concerned,
    this code is dead; the below two tests would be the first to reach it.

            PR c++/100102

    gcc/cp/ChangeLog:

            * pt.c (tsubst_function_decl): Remove old code for reducing
            args when it has excess levels.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/alias-decl-72.C: New test.
            * g++.dg/cpp0x/alias-decl-72a.C: New test.

    (cherry picked from commit 5357ab75dedef403b0eebf9277d61d1cbeb5898f)

[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4
         Resolution|---                         |FIXED
            Summary|[9/10/11/12 Regression] ICE |[9 Regression] ICE in
                   |in tsubst, at cp/pt.c:15310 |tsubst, at cp/pt.c:15310
             Status|ASSIGNED                    |RESOLVED

--- Comment #25 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 10.4, 11.2 and 12.

[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:a1b3484a8e6c53c8084723e3f1738d402374198e

commit r12-1270-ga1b3484a8e6c53c8084723e3f1738d402374198e
Author: Jason Merrill <jason@redhat.com>
Date:   Mon May 31 12:56:34 2021 -0400

    c++: alias member template [PR100102]

    Patrick already fixed the primary cause of this bug.  But while I was
    looking at this testcase I noticed that with the qualified name k::o we
    ended up with a plain FUNCTION_DECL, whereas without the k:: we got a
    BASELINK.  There seems to be no good reason not to return the BASELINK
    in this case as well.

            PR c++/100102

    gcc/cp/ChangeLog:

            * init.c (build_offset_ref): Return the BASELINK for a static
            member function.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/alias-decl-73.C: New test.

[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |henrik.nortamo at csc dot fi

--- Comment #27 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 100737 has been marked as a duplicate of this bug. ***

[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michaelreneer at gmail dot com

--- Comment #28 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 103532 has been marked as a duplicate of this bug. ***