[Gc] cc under mac os x

Grayson, Daniel R. dan at math.uiuc.edu
Thu Aug 2 08:00:12 PDT 2012 

Good point!  I didn't think of that optimization.

On Aug 2, 2012, at 8:04 AM, Ivan Maidanski <ivmai at mail.ru> wrote:

> Hi Daniel,
> 
> Thu, 2 Aug 2012 07:48:38 -0400 "Grayson, Daniel R." <dan at math.uiuc.edu>:
>> 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.
> 
> BZERO could be redirected to builtin_memset thus the code:
> 
> word dummy[SIZE];
> BZERO(dummy, sizeof(dummy));
> 
> could turn into:
> 
> dummy[0] = 0;
> ...
> dummy[SIZE-1] = 0;
> 
> and, since there is no readers of dummy, it is a dead code and code be wiped out.
> 
> 'volatile' says that dummy is used by some other party and the compiler is not allowed to remove any dummy[i] = 0;
> 
> Regards,
> Ivan
> 
>> 
>> 
>> 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/
>>>> 
>> 
>>

More information about the Gc mailing list