[Gc] cc under mac os x

[Grayson, Daniel R.]

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