Re: [pooma-dev] OpenMP status

[Jeffrey D. Oldham]

Richard Guenther wrote:

> On Tue, 24 Aug 2004, Jeffrey D. Oldham wrote:
>
>  
>
> > Richard Guenther wrote:
> >
> >    
> >
> > > Together with the last fixes OpenMP with the Intel Compiler 8.0
> > > on a 4-processor Itanium passes all regression tests in optimized
> > > mode apart from:
> > >
> > > - array_test5: compiler problem, if compiling with -mp it's fine
> > > - ScalarCode: compiler problem, sometimes works, sometimes generates
> > > unaligned access and abort()s (look for kernel messages)
> > >
> > >
> > >      
> > If it sometimes works, are we sure it is a compiler problem?  Is it
> > instead a race condition?
> >    
>
> I'm sure it's not a race condition, but a problem in the generated
> code as that does unaligned memory access which the Itanium seems to
> do not like:
>
>  
>
> > dmesg
> >    
> ScalarCode(23238): unaligned access to 0x2000000001200ca5,
> ip=0x20000000003fe670
> ScalarCode(23238): unaligned access to 0x2000000001200cad,
> ip=0x20000000003fe671
> ScalarCode(23238): unaligned access to 0x2000000001200c9d,
> ip=0x20000000003fe690
> ScalarCode(23267): unaligned access to 0x2000000000566b06,
> ip=0x20000000003fe7a1
>
> It's at the lowest optimization level the compiler does any
> OpenMP stuff, so I can't really check otherwise.
>
> From gdb I see it's
>
> (gdb) run
> Starting program:
> /net/alwazn/home/rguenth/src/pooma-bk/r2/src/Field/tests/LINUXICC/ScalarCode
> [Thread debugging using libthread_db enabled]
> [New Thread 2305843009213887952 (LWP 23722)]
> [New Thread 2305843009219836112 (LWP 23723)]
> [New Thread 2305843009224030416 (LWP 23724)]
> [New Thread 2305843009228224720 (LWP 23725)]
> [New Thread 2305843009232419024 (LWP 23726)]
> ScalarCode(23722): unaligned access to 0x2000000000566b07,
> ip=0x20000000003fe7a1
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 2305843009213887952 (LWP 23722)]
> 0x20000000003fd630 in _int_malloc () from /lib/tls/libc.so.6.1
> (gdb) bt
> #0  0x20000000003fd630 in _int_malloc () from /lib/tls/libc.so.6.1
> #1  0x20000000003fb760 in malloc () from /lib/tls/libc.so.6.1
> #2  0x2000000000268d10 in operator new () from /usr/local/lib/libcxa.so.6
> #3  0x4000000000119c90 in
> _ZN22UniformRectilinearMeshILi2EdEC9ERKS0_RK8IntervalILi2EE ()
> #4  0x40000000001a3640 in
> _ZN11FieldEngineI22UniformRectilinearMeshILi2EdEd9BrickViewEC9Id10MultiPatchI7GridTag5BrickEEERKS_IS1_T_T0_ERK5INodeILi2EE
> ()
> #5  0x400000000018aab0 in
> View1Implementation<Field<UniformRectilinearMesh<2, double>, double,
> MultiPatch<GridTag, Brick> >, INode<2>, false>::make<INode<2>,
> CombineDomainOpt<TemporaryNewDomain1<Interval<2>, INode<2> >, false> > ()
> #6  0x400000000018adb0 in View1<Field<UniformRectilinearMesh<2, double>,
> double, MultiPatch<GridTag, Brick> >, INode<2> >::make ()
> #7  0x40000000001cd3a0 in
> MultiArgEvaluator<MultiPatchEvaluatorTag>::evaluate<MultiArg2<Field<UniformRectilinearMesh<2,
> double>, double, MultiPatch<GridTag, Brick> >,
> Field<UniformRectilinearMesh<2, double>, double, Brick> >,
> AllFaceToCellAverage<2>, 2, EvaluateLocLoop<AllFaceToCellAverage<2>, 2> >
> ()
> #8  0x40000000001374e0 in
> MultiArgEvaluator<MainEvaluatorTag>::evaluate<MultiArg2<Field<UniformRectilinearMesh<2,
> double>, double, MultiPatch<GridTag, Brick> >,
> Field<UniformRectilinearMesh<2, double>, double, Brick> >,
> AllFaceToCellAverage<2>, 2, EvaluateLocLoop<AllFaceToCellAverage<2>, 2> >
> ()
> #9  0x40000000000d9bd0 in ScalarCode<AllFaceToCellAverage<2>
>  
>
> > ::operator()<Field<UniformRectilinearMesh<2, double>, double,
> >    
> MultiPatch<GridTag, Brick> >, Field<UniformRectilinearMesh<2, double>,
> double, Brick> > ()
> #10 0x40000000000082d0 in main ()
>
> not inside any OpenMP parallelized region (only maybe directly preceding).
> And it may be bad interaction between the installed libc and the Intel
> Compiler.  Who knows.
>  
OK.  Thanks for the analysis.

--
Jeffrey D. Oldham
address@hidden