[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 Scott A. Colcord sacolcor at provide dot net changed: What|Removed |Added CC||sacolcor at provide dot net --- Comment #8 from Scott A. Colcord sacolcor at provide dot net 2011-09-14 14:59:01 UTC --- Now that regex has been ratified as part of the C++11 standard, shouldn't failure to support it be considered a bug? At the least, it seems like a WONTFIX status isn't appropriate, because (as I understand it) WONTFIX means that even if someone were to offer to do the work, there's no interest in accepting it into the tree.
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #12 from Scott A. Colcord sacolcor at provide dot net 2011-09-14 15:36:46 UTC --- As long as std::regex is still on the todo list, that resolves my concern. And I would love to be able to help; if you can give me a couple of extra hours in my day, I'll happily devote them to developing this feature. :-P
[Bug c++/44277] New: [C++0x] Add warning to facilitate nullptr conversion.
C++0x introduces the 'nullptr' constant, intended to replace a literal '0' for null pointers. Support for nullptr is being (has been?) added to gcc 4.6. However, for backward compatibility reasons, '0' will remain convertible to pointer type for the foreseeable future. As grepping for '0' is likely to be unfeasibly noisy, it would be helpful if a warning could be enabled to detect the use of '0' as a pointer type. -- Summary: [C++0x] Add warning to facilitate nullptr conversion. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sacolcor at provide dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44277
[Bug c++/33979] support for char16_t, char32_t
--- Comment #18 from sacolcor at provide dot net 2009-12-14 21:36 --- Should the library support for this be split into a separate bug? Or two bugs, if libstdc++ and glibc both need to handle the new types? -- sacolcor at provide dot net changed: What|Removed |Added CC||sacolcor at provide dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #3 from sacolcor at provide dot net 2009-05-21 13:56 --- Reopening, because if this is by design, the doc page at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html should elaborate; it does not currently mention anything about incompatibility or other difficulties with -no-integrated-cpp or -save-temps. The supplied code compiles fine if the -no-integrated-cpp flag is removed, and it seems reasonable for a user to expect that those flags would not cause an otherwise working build to break. Are precompiled headers simply incompatible with those flags? If not, then what's needed to make them work? -- sacolcor at provide dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug pch/40215] GCH generated with -save-temps does not store preprocessor state.
--- Comment #5 from sacolcor at provide dot net 2009-05-21 18:21 --- (In reply to comment #4) How can the PCH contain information that is lost by using an external preprocessor? When I do -save-temps, it's still using the GNU CPP, not an external one, so it's not clear to me why information would be lost. I'll update the summary line so that it's clear that I'm not using an external preprocessor. When a .h.gch is built in one pass, the integrated preprocessor takes the preprocessor symbol state at the end of the file and passes it through (or around) the compile and assemble phases to be stored in the .h.gch file. It seems like the CPP should do the same thing when invoked as part of the -save-temps chain; embed that same information in the .i* files. Then when the compiler phase sees it, it could pass it through and store that information in the .h.gch. Perhaps I need to understand more about how the PCH system works; I looked for that information in the internal doc, but could not find anything. -- sacolcor at provide dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Generated GCH fails to honor|GCH generated with -save- |include guards with -no-|temps does not store |integrated-cpp |preprocessor state. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug pch/40215] New: Generated GCH for c++ file fails to honor include guards with -no-integrated-cpp
Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sacolcor at provide dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #1 from sacolcor at provide dot net 2009-05-21 02:06 --- (Adjusting summary; additional testing revealed that this is not confined to C++) -- sacolcor at provide dot net changed: What|Removed |Added Summary|Generated GCH for c++ file |Generated GCH fails to honor |fails to honor include |include guards with -no- |guards with -no-integrated- |integrated-cpp |cpp | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug libstdc++/20534] New: Erroneous #include of cassert
gcc/libstdc++-v3/include/debug/debug.h:272 reads: #include cassert // TBD: temporary Is this temporary include still needed? It causes most uses of STL to pull in the assert header, which means that programs can (and have) failed to compile on versions of the compiler without this bug. -- Summary: Erroneous #include of cassert Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sacolcor at provide dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20534
[Bug libstdc++/20534] Erroneous #include of cassert
--- Additional Comments From sacolcor at provide dot net 2005-03-18 20:57 --- I'm working on it, but it may take me a where to track it down to a minimal case. You're correct in that this is legal behavior for a conforming compiler; the actual core problem is that because gcc (and most other compilers) #includes some standard headers in others, it's possible to write code that is invalid (because it does not #include all of the necessary headers) but have it still compile without a diagnostic. Thus, it breaks when moved to a compiler with a different internal library header configuration. In this case, the change was the debug header rework performed between v3.3.2 and v3.4.0. It was the obvious temporary label on that line that led me to believe that it was erroneous; if it needs to stay there, it probably shouldn't be tagged that way (or should indicate what its intended lifetime is). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20534
