This makes more sense now. I'll look into changing the help messages on
the configure script, and check whether my environment is somehow injecting
flags. It's good to know that lower optimization levels take priority.
Dave
On Wed, Oct 4, 2017 at 7:01 AM, Jason Swails <jason.swails.gmail.com> wrote:
> On Wed, Oct 4, 2017 at 1:02 AM, David Cerutti <dscerutti.gmail.com> wrote:
>
> > Hello devs,
> >
> > I've historically been a heavy user of the configure -debug option,
> which I
> > just read is supposed to set -noopt.
>
>
> I fixed that. This was true in the past, but I disabled that so that
> -debug just added debugging symbols to the binaries and -noopt was required
> to turn off optimizations. The rationale for this is that debugging an
> optimized binary is very useful when tracking down issues related to
> obscure bugs that only manifest with optimizations (or as has been the case
> a couple times, compiler optimization bugs).
>
> For instance, this is how I hunted down a weird bug in pmemd TI that I
> fixed in lines 2194 to 2205 of ti.F90 (basically look for wherever you see
> "volatile" in the F90 source code that's needed to prevent compilers from
> optimizing away certain variables that end up resulting in buggy machine
> code -- this shows up a few times in sander as well).
>
> The debugger helpfully told me that those variables were optimized away.
> There are certainly caveats to debugging an optimized binary (since it's
> much harder to draw correspondence between the source code and instructions
> in the binary), but it is still frequently useful.
>
>
> > (I had been explicitly setting -noopt
> > with -debug). But when I do compile I see a lot of stuff like this:
> >
> > gfortran -DBINTRAJ -DEMIL -DPUBFFT -g -O0 -O3 -DCUDA
> > -I/home/cerutti/amber/include -c runmin.F90
> > gfortran -DBINTRAJ -DEMIL -DPUBFFT -g -O0 -O3 -DCUDA
> > -I/home/cerutti/amber/include -c veclib.F90
> > gfortran -DBINTRAJ -DEMIL -DPUBFFT -g -O0 -O3 -DCUDA
> > -I/home/cerutti/amber/include -c gb_alltasks_setup.F90
> >
> > What's up with -O0 -O3?
>
>
> I looked everywhere in configure2. -O0 is only ever set inside an
> "optimize="no"" conditional block, and nowhere in the configure script do
> the debug conditional blocks do anything but set debug compiler flags.
> Maybe AMBERBUILDFLAGS or some other environment variable you set is
> injecting -O3 or -O0. Do you have global CFLAGS/FFLAGS set? Could those
> be adding -O0 or -O3? configure2 does now respect those environment
> variables, so if you have some kind of pre-set development environment
> variables (FC, CC, CXX, CFLAGS, FFLAGS, ...), those will get injected into
> the final config.h file.
>
>
> > It looks like the optimizations are not really
> > being suppressed as advertised. Can someone with better knowledge of the
> > configure script weigh in here, or perhaps indicate how to fix this? I
> > haven't run into any actual problems with regard to the -O3 when I try to
> > use valgrind and gdb, but still...
> >
>
> I believe -O0 always overrides -O3 (as opposed to "last-one-wins"),
> although you should check the compiler docs to verify if necessary.
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Oct 04 2017 - 13:30:03 PDT
