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