dragonegg vs -ffast-math?

I am finding that llvm 2.8 rc3 with dragonegg svn built against current
gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting
to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error...

f951: Unknown command line argument '--enable-finite-only-fp-math'. Try: 'f951 -help'

The standard gcc 4.5.2 gfortran compiler has no problem with that option.
       Jack

Hi Jack,

   I am finding that llvm 2.8 rc3 with dragonegg svn built against current
gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting
to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error...

f951: Unknown command line argument '--enable-finite-only-fp-math'. Try: 'f951 -help'

The standard gcc 4.5.2 gfortran compiler has no problem with that option.
        Jack

I've fixed this in commit 115781. The fix will be in the dragonegg 2.8 release,
which should come out sometime this week.

Ciao,

Duncan.

Hi Jack,

> I am finding that llvm 2.8 rc3 with dragonegg svn built against current
> gcc-4_5-branch doesn't appear to allow gfortran to use -ffast-math. Attempting
> to compile code using the dragonegg plugin under gcc 4.5.2 with that option produces the error...
>
> f951: Unknown command line argument '--enable-finite-only-fp-math'. Try: 'f951 -help'
>
> The standard gcc 4.5.2 gfortran compiler has no problem with that option.
> Jack

I've fixed this in commit 115781. The fix will be in the dragonegg 2.8 release,
which should come out sometime this week.

Ciao,

Duncan.

Duncan,
   Thanks. I can confirm this is in fact fixed in current dragonegg svn. On a different
question, what are the prospects getting aermod to compile under dragonegg? I am still
seeing compile failures of the form...

de-gfortran45 -ffast-math -funroll-loops -msse3 -O3 aermod.f90 -o aermod
Assertion failed: ((NumParams == FTy->getNumParams() || (FTy->isVarArg() && NumParams > FTy->getNumParams())) && "Calling a function with bad signature!"), function init, file /sw/src/fink.build/llvm-clang-2.8-1/llvm-2.8/lib/VMCore/Instructions.cpp, line 242.
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.

This also seems to be the same failure preventing capacita.f90, gas_dyn.f90, induct.f90, protein.f90, rnflow.f90 and
test_fpu.f90 from compiling.
         Jack

Hi Jack,

    Thanks. I can confirm this is in fact fixed in current dragonegg svn. On a different
question, what are the prospects getting aermod to compile under dragonegg? I am still
seeing compile failures of the form...

de-gfortran45 -ffast-math -funroll-loops -msse3 -O3 aermod.f90 -o aermod
Assertion failed: ((NumParams == FTy->getNumParams() || (FTy->isVarArg()&& NumParams> FTy->getNumParams()))&& "Calling a function with bad signature!"), function init, file /sw/src/fink.build/llvm-clang-2.8-1/llvm-2.8/lib/VMCore/Instructions.cpp, line 242.
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.

This also seems to be the same failure preventing capacita.f90, gas_dyn.f90, induct.f90, protein.f90, rnflow.f90 and
test_fpu.f90 from compiling.

this is caused by bogusness coming out of the Fortran front-end. For example,
it likes to declare functions that take four integer parameters, but at call
sites only one parameter is passed, an array of four integers. Inside gcc this
all comes out in the wash somehow (I don't know how the inliner sorts this kind
of thing out...), but in dragonegg it triggers the assertions you see.

I have a grand plan for fixing this, which will also result in no gcc patches
being needed any more on linux, what a deal! I've started on it; my goal is
to have it ready for 2.9.

Ciao,

Duncan.

Jack,

This also seems to be the same failure preventing capacita.f90, gas_dyn.f90, induct.f90, protein.f90, rnflow.f90 and
test_fpu.f90 from compiling.

This might be a long-standing fortran frontend bug where bogus trees
were created. It was specially workarounded in llvm-gcc.

Jack,

> This also seems to be the same failure preventing capacita.f90, gas_dyn.f90, induct.f90, protein.f90, rnflow.f90 and
> test_fpu.f90 from compiling.
This might be a long-standing fortran frontend bug where bogus trees
were created. It was specially workarounded in llvm-gcc.

Anton,
   Have you considered looking up that bug in FSF gcc bugzilla and pinging it?
The gfortran developers may have forgotten about it and perhaps it could be
addressed by them for gcc 4.6 (as they are still in stage 1 for a few more weeks).
          Jack

Jack,

Have you considered looking up that bug in FSF gcc bugzilla and pinging it?
The gfortran developers may have forgotten about it and perhaps it could be
addressed by them for gcc 4.6 (as they are still in stage 1 for a few more weeks).

Well, that bug is in bugzilla since gcc 4.2. Since it does not
influence "stock" gcc I
doubt they will mark it as high priority.

Jack,

> Have you considered looking up that bug in FSF gcc bugzilla and pinging it?
> The gfortran developers may have forgotten about it and perhaps it could be
> addressed by them for gcc 4.6 (as they are still in stage 1 for a few more weeks).
Well, that bug is in bugzilla since gcc 4.2. Since it does not
influence "stock" gcc I
doubt they will mark it as high priority.

Anton,
   The gfortran developers have been cleaning up their interactions with the
middle end though. Do you have the PR number handy?
              Jack

The gfortran developers have been cleaning up their interactions with the
middle end though. Do you have the PR number handy?

Yes, 33097