Handle -ffast-math

[certik]

#315 removed -ffast-math from default flags because it can cause problems. However, I still want to use it in my projects that work with it and makes them a lot faster. I opened this issue to brainstorm some ways to fix this.

One proposal is this: there will be a flag fast-math in fpm.toml that is false by default (if you omit it). If you set it to true, then you signal to fpm that your package works both with and without the -ffast-math flag.

When you run fpm build --release on a package, fpm will examine the fast-math flag in the current package as well as all the dependencies. If they are all true, then it builds everything with -ffast-math. If one of them is false, then it will not use the flag.

This proposal should get me what I would like, without breaking things for others. As an example, until we fix stdlib, we would not set its fast-math flag to true which will cause all programs that use it to be compiled without -ffast-math. Package maintainers and end users who do not want to be worried about this simply omit the fast-math flag in their fpm.toml which makes fpm never to compile with -ffast-math.

Possible issues:

• It is not well defined what exactly fast-math means for each compiler. We can overcome this by being practical: for each compiler that we support, we identify these so-called "unsafe" optimizations, and package maintainers that want to take advantage of fast-math (such as myself) will ensure that their package works with it.

[urbanjost]

So if I happen to use a case conversion routine from stdlib I cannot build with -ffast-math. That strongly discourages someone from using a lot of packages. Most such options can be used on a single file/routine without adverse affects in being mixed with other routines. I can compile up all my code with fast-math and still use standard system libraries and X11 Windows for example. Not all compiler options are like that, but most that have that issue are creating a specific file type, especially if a lot of package owners do not bother verifying their package can work with -ffast-math. Some options might be able to be flagged as "safe to mix". In those cases you could compile all the packages marked as --fast-math compatible instead of compiling nothing with the optimzation flag if one package indicates it is a problem. You would also want a relatively easy way to query the package, hopfully before incorporating into your package, to decide if you want to use it. I have not used gfortran for heavy lifting and primarily use it at home so I am not positive what can be mixed, but the same can apply to optimization levels, unrolling levels for loops, ... so for large packages there has to be more than an on-for-everyone, off-for-everyone option.

[awvwgk]

I would suggest we get #112 working for something simple like optimization levels and than extend on the syntax.

[hridyasadanand]

Hi, I would like to work on this issue as part of my GSoC preparation. Could you please provide some pointers on where to start?