gcc trunk already produced a warning, and libstdc++ trunk was already fixed. On Feb 17, 2012 12:14 AM, "Jeffrey Yasskin" <[email protected]> wrote:
> On Tue, Feb 14, 2012 at 12:44 PM, Richard Smith <[email protected]> > wrote: > > On Sat, Feb 11, 2012 at 3:51 PM, Sebastian Redl > > <[email protected]> wrote: > >> > >> Author: cornedbee > >> Date: Sat Feb 11 17:51:47 2012 > >> New Revision: 150318 > >> > >> URL: http://llvm.org/viewvc/llvm-project?rev=150318&view=rev > >> Log: > >> Represent C++ direct initializers as ParenListExprs before semantic > >> analysis > >> instead of having a special-purpose function. > >> > >> - ActOnCXXDirectInitializer, which was mostly duplication of > >> AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few > days > >> ago), is dropped completely. > >> - MultiInitializer, which was an ugly hack I added, is dropped again. > >> - We now have the infrastructure in place to distinguish between > >> int x = {1}; > >> int x({1}); > >> int x{1}; > > > > > > g++4.6 has a bug where it silently accepts "t({...})" as if it were a > > brace-or-init-list initializer in a constructor's member initializer > list. > > By the law of nature that for every g++ "extension" there is an equal and > > opposite libstdc++ bug, libstdc++ 4.6's <bitset> uses this syntax to > > initialize its member array in C++11 mode. Is it feasible to downgrade > the > > error in this particular case to an ExtWarn? > > Please also file gcc bugs in cases like this. They're generally happy > to try to fix gcc-trunk so more instances don't pop up in the future. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
