[Bug c++/53500] New: internal compiler error in joust()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 Bug #: 53500 Summary: internal compiler error in joust() Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3

[Bug c++/53500] internal compiler error in joust()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #2 from Paul Pogonyshev pogonyshev at gmx dot net 2012-05-27 19:33:35 UTC --- (In reply to comment #1) I don't see it being attached. Apparently it got eaten as too large. Please see http://rghost.net/38322304

[Bug c++/53500] internal compiler error in joust()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500 --- Comment #6 from Paul Pogonyshev pogonyshev at gmx dot net 2012-05-27 20:03:40 UTC --- Created attachment 27508 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27508 much reduced testcase not using any libraries other than libstdc++ gcc

[Bug libstdc++/49384] istringstream::tellg at the end of string gives a wrong result

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49384 --- Comment #2 from Paul Pogonyshev pogonyshev at gmx dot net 2011-06-13 20:09:49 UTC --- So, changing in a way incompatible to what the standard says is intended? Or am I (and pre-4.6 libstdc++) misreading the standard?

[Bug libstdc++/49384] New: istringstream::tellg at the end of string gives a wrong result

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49384 Summary: istringstream::tellg at the end of string gives a wrong result Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits

--- Comment #2 from pogonyshev at gmx dot net 2010-03-27 14:36 --- I'm sorry, but why? Isn't the compiler the same? What is the point of not providing good type traits if you can? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43549

[Bug c++/43549] TR1 type_traits are much worse than C++0x type_traits

--- Comment #4 from pogonyshev at gmx dot net 2010-03-27 19:33 --- From info: ...some of which have been implemented in an experimental C++0x mode in GCC. Instead of maintaining a separate piece of code you could have one just include another so that they are the same and be done

[Bug c++/43549] New: TR1 type_traits are much worse than C++0x type_traits

type_traits Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pogonyshev at gmx dot net http://gcc.gnu.org/bugzilla

[Bug c++/43368] New: different access to templated structure static field give different results

Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pogonyshev at gmx dot net GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC

[Bug c++/42203] New: std::copy() results to a call to memmove() and is not inlined in trivial cases

() and is not inlined in trivial cases Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pogonyshev at gmx dot net GCC target

[Bug c++/42203] std::copy() results to a call to memmove() and is not inlined in trivial cases

--- Comment #1 from pogonyshev at gmx dot net 2009-11-28 01:22 --- Created an attachment (id=19166) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19166action=view) source code of the program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42203

[Bug c++/42203] std::copy() results to a call to memmove() and is not inlined in trivial cases

--- Comment #2 from pogonyshev at gmx dot net 2009-11-28 01:23 --- Created an attachment (id=19167) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19167action=view) disassemble results for main() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42203

[Bug c++/24056] failed lookup of static non-member operator function with certain templated arguments

--- Comment #5 from pogonyshev at gmx dot net 2006-10-12 18:58 --- OK, thanks for the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056

[Bug c++/24056] failed lookup of static non-member operator function with certain templated arguments

--- Additional Comments From pogonyshev at gmx dot net 2005-09-25 16:20 --- Created an attachment (id=9805) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9805action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056

[Bug c++/24056] New: failed lookup of static non-member operator function with certain templated arguments

Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pogonyshev at gmx dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc

[Bug c++/24056] failed lookup of static non-member operator function with certain templated arguments

--- Additional Comments From pogonyshev at gmx dot net 2005-09-25 16:54 --- So, not a bug then? I still don't understand why this code is ill-formed, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056

[Bug libstdc++/23494] New: std::basic_string capacity weirdness

Version: 3.2 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pogonyshev at gmx dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org

[Bug libstdc++/23494] std::basic_string capacity weirdness

--- Additional Comments From pogonyshev at gmx dot net 2005-08-20 18:48 --- Because it defeats the effect of reserve() call on `s1'. I'm not saying I know how to avoid it, but I wonder if there is some strict policy behind `std::basic_string' reallocation behavior in GNU STL. Maybe