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

Ivan Maidanski ivmai at mail.ru
Wed Aug 1 15:10:25 PDT 2012


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



More information about the Gc mailing list