[Bug libstdc++/51008] New: GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 Bug #: 51008 Summary: GTHR - extend interface with __gthread_recursive_mutex_destroy Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: andv...@gmail.com This is not a direct libstdc++ bug, but an interface issue of gthreads. I haven't found a similar bug report except for #46455. The issue appears because in libstdc++-v3/include/ext/concurrence.h in d-tor of __recursive_mutex class, when a custom GTHR implementation is used (We have to provide one for a legacy non-POSIX OS). According to SVN, the problem still exists in branch 4.6 and trunk. I can propose two solutions: 1. Add __gthread_recursive_mutex_destroy and get rid of _S_destroy template hacks. 2. Add a new macro __GTHREAD_RECURSIVE_MUTEX_DESTROY_FUNCTION. If the macro is defined by GTHR implementation then __mutex d-tor shall call it instead of _S_destroy hacks. It shall be also a good solution for Win32 and other custom destructors. IMO, the first one is the most correct. The second is suitable to maintain backward compatibility and is the least risky. I can provide a patch for the second approach, if needed.
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #1 from Andrey Galkin 2011-11-07 13:52:36 UTC --- * The problem is in incompatible types when __gthread_mutex_destroy is called instead of __gthread_recursive_mutex_destroy (missing in the default interface) in __recursive_mutex::_S_destroy.
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 --- Comment #5 from Andrey Galkin 2011-11-07 14:28:56 UTC --- Created attachment 25736 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25736 PR51008 workaround, fits GCC 4.6.2
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 Andrey Galkin changed: What|Removed |Added Severity|major |minor --- Comment #6 from Andrey Galkin 2011-11-07 14:29:16 UTC --- Actually, I'm quite OK applying my custom patch (attached) during toolchain build, but it could be useful for others. Changing importance to minor.
[Bug c++/51060] New: Temporary object stack space is not re-used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51060 Bug #: 51060 Summary: Temporary object stack space is not re-used Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: andv...@gmail.com Created attachment 25769 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25769 10 tmp objects of 1KB in size produce 10KB frame I've tried hard finding a related incident, the only one close to it is PR 16269, but its solution doesn't help. Attached is a sample test, which allocates 10 temporary objects of 1KB size in own blocks in the same function. If compiled with "-Wframe-larger-than=2048 -Werror -Os" (-Oany) the following warning is produced: warning: the frame size of 10240 bytes is larger than 2048 bytes [-Wframe-larger-than=] In our case, function frames are blown away for 100+KB, what makes a code with similar pattern absolutely unusable in embedded systems. Reproduced on GCC 4.6.1 x86_64 @ Debian and custom built GCC 4.6.2 for ARM. The same issue exists in GCC 4.3.x for ARM.
