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

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

[ldionne.2 at gmail dot com]

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

            Bug ID: 65498
           Summary: ICE in cxx_eval_call_expression when using __func__
                    inside dependent context
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ldionne.2 at gmail dot com

The following code triggers an ICE on GCC trunk:
------------------------------------------------------------------------------
    #include <type_traits>

    struct T;

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

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

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


Example run:
------------------------------------------------------------------------------
› ~/code/gcc5/bin/g++ -std=c++1y ~/code/hana/test/worksheet.cpp
/Users/ldionne/code/hana/test/worksheet.cpp: In substitution of ‘template<bool
_Cond, class _Tp> using enable_if_t = typename std::enable_if::type [with bool
_Cond = std::is_same<T, T>{}(); _Tp = void]’:
/Users/ldionne/code/hana/test/worksheet.cpp:1411:25:   required from here
/Users/ldionne/code/hana/test/worksheet.cpp:1408:50:   in constexpr expansion
of ‘((std::integral_constant<bool, true>*)(& std::is_same<T,
T>()))->std::integral_constant<_Tp, __v>::operator()<bool, true>()’
/Users/ldionne/code/hana/test/worksheet.cpp:1411:25: internal compiler error:
in cxx_eval_call_expression, at cp/constexpr.c:1358
         auto ICE_HERE = __func__;
                         ^

/Users/ldionne/code/hana/test/worksheet.cpp:1411:25: internal compiler error:
Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
------------------------------------------------------------------------------

Note that using 

    std::is_same<X, T>::value

instead of 

    std::is_same<X, T>{}()

seems to fix the issue.


Regards,
Louis Dionne
>From gcc-bugs-return-481008-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 18:00:53 2015
Return-Path: <gcc-bugs-return-481008-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17276 invoked by alias); 20 Mar 2015 18:00:52 -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 17253 invoked by uid 48); 20 Mar 2015 18:00:49 -0000
From: "marejde at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65499] New: Missing "using namespace literals::chrono_literals" in std::chrono
Date: Fri, 20 Mar 2015 18:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marejde at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65499-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/msg02152.txt.bz2
Content-length: 1448

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

            Bug ID: 65499
           Summary: Missing "using namespace literals::chrono_literals" in
                    std::chrono
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marejde at gmail dot com

Reading http://en.cppreference.com/w/cpp/chrono/operator%22%22min (sorry, I do
not have the spec readily available) it says:

"In addition, within the namespace std::chrono, the directive using namespace
literals::chrono_literals; is provided by the standard library, so that if a
programmer uses using namespace std::chrono; to gain access to the duration
classes, the duration literal operators become visible as well."

The following program:

#include <chrono>
#include <iostream>

int main(void)
{
    using namespace std::chrono;
    minutes min = 36min;
    return 0;
}

Does not compile with GCC 4.9.2 while it does with Clang 3.6.

Looking at GCC trunk as of today I do not see a "using namespace
literals::chrono_literals;" anywhere in libstdc++-v3/include/ . Clang's libc++
has it in the chrono namespace though.

Would be great if this could be fixed before GCC 5.0 is released so I don't
have to sprinkle "using namespace literals::chrono_literals;" in my code to be
able to compile with GCC.

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-20
   Target Milestone|---                         |5.0
            Summary|ICE in                      |[5 Regression] ICE in
                   |cxx_eval_call_expression    |cxx_eval_call_expression
                   |when using __func__ inside  |when using __func__ inside
                   |dependent context           |dependent context
     Ever confirmed|0                           |1

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Confirmed.

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

[ldionne.2 at gmail dot com]

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

--- Comment #1 from Louis Dionne <ldionne.2 at gmail dot com> ---
Apologies; the lines of the example run were wrapped and it's unreadable from
here. Here's what it looks like:

    https://gist.github.com/ldionne/054e276caf90f16e3223

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

[daniel.kruegler at googlemail dot com]

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.

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

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The first snippet in comment 3 started ICEing with r217664.

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

[ldionne.2 at gmail dot com]

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

--- Comment #5 from Louis Dionne <ldionne.2 at gmail dot com> ---
[Just a quick comment: thank you for being so responsive. Most of my bug
reports on Clang are left hanging for a long while before anyone ever considers
them, and I appreciate it not being the case here.]

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The problem appears to be that we're trying to use the body of the operator()
function after it's been released (release_function_body).  Investigating
more...

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
After we process functions, we remove the unused ones here

1112       if (!node->aux && !node->referred_to_p ())
1113         {
1114           if (symtab->dump_file)
1115             fprintf (symtab->dump_file, " %s", node->name ());
1116           node->remove ();

Afterwards we start the mangling: for each symbol we call
insert_to_assembler_name_hash, even for __func__, but that doesn't have
DECL_ASSEMBLER_NAME set, which means we call mangle_decl for it, that calls
get_mostly_instantiated_function_type later on, and that subsequently calls
cxx_eval_call_expression, and here we ICE.

Any ideas?

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

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
The problem here is that mangling wants to do constexpr evaluation after we've
thrown away the body of is_same::operator() because it isn't referenced.

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

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So fixed (tried both snippets in comment 3).