[Gc] cc under mac os x

[Grayson, Daniel R.]

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/
>> 
>>