Re[5]: [Gc] cc under mac os x

[Ivan Maidanski]

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