search for: _iround

...n in the Polyhedron 2005 benchmarks for aermod and rnflow. The first fails to compile with the errror... % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 aermod.f90 -o aermod Undefined symbols for architecture x86_64: "_iround", referenced from: _stodbl_ in ccZmJVlP.o _evper_ in ccZmJVlP.o "_iroundf", referenced from: _aver_ in ccZmJVlP.o _vdp_ in ccZmJVlP.o _stonum_ in ccZmJVlP.o _terrst_ in ccZmJVlP.o _hrqext_ in ccZmJVlP.o _averev_ in ccZmJVlP.o _w...

...> benchmarks for aermod and rnflow. The first fails to compile with the errror... > > % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 aermod.f90 -o aermod > Undefined symbols for architecture x86_64: > "_iround", referenced from: I looked into this briefly. I think iround is some kind of gcc intrinsic (like the lround function in C, except it returns an int). I don't have access to that benchmark suite nor do I know Fortran very well. Can you try to construct a small reproducing test case give...

...; > % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 aermod.f90 -o aermod does it happen without -specs=/sw/lib/gcc4.8/lib/integrated-as.specs ? Ciao, Duncan. > Undefined symbols for architecture x86_64: > "_iround", referenced from: > _stodbl_ in ccZmJVlP.o > _evper_ in ccZmJVlP.o > "_iroundf", referenced from: > _aver_ in ccZmJVlP.o > _vdp_ in ccZmJVlP.o > _stonum_ in ccZmJVlP.o > _terrst_ in ccZmJVlP.o > _hrqext_ in...

...005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current >> FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 >> which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this skews the geometric mean >> of the run time to much higher values. > > I also didn't hook up LLVM's new fast-math optimizations yet, which I expect to > make a big difference. Duncan, Is current dragonegg 3.3...

On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > Duncan, > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic > to work around without some additional substitute being added in FSF gcc upstream? Hi Jack, There's a patch under review to

Duncan, I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic to work around without some additional substitute being added in FSF gcc upstream? Jack

...the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this skews the geometric mean of the run time to much higher values. Jack Tested on x86_apple-darwin12 Compile Flags: -ffast-math -funroll-loops -O3 de-gfortran47: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dr...