Created attachment 50605 [details]
Compressed preprocessed source code

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>;
};

Started to ICE with r8-2724-g88b811bd29063036fd4536ee1312b1269cade6ed

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 {};
};

(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).

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 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.

Changing component from tree-opt to c++

*** Bug 100240 has been marked as a duplicate of this bug. ***

GCC 8 branch is being closed.

GCC 9.4 is being released, retargeting bugs to GCC 9.5.

*** Bug 100277 has been marked as a duplicate of this bug. ***

*** Bug 100448 has been marked as a duplicate of this bug. ***

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>

(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

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.

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 100599 has been marked as a duplicate of this bug. ***

Candidate patch that addresses the ICE in the original testcase and reductions: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571899.html

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.

@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)

(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.

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)

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)

Fixed for GCC 10.4, 11.2 and 12.

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 100737 has been marked as a duplicate of this bug. ***

*** Bug 103532 has been marked as a duplicate of this bug. ***