Bug 1386922 - RFC: Brace initialization bug
Summary: RFC: Brace initialization bug
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: gcc
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: alpha
: 6.0
Assignee: Jakub Jelinek
QA Contact: Michael Petlan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-19 20:50 UTC by Paulo Andrade
Modified: 2020-09-10 09:52 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2017-04-26 09:33:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 67631 0 None None None 2016-10-19 20:50:37 UTC
Red Hat Product Errata RHBA-2017:1143 0 normal SHIPPED_LIVE devtoolset-6-gcc bug fix update 2017-04-26 13:30:26 UTC

Description Paulo Andrade 2016-10-19 20:50:38 UTC
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.
"""

Comment 2 Jakub Jelinek 2017-01-12 10:28:50 UTC
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?

Comment 3 Deepu K S 2017-01-12 10:43:09 UTC
(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.

Comment 6 Michael Petlan 2017-02-22 12:40:09 UTC
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

Comment 8 errata-xmlrpc 2017-04-26 09:33:01 UTC
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


Note You need to log in before you can comment on or make changes to this bug.