http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-29 11:49:09 UTC --- (In reply to comment #9) > Even though the proposed patch seems to be a proper solution, to me it seems > to > be that using -fpermissive just to come around this particular error is > allowing other non-confirming code to compile as well, which may not be > desired > in many situations (for instance, assigning a const pointer to a non-const > pointer would not be regarded as an error). Yup. Some compilers allow every single backwards-compatibility feature to be controlled by a separate option. The cost of developing, testing and maintaining that is enormous. > In my case, I have modified the patch to throw a warning instead, but probably > the best solution would be to add a sort of > -fno-constexpr-initialization-check > flag. I read that the previous GCC extension is deprecated now, but it is > important to take into account that then it would be hard to use c++11 with > older code, just because of details like this one. That older code wasn't valid in C++03 either, and relied on an extension which was deprecated many years ago. That sounds like exactly the sort of situation -fpermissive is for. Rather than changing the effect on this extension, I'd prefer if -fpermissive was changed to reject some truly *ancient* features which haven't been supported without -fpermissive by any version of G++ since 3.0
