* [Bug c++/65498] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
@ 2015-03-20 18:19 ` ldionne.2 at gmail dot com
2015-03-20 18:19 ` [Bug c++/65498] [5 Regression] " paolo.carlini at oracle dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ldionne.2 at gmail dot com @ 2015-03-20 18:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
2015-03-20 18:19 ` [Bug c++/65498] " ldionne.2 at gmail dot com
@ 2015-03-20 18:19 ` paolo.carlini at oracle dot com
2015-03-20 21:03 ` daniel.kruegler at googlemail dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: paolo.carlini at oracle dot com @ 2015-03-20 18:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
2015-03-20 18:19 ` [Bug c++/65498] " ldionne.2 at gmail dot com
2015-03-20 18:19 ` [Bug c++/65498] [5 Regression] " paolo.carlini at oracle dot com
@ 2015-03-20 21:03 ` daniel.kruegler at googlemail dot com
2015-03-22 14:52 ` mpolacek at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2015-03-20 21:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (2 preceding siblings ...)
2015-03-20 21:03 ` daniel.kruegler at googlemail dot com
@ 2015-03-22 14:52 ` mpolacek at gcc dot gnu.org
2015-03-22 15:11 ` ldionne.2 at gmail dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-03-22 14:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (3 preceding siblings ...)
2015-03-22 14:52 ` mpolacek at gcc dot gnu.org
@ 2015-03-22 15:11 ` ldionne.2 at gmail dot com
2015-03-24 13:25 ` mpolacek at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ldionne.2 at gmail dot com @ 2015-03-22 15:11 UTC (permalink / raw)
To: gcc-bugs
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.]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (4 preceding siblings ...)
2015-03-22 15:11 ` ldionne.2 at gmail dot com
@ 2015-03-24 13:25 ` mpolacek at gcc dot gnu.org
2015-03-24 15:51 ` mpolacek at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-03-24 13:25 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (5 preceding siblings ...)
2015-03-24 13:25 ` mpolacek at gcc dot gnu.org
@ 2015-03-24 15:51 ` mpolacek at gcc dot gnu.org
2015-03-24 17:13 ` jason at gcc dot gnu.org
2015-03-25 8:46 ` mpolacek at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-03-24 15:51 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (6 preceding siblings ...)
2015-03-24 15:51 ` mpolacek at gcc dot gnu.org
@ 2015-03-24 17:13 ` jason at gcc dot gnu.org
2015-03-25 8:46 ` mpolacek at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jason at gcc dot gnu.org @ 2015-03-24 17:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
2015-03-20 18:15 [Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context ldionne.2 at gmail dot com
` (7 preceding siblings ...)
2015-03-24 17:13 ` jason at gcc dot gnu.org
@ 2015-03-25 8:46 ` mpolacek at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-03-25 8:46 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 10+ messages in thread