[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 --- Whoa whoa whoa... The behavior seemed correct before. vectorfloat[4] shouldn't even be legal. Shouldn't the compiler to catch such a mistake? -- jeff at schwabcenter dot com changed: What|Removed |Added CC||jeff at schwabcenter dot com 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
--- 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 CopyConstructible and assignable, but raw arrays are neither. Is there at least some flag to re-enable the diagnostic? If you're saying this is a necessary evil for reasons of backward compatibility, then I understand, but in my opinion, this is a step backward that will confuse newcomers like Brian and hurt cross-compatibility. Speaking strictly as a GCC user, I don't see any reason to reduce the compiler's ability to deduce an obvious mistake with ill-defined semantics. -- 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
--- 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
--- 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 about to add the check myself, I'm hardly in a position to criticize. The diagnostic did have the nice property of catching a real, semantic error, though, and it seems a shame to let a known error go unreported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- 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 boost/bind.hpp
#include functional
using boost::bind;
using std::multiplies;
int main() {
// Fine.
int const lvalue = 5;
bind(multipliesint(),4,_1)(lvalue);
// Mistaken for a cast.
bind(multipliesint(),4,_1)(5);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug debug/35502] New: -Wall should include -Wswitch-default
The g++ man page says -Wall is equivalent to All of the above -W
options combined. The -Wswitch-default option should therefore be included in
-Wall, but currently is not.
The correct solution IMO is to add -Wswitch-default to -Wall in c-opts.c.
Please see the attached patch.
Script started on Fri Mar 7 12:16:38 2008
~$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++
--prefix=/export/home/jeff/opt/gcc
Thread model: posix
gcc version 4.2.4 20080214 (prerelease)
~$ g++ -Wall -Wswitch-default main.cc
main.cc: In function 'int main(int, char**)':
main.cc:1: warning: switch missing default case
~$ g++ -Wall main.cc -save-temps
~$ cat main.ii
# 1 main.cc
# 1 built-in
# 1 command-line
# 1 main.cc
int main(int argc, char** argv) { switch (argc) { } }
Script done on Fri 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 org
ReportedBy: jeff at schwabcenter dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- 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=15277action=view) Preprocessed sample code Compiling the attached file with g++ -Wall should produce warning: switch missing default case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- 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=15278action=view) Fix for this bug Setting warn_switch_default = value in the OPT_Wall case of c_common_handle_option (in gcc/c-opts.c) fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- 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, rather than the code? Include Wswitch-default in Wall is intuitive to me, and avoiding the warning is straight-forward (if not trivial). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- 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 switch statements without default cases, so adding -Wswitch-default to -Wall would make our lives more difficult, anyway. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- 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 Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
