This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/81942] ICE on empty constexpr constructor with C++14
- From: "paolo.carlini at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 31 Aug 2017 11:09:24 +0000
- Subject: [Bug c++/81942] ICE on empty constexpr constructor with C++14
- Auto-submitted: auto-generated
- References: <bug-81942-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
Thomas Preud'homme <thopre01 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-invalid-code |ice-on-valid-code
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-08-31
CC| |paolo.carlini at oracle dot com
Ever confirmed|0 |1
--- Comment #2 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to TC from comment #1)
> Why is this tagged ice-on-invalid? The test case is valid C++14.
My bad, got confused by the error message when building for C++11.
--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
We ICE when cxx_eval_constant_expression encounters a GOTO_EXPR to a LABEL_DECL
target which is neither a break nor a continue. This is the .original:
;; Function constexpr A::A() (null)
;; enabled by -tree-original
{
// predicted unlikely by goto predictor.;
goto <D.4600>;
}
<D.4600>:;
return this;
For comparison, for x86_64 we generate none of that, simply:
;; Function constexpr A::A() (null)
;; enabled by -tree-original
{
return;
}
A guess an ARM expert is welcome, to understand where the goto is coming
from...