Ivan Maidanski
2016-01-05 07:40:28 UTC
Hello Mike,
About upgrade of libgc to v7+: I'm preparing a patch in GCC trunk to polish libgc API to match that of bdwgc master. Though it does not seem to be complete (I haven't checked even whether it is buildable), you could get it (a set of patches actually) from
https://github.com/ivmai/gcc/tree/match-bdwgc-api
Regards,
Ivan
About upgrade of libgc to v7+: I'm preparing a patch in GCC trunk to polish libgc API to match that of bdwgc master. Though it does not seem to be complete (I haven't checked even whether it is buildable), you could get it (a set of patches actually) from
https://github.com/ivmai/gcc/tree/match-bdwgc-api
Regards,
Ivan
[Adding Ivan, the current bdwgc maintainer.]
I don't fully understand the issue here. Do we understand where the problem is coming from? Are the compiler/linker generating misaligned pointers someplace? That would strike me as a misfeature elsewhere.
Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer. It causes the gc to look for pointers at every 2 byte offset, quadrupling the number of potential pointers that are tested, and significantly increasing the risk of finding "false" pointers. I would expect more problems caused by large block allocations.
Hans
I don't fully understand the issue here. Do we understand where the problem is coming from? Are the compiler/linker generating misaligned pointers someplace? That would strike me as a misfeature elsewhere.
Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer. It causes the gc to look for pointers at every 2 byte offset, quadrupling the number of potential pointers that are tested, and significantly increasing the risk of finding "false" pointers. I would expect more problems caused by large block allocations.
Hans
This bug doesn't exist in the more recent boehm-gc 7.2 or
later releases. Until the exact change from 6.6 to 7.2 that suppresses
this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
version or later, the simple fix to suppress this issue on darwin is
to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
that target.
It would be nice to just pull in 7.2 (or just the latest release)âŠÂ seems like that should be easier to maintain to me.later releases. Until the exact change from 6.6 to 7.2 that suppresses
this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
version or later, the simple fix to suppress this issue on darwin is
to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
that target.
Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?
Iâd like to punt the approval to a libboehm person, though, not sure we have any. Just checked we donât have an official maintainer listed. :-( Do we have anybody that wants to review the patch or should I? Though I would prefer a new import of a newer library to fix the issue, Iâm tempted to just approve the patch. Kinda donât want to as any deviation makes importing a new library annoying. What do others think?