[petsc-dev] CFLAGS and COPTFLAGS

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>    Yes, What if they just set a single flag having nothing to do with
>    optimization. This will turn off PETSc’s attempt to provide any
>    kind of optimization flag (even with —with-debugging=0). I think
>    this is bad. *

Is it really that bad?  Other packages usually don't try to do anything
smart and I think there is a very real cost to second-guessing the user.
Worse, the user has to wait minutes for configure to complete before
reading the printout carefully to learn what PETSc decided to use.

I think we still want warning flags because users are unlikely to guess
decent ones.  And -fPIC needs to be automatic based on shared libs.

>>>   Could we do the following?
>>> 
>>>   Look through any provided CFLAGS (FFLAGS, CXXFLAGS) if we detect
>>>   something that looks like optimization then act as if COPTFLAGS was
>>>   set and do not set our own optimization default flag? We can also
>>>   keep support for the COPTFLAGS stuff
>>> 
>>>   We can look for -O%d , are there other things to look for?  This seems easy enough to add.
>> 
>> -ftree-vectorize, -fast, -qhot -qsimd=auto
>
>    So if they pass -fast then we simply don’t set any optimization flags ourself? We could do that.

My point was that there are *lots* of optimization flags, with new ones
every release from every vendor.  We could test for a few, but can never
be comprehensive.  Do we want to be in this business?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140117/b52d7d61/attachment.sig>