[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

["daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
Removing libraries dependencies leads to:

//--------------
template <typename, typename>
struct is_same 
{ 
  enum { value = false }; 
  constexpr bool operator()() const noexcept { return value; }
};

template <typename T>
struct is_same<T, T> 
{ 
  enum { value = true }; 
  constexpr bool operator()() const noexcept { return value; }
};

template <bool, typename = void>
struct enable_if { };

template <typename T>
struct enable_if<true, T> { typedef T type; };

template <bool V, typename T = void>
using enable_if_t = typename enable_if<V, T>::type;

struct T;

template <typename, typename = void>
struct F { };

template <typename X>
struct F<X, enable_if_t<is_same<X, T>{}()>> {
    template <typename MakeDependent>
    F(MakeDependent) {
        auto ICE_HERE = __func__;
        (void)ICE_HERE; // avoid -Wunused-variable
    }
};

int main() {
    F<T>{1};
}
//--------------

If we remove remove the enable_if_t alias we get to:

//--------------
template <typename, typename>
struct is_same 
{ 
  enum { value = false }; 
  constexpr bool operator()() const noexcept { return value; }
};

template <typename T>
struct is_same<T, T> 
{ 
  enum { value = true }; 
  constexpr bool operator()() const noexcept { return value; }
};

template <bool, typename = void>
struct enable_if { };

template <typename T>
struct enable_if<true, T> { typedef T type; };

struct T;

template <typename, typename = void>
struct F { };

template <typename X>
struct F<X, typename enable_if<is_same<X, T>{}()>::type> {
    template <typename MakeDependent>
    F(MakeDependent) {
        auto ICE_HERE = __func__;
        (void)ICE_HERE; // avoid -Wunused-variable
    }
};

int main() {
    F<T>{1};
}
//--------------

This still leads to an ICE, but with different diagnostics using GCC 5.0.0
20150320 (experimental):

>>>>>>>>>>>
nternal compiler error: Error reporting routines re-entered.
0x6fedc5 cxx_eval_call_expression
    /home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1358
0x6f9beb cxx_eval_constant_expression
    /home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3021
0x6fc330 cxx_eval_outermost_constant_expr
    /home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3529
0x6283b0 convert_nontype_argument
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:5843
0x6283b0 convert_template_argument
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:6744
0x628f32 coerce_template_parms
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:7171
0x629ea8 lookup_template_class_1
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:7780
0x629ea8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:8096
0x62b12c tsubst_aggr_type
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:10460
0x623ce9 tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/heads/gcc/gcc-source/gcc/cp/pt.c:12418
0x655bd0 dump_template_bindings
    /home/heads/gcc/gcc-source/gcc/cp/error.c:369
0x655bd0 dump_substitution
    /home/heads/gcc/gcc-source/gcc/cp/error.c:1448
0x6570fe decl_as_string_translate(tree_node*, int)
    /home/heads/gcc/gcc-source/gcc/cp/error.c:2821
0x6c1f35 cxx_printable_name_internal
    /home/heads/gcc/gcc-source/gcc/cp/tree.c:2028
0x656cb2 cp_print_error_function
    /home/heads/gcc/gcc-source/gcc/cp/error.c:3154
0x656cb2 cp_diagnostic_starter
    /home/heads/gcc/gcc-source/gcc/cp/error.c:3108
0x102b889 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
    /home/heads/gcc/gcc-source/gcc/diagnostic.c:866
0x102c8a2 internal_error(char const*, ...)
    /home/heads/gcc/gcc-source/gcc/diagnostic.c:1223
0x102b1e3 fancy_abort(char const*, int, char const*)
    /home/heads/gcc/gcc-source/gcc/diagnostic.c:1291
0x6fedc5 cxx_eval_call_expression
    /home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1358
<<<<<<<<<<<
>From gcc-bugs-return-481030-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 20:42:11 2015
Return-Path: <gcc-bugs-return-481030-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 108363 invoked by alias); 20 Mar 2015 20:42:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 107516 invoked by uid 48); 20 Mar 2015 20:42:07 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
Date: Fri, 20 Mar 2015 21:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64860-4-ETcnQ9QLK0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64860-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64860-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02174.txt.bz2
Content-length: 319

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd860

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I suppose proper fix is to make flag_incremental_linking and turn -r from
Driver only.  Then we could revisit individual optimizations that do rely on
the fact that static linking will not be re-done.