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

Ivan Maidanski ivmai at mail.ru
Thu Aug 2 03:48:59 PDT 2012


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