Barry Smith <[email protected]> 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?
pgp1qxiYZw4dT.pgp
Description: PGP signature
