On 05/29/2015 07:31 AM, Martin Liška wrote:
On 05/28/2015 07:15 PM, Jeff Law wrote:
On 05/28/2015 06:49 AM, Martin Liška wrote:
.
This mechanism has been just adapted. I find it quite useful as we have
examples in source code where we
allocate same struct/class types from a various pool. For debugging
purpose, it helps to identify if
release operation is called for a correct pool.
I saw that you were following existing practice for the pools in the
removal patch. I still don't like it as it makes mixing and matching
objects harder when debugging gcc and if the structure is exposed for
plugins, then we've got an unnecessary ABI plugin breakage.
I certainly understand how it's useful -- I'm not questioning that.
I'm questioning changing the size of structures on ENABLE_CHECKING.
My first inclination would be to include all that stuff
unconditionally. If that's too much overhead, then perhaps include
the structure member, but not bother with any of the bookkeeping
except for ENABLE_CHECKING.
Hi.
Updated version of patch removes ENABLE_CHECKING in the struct definition.
News in the patchset I'm going to re-send:
+ Changelog entries are fixed for spaces
+ Each patch passes ./contrib/check_GNU_style.sh script
+ pool_allocator::pool_allocator is a trivial constructor and first
allocation launches initialization
+ some patches are squashed as were mentioned multiple time
(ira-color.c, ira-build.c)
The patch set survives x86_64-linux-pc boostrap, I'm going to re-run
regression tests.
Sounds perfect. Once the regression testing is done, the whole set is
fine for the trunk.
Thanks for tackling this.
jeff
