[m-dev.] GCC 4.6, 4.7 and parallel grades

[Paul Bone]

On Tue, Jul 02, 2013 at 10:58:45PM +1000, Julien Fischer wrote:
> On Tue, Jul 2, 2013 at 9:09 PM, Paul Bone <paul at bone.id.au> wrote:
> 
> >
> > A user reported to me a bug whereby a program (not even a parallel one) can
> > crash (segfault) in a parallel low-level C grade.
> >
> > I've narrowed this down to GCC 4.6 and 4.7, (maybe later versions too), and
> > the -freorder-functions optimisation that is enabled at -O2.  I think that
> > calling a clusure is somehow involved - perhaps it's what is required to
> > make the bug come to the surface.
> >
> > Does anyone know how these three things: -freorder-functions,
> > parallelism/thread safty and closures may cause such a program.  In
> > particular do we at any point rely on the order that functions appear in an
> > executable's .text area?  This may just be an edge case that we havn't hit
> > before with Mercury's use of non-local gotos.
> >
> > I've disassembled both object files (working and broken) for the same
> > program and diffed them, there's no difference.  There is a difference in
> > the disassembly of the _init.o file, the main function is placed in a new
> > section named .text.startup.  I can't imagine how this could contribute to
> > the problem.
> 
> 
> What about in the object file for the runtime?  (Particularly, any contain
> code
> that deals with closures.)
> 

I could fix the problem by changing the C options for the application alone.
In both cases the runtime and standard library were identical.  This was the
mandelbrot application, which is quite small and if executed with the right
(default?) options doesn't even call list.map.  The closure that triggered the
bug was called from mandelbrot.my_map, which is the same as list map but
included in the application for auto-parallelism tests.


-- 
Paul Bone
http://www.bone.id.au