This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/81942] ICE on empty constexpr constructor with C++14


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...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]