| Summary: | RFC: Brace initialization bug | ||
|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Paulo Andrade <pandrade> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | Michael Petlan <mpetlan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | dkochuka, jakub, jason, law, mcermak, mnewsome, mpetlan, mpolacek, ohudlick |
| Target Milestone: | alpha | ||
| Target Release: | 6.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | devtoolset-6-gcc-6.3.1-2.2.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, due to a bug in the C++ FE, a valid program using the "explicit" specifier on an "operator" and then using this operator in a list-initializer might have been rejected. This bug has been fixed and the program is now correctly compiled.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-04-26 09:33:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
The upstream PR has been fixed and the fix will be included in DTS 6.1. The #c0 snippet is not self-contained, so are you talking about something from the upstream PR that you believe is still not fixed? Can you provide self-contained testcase? (In reply to Jakub Jelinek from comment #2) > The upstream PR has been fixed and the fix will be included in DTS 6.1. > The #c0 snippet is not self-contained, so are you talking about something > from the upstream PR that you believe is still not fixed? Can you provide > self-contained testcase? No. I was asking from this RH BZ point. Just wanted to understand if we have plans to backport the fix in the next DTS release. Thanks for the reply. Successfully tested devtoolset-6-gcc-6.3.1-3.1.el{6,7}, all architectures:
PASS: g++.dg/cpp0x/initlist-explicit1.C -std=c++11 (test for excess errors)
PASS: g++.dg/cpp0x/initlist-explicit1.C -std=c++14 (test for excess errors)
UNSUPPORTED: g++.dg/cpp0x/initlist-explicit1.C -std=c++98
PASS: g++.dg/cpp0x/initlist-explicit1.C -std=c++11 (test for excess errors)
PASS: g++.dg/cpp0x/initlist-explicit1.C -std=c++14 (test for excess errors)
UNSUPPORTED: g++.dg/cpp0x/initlist-explicit1.C -std=c++98
VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1143 |
While the test cases in upstream bug report work if doing an explicit type cast, or not using the explicit keyword in the cast operators, the reasoning is that the type conversion should be done: """ With a class which has an explicit type cast operator: struct X { unsigned data_; explicit operator unsigned() const {return data_;} }; Assuming x_ is with type X, this works: unsigned t{x_}; But below few cases does not work unsigned t1 = unsigned{x_}; auto t2 = unsigned{x_}; return unsigned{x_}; unsigned{x_} should have same effect as explicit type cast in the above example. """