[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2013-05-01 11:48:38 UTC --- With the fix for c++/57092 the ICEs are gone.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-05-07
CC||paolo.carlini at oracle dot
||com
Ever Confirmed|0 |1
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-07
09:50:43 UTC ---
For concreteness, with the below patchlet (for the record, about the
cxx_eval_call_expression bits, in build_data_member_initialization we have
something quite similar) all the test pass, besides the four lines:
static_assert((c.*W_int(C::*)()const, C::c1::value)() == 10, oops);
static_assert((c.*X_int(C::*)()const, C::c1::value)() == 10, oops);
static_assert((c.*Y_int(C::*)()const, C::c1::value)() == 10, oops);
static_assert((c.*Z_int(C::*)()const, C::c1::value)() == 10, oops);
///
Index: semantics.c
===
--- semantics.c (revision 187228)
+++ semantics.c (working copy)
@@ -5269,6 +5269,7 @@ finish_decltype_type (tree expr, bool id_expressio
case INTEGER_CST:
case PTRMEM_CST:
+ case ADDR_EXPR:
/* We can get here when the id-expression refers to an
enumerator or non-type template parameter. */
type = TREE_TYPE (expr);
@@ -6488,6 +6489,12 @@ cxx_eval_call_expression (const constexpr_call *ol
/* Might be a constexpr function pointer. */
fun = cxx_eval_constant_expression (old_call, fun, allow_non_constant,
/*addr*/false, non_constant_p);
+ if (TREE_CODE (fun) == NOP_EXPR)
+ {
+ tree tmp = fun;
+ STRIP_NOPS (tmp);
+ fun = tmp;
+ }
if (TREE_CODE (fun) == ADDR_EXPR)
fun = TREE_OPERAND (fun, 0);
}
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #3 from andyg1001 at hotmail dot co.uk 2012-05-04 16:22:21 UTC ---
This ICE still occurs in the release version of gcc 4.7.0.
Here is the output from compiling the attached test-case as is:
$ g++-4.7 -std=c++11 ice.cpp
ice.cpp: In instantiation of ‘struct Zconst int*, ( a)’:
ice.cpp:39:33: required from here
ice.cpp:11:41: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccPyRnUB.out file, please attach this to
your bugreport.
And if the lines in the test-case marked ICE are commented out, then this is
the output:
$ g++-4.7 -std=c++11 ice.cpp
ice.cpp:47:1: error: non-constant condition for static assertion
ice.cpp:47:43: error: expression ‘b10’ does not designate a constexpr
function
ice.cpp:48:1: error: non-constant condition for static assertion
ice.cpp:48:43: error: expression ‘b10’ does not designate a constexpr
function
ice.cpp:64:1: error: non-constant condition for static assertion
ice.cpp:64:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:65:1: error: non-constant condition for static assertion
ice.cpp:65:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:66:1: error: non-constant condition for static assertion
ice.cpp:66:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:67:1: error: non-constant condition for static assertion
ice.cpp:67:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:70:1: error: non-constant condition for static assertion
ice.cpp:70:43: error: expression ‘C::c2’ does not designate a constexpr
function
ice.cpp:71:1: error: non-constant condition for static assertion
ice.cpp:71:43: error: expression ‘C::c2’ does not designate a constexpr
function
The attached test-case compiles and runs successfully under clang with one
small change as shown in this diff (this doesn't affect the test-case under
gcc):
--- ice.cpp
+++ ice.cpp
@@ -53,6 +53,7 @@
static_assert(Z_int(*)(), b10::value() == 10, oops);// ICE
constexpr struct C {
+constexpr C() = default;
constexpr int c1() const { return 10; }
static constexpr int c2() { return 10; }
} c;
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-05-04 16:42:39 UTC ---
(In reply to comment #3)
This ICE still occurs in the release version of gcc 4.7.0.
And also in 4.8.0 HEAD btw.
The attached test-case compiles and runs successfully under clang with one
small change as shown in this diff (this doesn't affect the test-case under
gcc):
--- ice.cpp
+++ ice.cpp
@@ -53,6 +53,7 @@
static_assert(Z_int(*)(), b10::value() == 10, oops);// ICE
constexpr struct C {
+constexpr C() = default;
constexpr int c1() const { return 10; }
static constexpr int c2() { return 10; }
} c;
These changes are necessary for any reasonable comparison.
It seems to me that we have at least two compiler bugs here.
1) The ICE
2) The incorrect diagnostics of some non-constexpr function.
The latter error reminds me very much of bug 52892 where it became clear that
gcc can loose constexpr information when typedefs and template parameters are
inserted.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-04 18:40:51 UTC --- The ICEs, all of them, in the extended testcase too, seem easy to fix, apparently it's just that finish_decltype_type doesn't handle ADDR_EXPR. The remaining issues are more nasty, some can be fixed/wa with STRIP_NOPS, looks like we have to handle many NOP_EXPRs, something I don't really understand.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC --- Created attachment 26743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743 test-case for decltype ICE / incorrect evaluation of constexpr The attached test-case source expands on my previous bug report and shows where the ICE occurs with decltype but also where the compiler fails to detect that a value is actually constexpr (lines marked incorrect evaluation). What is interesting is that the incorrect evaluation does not occur for comparable use inside main(). GCC version: g++ (GCC) 4.7.0 20120224 (experimental)
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-16 19:24:10 UTC --- (In reply to comment #0) Note that non-static member function pointers do not generate either issues, although it is necessary to add const to the pointer type but not to the corresponding function definition: Adding const to the function type is required, because the constexpr specifier for any non-static member functions behaves as if the function were declared as const member function.
