[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

2009-05-19 Thread jeff at schwabcenter dot com
--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 --- What he said. I'm perusing your patch, and I appreciate that you removed an artificial restriction. The right place to catch this is up front, in a concept check, rather than in _Destroy; since I'm not ab

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

2009-05-19 Thread jeff at schwabcenter dot com
--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 --- OK. Thanks for the explanation. Are the semantics documented somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

2009-05-19 Thread jeff at schwabcenter dot com
--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 --- I understand the desire for backward compatibility, but are the semantics actually the same? Are the vector values arrays, or do they decay to pointers? Section 23.1 says standard container elements have to be

[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types

2009-05-19 Thread jeff at schwabcenter dot com
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 --- Whoa whoa whoa... The behavior seemed correct before. vector shouldn't even be legal. Shouldn't the compiler to catch such a mistake? -- jeff at schwabcenter dot com changed: What

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

2009-01-14 Thread jeff at schwabcenter dot com
--- Comment #2 from jeff at schwabcenter dot com 2009-01-14 19:20 --- I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1). #include #include using boost::bind; using std::multiplies; int main() { // Fine. int const lvalue = 5; bind(multiplies()

[Bug debug/35502] -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
--- Comment #7 from jeff at schwabcenter dot com 2008-03-07 23:43 --- http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html does not list -Wswitch-default being enabled by -Wall. -- jeff at schwabcenter dot com changed: What|Removed |Added

[Bug debug/35502] -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
--- Comment #6 from jeff at schwabcenter dot com 2008-03-07 23:42 --- > Is there any particular reason for changing the docs, rather than the code? Kindly disregard that question. I have just been informed by a co-worker that some of our third-party library headers include swi

[Bug debug/35502] -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
--- Comment #5 from jeff at schwabcenter dot com 2008-03-07 23:38 --- Thanks for the quick response and the links. FYI, the latter link seems to be broken: http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html Is there any particular reason for changing the docs

[Bug debug/35502] -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
--- Comment #2 from jeff at schwabcenter dot com 2008-03-07 23:24 --- Created an attachment (id=15278) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15278&action=view) Fix for this bug Setting warn_switch_default = value in the OPT_Wall case of c_common_handle_option (i

[Bug debug/35502] -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
--- Comment #1 from jeff at schwabcenter dot com 2008-03-07 23:21 --- Created an attachment (id=15277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15277&action=view) Preprocessed sample code Compiling the attached file with g++ -Wall should produce "warning: sw

[Bug debug/35502] New: -Wall should include -Wswitch-default

2008-03-07 Thread jeff at schwabcenter dot com
Mar 7 12:17:25 2008 -- Summary: -Wall should include -Wswitch-default Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot