Okay, the latest branch still works with clang, and so does
gc-7_2-hotfix-3
But I don't see how "volatile" in the line
volatile word dummy[CLEAR_SIZE];
adds any clarity. It's confusing, because dummy refers
to an ordinary memory location, not an I/O port or a register, and
we aren't worried about interference from other threads. The only
access to dummy is through BZERO, so there is no apparent compiler
optimization to be feared.
On Aug 2, 2012, at 6:48 AM, Ivan Maidanski <ivmai at mail.ru> wrote:
> Hi Daniel,
>> 1. I removed almost dummy variables (together with volatile, of course).
> 2. For clarity (and to prevent potential compiler optimizations), volatile should remain.
> 3. I'm not going to prepare a cumulative patch, if you need to fix some other BDWGC source, just apply these 3 patches (not sure that they can be applied to gc7.3alpha2 smoothly):
>https://github.com/ivmai/bdwgc/commit/d6acbda22a4f5bdf4340edacdccf01cc7e38aea8>https://github.com/ivmai/bdwgc/commit/57b94a38df8026868010ec2ea0f47cd1f94f0c60>https://github.com/ivmai/bdwgc/commit/f1f2d378a04ac3f1be330ea6df6e553295657e22>> 4. I've applied the patches to release-7_2 candidate branch as well, please test it: https://github.com/ivmai/bdwgc/tree/gc-7_2-hotfix-3>> Regards,
> Ivan
>> Wed, 1 Aug 2012 18:24:25 -0400 "Grayson, Daniel R." <dan at math.uiuc.edu>:
>> That worked for clang.
>>>> But what about undoing the commit that inserted all the "volatile" attributes?
>> For clarity.
>>>> On Aug 1, 2012, at 6:10 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
>>>>> Hi Hans and Daniel,
>>>>>> You're right.
>>> Done another commit (a group of). Please check it once more.
>>>>>> I finally realized that GC_approx_sp not only clarifies but also fixes (this is not related to compiler optimizations) the algorithm of GC_clear_stack_inner for STACK_GROWS_UP case.
>>>>>> Regards,
>>> Ivan
>>>>>> Wed, 1 Aug 2012 17:12:23 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
>>>> Ivan -
>>>>>>>>>>>>>>>> Since it's the address, and not the value of dummy that's used, I wouldn't have expected that to have any impact. I think that switching to GC_approx_sp() clarifies the code and avoids the problem. It does so at a tiny performance cost, but I doubt that's ever noticeable.
>>>>>>>>>>>>>>>> I didn't look carefully at the other changes, but I think they have similar issues. I don't see how volatile helps either. The problem here is that I think C officially disallows comparisons of pointers to different objects. Hence GC_clear_stack() doesn't play by the rules. But so long as the compiler doesn't know where the pointers are coming from, it has to generate the expected code, and things will work.
>>>>>>>>>>>>>>>> An alternative would be to write more of this in assembly code, but that's a pain to maintain.
>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
>>>>>>>>> On Behalf Of Grayson, Daniel R.
>>>>>>>>> Sent: Wednesday, August 01, 2012 5:02 AM
>>>>>>>>> To: Ivan Maidanski
>>>>>>>>> Cc: gc at linux.hpl.hp.com>>>>>>>>> Subject: Re: [Gc] cc under mac os x
>>>>>>>>>>>>>>>>>> That doesn't help. I.e., with Apple clang version 4.0, the gc tests
>>>>>>>>> still fail.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2012, at 7:09 AM, Ivan Maidanski <ivmai at mail.ru> wrote:
>>>>>>>>>>>>>>>>>>> Hi Daniel,
>>>>>>>>>>>>>>>>>>>> I've added volatile to dummy, could you please check the code (master
>>>>>>>>> branch): https://github.com/ivmai/bdwgc/>>>>>>>>>> (The patch itself is:
>>>>>>>>>https://github.com/ivmai/bdwgc/commit/d6acbda22a4f5bdf4340edacdccf01cc7>>>>>>>>> e38aea8)
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>>> Mon, 30 Jul 2012 20:31:04 -0400 от "Grayson, Daniel R."
>>>>>>>>> <dan at math.uiuc.edu>:
>>>>>>>>>>> That works (with Apple clang version 4.0).
>>>>>>>>>>>>>>>>>>>>>> On Jul 30, 2012, at 8:25 PM, "Boehm, Hans" <hans.boehm at hp.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Maybe we should just call GC_approx_sp() instead of taking the
>>>>>>>>> address of dummy? This is all very heuristic, so being off by a few
>>>>>>>>> bytes here shouldn't matter.
>>>>>>>>>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Grayson, Daniel R. [mailto:dan at math.uiuc.edu]
>>>>>>>>>>>>> Sent: Monday, July 30, 2012 4:48 PM
>>>>>>>>>>>>> To: Boehm, Hans
>>>>>>>>>>>>> Cc: gc at linux.hpl.hp.com>>>>>>>>>>>>> Subject: Re: [Gc] cc under mac os x
>>>>>>>>>>>>>>>>>>>>>>>>>> The problem is that the comparison
>>>>>>>>>>>>>>>>>>>>>>>>>> (word)(&dummy[0]) > (word)limit
>>>>>>>>>>>>>>>>>>>>>>>>>> in GC_clear_stack_inner is optimized by -O2 to the constant value
>>>>>>>>> FALSE
>>>>>>>>>>>>> (1). Same
>>>>>>>>>>>>> for any comparison of those two pointers. The only solution I see
>>>>>>>>> is
>>>>>>>>>>>>> to
>>>>>>>>>>>>> pass &dummy[0] through an identity function compiled in another
>>>>>>>>> file,
>>>>>>>>>>>>> so the
>>>>>>>>>>>>> optimizer can't see it. That works.
>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 30, 2012, at 5:56 PM, "Boehm, Hans" <hans.boehm at hp.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note that GC_clear_stack_inner() is a tiny piece of non-portable
>>>>>>>>>>>>> code. It would be nice to understand why this is failing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't understand the limit value. It's computed in
>>>>>>>>> GC_clear_stack
>>>>>>>>>>>>> from GC_approx_sp(), which should return the stack pointer. It
>>>>>>>>> should
>>>>>>>>>>>>> be a few K less than the stack pointer. It doesn't look like it.
>>>>>>>>>>>>> Stepping through GC_clear_stack() the first time it's called might
>>>>>>>>> be
>>>>>>>>>>>>> helpful.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is also code that can break with excessively clever whole
>>>>>>>>>>>>> program analysis. It recourses until the stack pointer is below a
>>>>>>>>>>>>> certain value. If the compiler manages to recognize that the
>>>>>>>>> function
>>>>>>>>>>>>> is tail recursive (which we intentionally make hard), the stack
>>>>>>>>> may not
>>>>>>>>>>>>> actually grow as a result of the recursion, causing this to loop
>>>>>>>>>>>>> forever.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stubbing out GC_clear_stack_inner() completely (just return arg)
>>>>>>>>>>>>> should only introduce a performance issue. That may also be worth
>>>>>>>>>>>>> trying.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: gc-bounces at linux.hpl.hp.com [mailto:gc-
>>>>>>>>>>>>>bounces at linux.hpl.hp.com]
>>>>>>>>>>>>>>> On Behalf Of Grayson, Daniel R.
>>>>>>>>>>>>>>> Sent: Sunday, July 29, 2012 11:59 AM
>>>>>>>>>>>>>>> To: gc at linux.hpl.hp.com>>>>>>>>>>>>>>> Subject: [Gc] cc under mac os x
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I discovered today that libgc doesn't work with /usr/bin/cc
>>>>>>>>> under
>>>>>>>>>>>>>>> Mac OS X 10.8. I usually use gcc, so having it work with cc is
>>>>>>>>> not
>>>>>>>>>>>>>>> important to me, but it might be to others.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Most of the tests fail with a segmentation fault. Gdb shows a
>>>>>>>>> deep
>>>>>>>>>>>>>>> recursion:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #0 0x0000000100011086 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>>>>>>>> limit=0x7fff5fbfa0a0 "") at misc.c:306
>>>>>>>>>>>>>>> #1 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #2 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #3 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #4 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #5 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #6 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #7 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #8 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #9 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #10 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>> #11 0x0000000100011096 in GC_clear_stack_inner (arg=0x0,
>>>>>>>>> limit=0x6a8
>>>>>>>>>>>>>>> <Address 0x6a8 out of bounds>) at misc.c:308
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Gc mailing list
>>>>>>>>>>>>>>>Gc at linux.hpl.hp.com>>>>>>>>>>>>>>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Gc mailing list
>>>>>>>>>>>Gc at linux.hpl.hp.com>>>>>>>>>>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>> Gc mailing list
>>>>>>>>>Gc at linux.hpl.hp.com>>>>>>>>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>>>>>>>>>>>>>> _______________________________________________
>> Gc mailing list
>>Gc at linux.hpl.hp.com>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/>>