public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization
@ 2011-01-25 4:12 schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-01-25 4:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Summary: Various non-conforming behaviors with braced-init-list
initialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: schaub.johannes@googlemail.com
According to n3225, GCC is apparently not conforming to the latest specs. The
following points out some flaws.
// should be invalid (takes bullet 5 of 8.5p16, for data-member a)
// incorrectly accepted by GCC.
struct A { int a[2]; A():a({1, 2}) { } };
The spec is not clear about what behavior the following should exhibit
according to 8.5p16. As long as it's not cleared up, GCC should reconsider
whether it's desirable to accept it, it seems:
int a({0}); // spec is not clear. doesn't define this case?
The following is ill-formed, because it takes bullet 2 and then hits 8.5.3p1:
int const &b({0}); // incorrectly accepted by GCC
If both of those have different meanings with regard to validity, this is very
disgusting.
In short, the intent seems to be that a "({ ... })" initializer is only allowed
for class types, where it will hit 8.5.16p6. That's the only valid way such an
initialize can be interpreted for classes, in order not to accept the following
struct A { explicit A(int, int); };
A a({1, 2}); // this must be invalid, and GCC correctly rejects it.
In the end, I think the spec is very unclear about this, and GCC possibly
should reconsider some of its behavior here.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
@ 2011-01-25 4:16 ` schaub.johannes at googlemail dot com
2011-01-25 5:21 ` schaub.johannes at googlemail dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-01-25 4:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Johannes Schaub <schaub.johannes at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #1 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:16:21 UTC ---
Adding Jason. AFAIK he's implemented this for GCC.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
@ 2011-01-25 5:21 ` schaub.johannes at googlemail dot com
2011-05-12 5:57 ` schaub.johannes at googlemail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-01-25 5:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #2 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:37:01 UTC ---
(In reply to comment #0)
> In short, the intent seems to be that a "({ ... })" initializer is only allowed
> for class types, where it will hit 8.5.16p6.
>
I'm sorry. I meant 8.5p16 bullet 6. I don't want to add unnecessarily more
confusion to this :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
2011-01-25 5:21 ` schaub.johannes at googlemail dot com
@ 2011-05-12 5:57 ` schaub.johannes at googlemail dot com
2011-07-29 6:09 ` d.v.a at ngs dot ru
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-05-12 5:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #3 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-05-12 05:23:15 UTC ---
I think we have the FDIS clear about these cases now. To update:
// invalid
struct A { int a[2]; A():a({1, 2}) { } };
// invalid
int a({0});
// invalid
int const &b({0});
struct A { explicit A(int, int); A(int, long); };
// invalid
A c({1, 2});
// valid (by copy constructor).
A d({1, 2L});
// valid
A e{1, 2};
struct B {
template<typename ...T>
B(initializer_list<int>, T ...);
};
// invalid (the first phase only considers init-list ctors)
// (for the second phase, no constructor is viable)
B f{1, 2, 3};
// valid (T deduced to <>).
B g({1, 2, 3});
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (2 preceding siblings ...)
2011-05-12 5:57 ` schaub.johannes at googlemail dot com
@ 2011-07-29 6:09 ` d.v.a at ngs dot ru
2011-07-29 12:24 ` schaub.johannes at googlemail dot com
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: d.v.a at ngs dot ru @ 2011-07-29 6:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
__vic <d.v.a at ngs dot ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |d.v.a at ngs dot ru
--- Comment #4 from __vic <d.v.a at ngs dot ru> 2011-07-29 06:08:29 UTC ---
struct A { int a[2]; A():a({1, 2}) { } };
Should be valid. Example:
class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};
What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
accepted in any case? Uniform initialization initially address this issue.
Out of constructor one can use "=":
::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
In constructor init-list "=" is prohibited therefore "()" must play a same
role.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (3 preceding siblings ...)
2011-07-29 6:09 ` d.v.a at ngs dot ru
@ 2011-07-29 12:24 ` schaub.johannes at googlemail dot com
2011-08-02 3:26 ` d.v.a at ngs dot ru
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-07-29 12:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #5 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-07-29 12:23:35 UTC ---
(In reply to comment #4)
> struct A { int a[2]; A():a({1, 2}) { } };
>
> Should be valid. Example:
>
> class cond_variable
> {
> ::pthread_cond_t cond;
> public:
> constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
> };
>
> What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
> accepted in any case? Uniform initialization initially address this issue.
>
Why not say
constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
> Out of constructor one can use "=":
>
> ::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
>
You can define it as follows to make it work in both cases
#define PTHREAD_COND_INITIALIZER {}
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (4 preceding siblings ...)
2011-07-29 12:24 ` schaub.johannes at googlemail dot com
@ 2011-08-02 3:26 ` d.v.a at ngs dot ru
2011-08-03 18:53 ` [Bug c++/47453] [DR 1214] " jason at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: d.v.a at ngs dot ru @ 2011-08-02 3:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #6 from __vic <d.v.a at ngs dot ru> 2011-08-02 03:25:10 UTC ---
>
> Why not say
>
> constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
>
What if PTHREAD_COND_INITIALIZER is a just scalar?
>
> You can define it as follows to make it work in both cases
>
> #define PTHREAD_COND_INITIALIZER {}
I cannot define/redefine this value. It's already defined in system headers...
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (5 preceding siblings ...)
2011-08-02 3:26 ` d.v.a at ngs dot ru
@ 2011-08-03 18:53 ` jason at gcc dot gnu.org
2011-08-03 19:17 ` schaub.johannes at googlemail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-03 18:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011.08.03 18:52:08
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
Summary|Various non-conforming |[DR 1214] Various
|behaviors with |non-conforming behaviors
|braced-init-list |with braced-init-list
|initialization |initialization
Ever Confirmed|0 |1
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (6 preceding siblings ...)
2011-08-03 18:53 ` [Bug c++/47453] [DR 1214] " jason at gcc dot gnu.org
@ 2011-08-03 19:17 ` schaub.johannes at googlemail dot com
2011-08-05 19:16 ` jason at gcc dot gnu.org
2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-08-03 19:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #7 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-08-03 19:17:04 UTC ---
(In reply to comment #6)
> >
> > You can define it as follows to make it work in both cases
> >
> > #define PTHREAD_COND_INITIALIZER {}
>
> I cannot define/redefine this value. It's already defined in system headers...
Ah I wasn't aware. You can at least workaround it though.
class cond_variable
{
struct { ::pthread_cond_t cond; } wrapper;
public:
constexpr cond_variable() : wrapper{PTHREAD_COND_INITIALIZER} {}
};
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (7 preceding siblings ...)
2011-08-03 19:17 ` schaub.johannes at googlemail dot com
@ 2011-08-05 19:16 ` jason at gcc dot gnu.org
2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-05 19:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:15:27 UTC ---
Author: jason
Date: Fri Aug 5 19:15:25 2011
New Revision: 177480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177480
Log:
PR c++/47453
* typeck.c (build_x_compound_expr_from_list): Also complain
about ({...}).
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist56.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist13.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist50.C
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (8 preceding siblings ...)
2011-08-05 19:16 ` jason at gcc dot gnu.org
@ 2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-05 19:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.7.0
--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:37:30 UTC ---
Implemented for 4.7.0. Currently this diagnostic is a pedwarn, i.e. only an
error with -pedantic-errors.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-08-05 19:38 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
2011-01-25 5:21 ` schaub.johannes at googlemail dot com
2011-05-12 5:57 ` schaub.johannes at googlemail dot com
2011-07-29 6:09 ` d.v.a at ngs dot ru
2011-07-29 12:24 ` schaub.johannes at googlemail dot com
2011-08-02 3:26 ` d.v.a at ngs dot ru
2011-08-03 18:53 ` [Bug c++/47453] [DR 1214] " jason at gcc dot gnu.org
2011-08-03 19:17 ` schaub.johannes at googlemail dot com
2011-08-05 19:16 ` jason at gcc dot gnu.org
2011-08-05 19:38 ` jason at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).