On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote:> 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 add gcc 4.8 support: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170127.htmlPeter, Thanks. With the second patch applied, current dragonegg 3.3svn builds under FSF gcc 4.8.1svn with the plugin header fix applied. There appears to be a regression 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 _wake_dfsn2_ in ccZmJVlP.o ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status and the second as... % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 rnflow.f90 -o rnflow Undefined symbols for architecture x86_64: "_iroundf", referenced from: _cmpmat_ in ccaC6IRb.o _MAIN__ in ccaC6IRb.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Jack> > Part of that patch has already been applied. I gather that Duncan > has been busy with conference organisation so it may take some time > for him to review the rest of it. > > Thanks, > -- > Peter
Hi Jack, On 09/05/13 18:21, Jack Howarth wrote:> On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: >> 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 add gcc 4.8 support: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170127.html > > Peter, > Thanks. With the second patch applied, current dragonegg 3.3svn builds under FSF gcc 4.8.1svn > with the plugin header fix applied. There appears to be a regression 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 aermoddoes 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 ccZmJVlP.o > _averev_ in ccZmJVlP.o > _wake_dfsn2_ in ccZmJVlP.o > ... > ld: symbol(s) not found for architecture x86_64 > collect2: error: ld returned 1 exit status > > and the second as... > > % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 rnflow.f90 -o rnflow > Undefined symbols for architecture x86_64: > "_iroundf", referenced from: > _cmpmat_ in ccaC6IRb.o > _MAIN__ in ccaC6IRb.o > ld: symbol(s) not found for architecture x86_64 > collect2: error: ld returned 1 exit status > > Jack > >> >> Part of that patch has already been applied. I gather that Duncan >> has been busy with conference organisation so it may take some time >> for him to review the rest of it. >> >> Thanks, >> -- >> Peter
On Thu, May 09, 2013 at 12:21:30PM -0400, Jack Howarth wrote:> On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > > 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 add gcc 4.8 support: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170127.html > > Peter, > Thanks. With the second patch applied, current dragonegg 3.3svn builds under FSF gcc 4.8.1svn > with the plugin header fix applied. There appears to be a regression 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: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 given the above information about what this function does? Thanks, -- Peter
On Sat, May 11, 2013 at 02:55:44PM -0700, Peter Collingbourne wrote:> On Thu, May 09, 2013 at 12:21:30PM -0400, Jack Howarth wrote: > > On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > > > 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 add gcc 4.8 support: > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170127.html > > > > Peter, > > Thanks. With the second patch applied, current dragonegg 3.3svn builds under FSF gcc 4.8.1svn > > with the plugin header fix applied. There appears to be a regression 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: > > 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 > given the above information about what this function does?Peter, I believe this bug is triggered by the following change to gcc 4.8.0. http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01100.html The testcase from that patch exposes the issue... % cat iround.f90 function my_nint(x) implicit none real :: x integer :: my_nint my_nint = nint(x) end function my_nint % /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -c iround.f90 % nm iround.o | grep iround % % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -c iround.f90 % nm iround.o | grep iround U _iroundf % % /sw/lib/gcc4.7/bin/gfortran -c iround.f90 % nm iround.o | grep iround % % /sw/lib/gcc4.8/bin/gfortran -c iround.f90 % nm iround.o | grep iround % So only gfortran 4.8.0 with dragonegg seems to generate this undefined symbol for iroundf. Jack> > Thanks, > -- > Peter
On Sat, May 11, 2013 at 09:53:08PM +0200, Duncan Sands wrote:> Hi Jack, > > On 09/05/13 18:21, Jack Howarth wrote: >> On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: >>> 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 add gcc 4.8 support: >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170127.html >> >> Peter, >> Thanks. With the second patch applied, current dragonegg 3.3svn builds under FSF gcc 4.8.1svn >> with the plugin header fix applied. There appears to be a regression 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 > > does it happen without -specs=/sw/lib/gcc4.8/lib/integrated-as.specs ? >Yes this undefined symbol also occurs without -specs=/sw/lib/gcc4.8/lib/integrated-as.specs. I believe this breakage in dragonegg with gcc 4.8.0 is fallout from the change... http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01100.html Jack> 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 ccZmJVlP.o >> _averev_ in ccZmJVlP.o >> _wake_dfsn2_ in ccZmJVlP.o >> ... >> ld: symbol(s) not found for architecture x86_64 >> collect2: error: ld returned 1 exit status >> >> and the second as... >> >> % /sw/lib/gcc4.8/bin/gfortran -fplugin=/sw/lib/gcc4.8/lib/dragonegg.so -specs=/sw/lib/gcc4.8/lib/integrated-as.specs -O1 rnflow.f90 -o rnflow >> Undefined symbols for architecture x86_64: >> "_iroundf", referenced from: >> _cmpmat_ in ccaC6IRb.o >> _MAIN__ in ccaC6IRb.o >> ld: symbol(s) not found for architecture x86_64 >> collect2: error: ld returned 1 exit status >> >> Jack >> >>> >>> Part of that patch has already been applied. I gather that Duncan >>> has been busy with conference organisation so it may take some time >>> for him to review the rest of it. >>> >>> Thanks, >>> -- >>> Peter