Re[11]: [Gc] cc under mac os x
Ivan Maidanski
ivmai at mail.ru
Thu Aug 2 05:04:19 PDT 2012
Hi Daniel,
Thu, 2 Aug 2012 07:48:38 -0400 "Grayson, Daniel R." <dan at math.uiuc.edu>:
> Okay, the latest branch still works with clang, and so does
>
> gc-7_2-hotfix-3
>
> But I don't see how "volatile" in the line
>
> volatile word dummy[CLEAR_SIZE];
>
> adds any clarity. It's confusing, because dummy refers
> to an ordinary memory location, not an I/O port or a register, and
> we aren't worried about interference from other threads. The only
> access to dummy is through BZERO, so there is no apparent compiler
> optimization to be feared.
BZERO could be redirected to builtin_memset thus the code:
word dummy[SIZE];
BZERO(dummy, sizeof(dummy));
could turn into:
dummy[0] = 0;
...
dummy[SIZE-1] = 0;
and, since there is no readers of dummy, it is a dead code and code be wiped out.
'volatile' says that dummy is used by some other party and the compiler is not allowed to remove any dummy[i] = 0;
Regards,
Ivan
>
>
> On Aug 2, 2012, at 6:48 AM, Ivan Maidanski <ivmai at mail.ru> wrote:
>
> > 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