Dear list, On Wed, 30 Oct 2013 03:45:55 -0700 (PDT) Volker Braun <vbraun.n...@gmail.com> wrote: > I still don't understand why -WALL makes the error go away. Presumably > there is some compiler warning that gets erroneously parsed in ATLAS' > tuning system. As long as nobody who can reproduce this debugs it further, > it will never get fixed upstream.
Atlas' install.txt reads: "If you can't use the cycle-accurate wall timer, the normal WALL timer is still much more accurate than the CPU timer, and you can use it by adding this to configure: -D c -DWALL" WALL being defined, causes time00 to be ATL_walltime instead of ATL_cputime in matime.c. This causes xdma to output "3e-04\n4e-04 \n4e-04" instead of "0e+00\n0e+00\n0e+00" at "-m 1 -t 12" (i.e. at 1 MFLOPS of computation). My guess is that ATL_walltime is either a slower call or has higher resolution than ATL_cputime, so that outputting 0e +00 is avoided. If I modify matime.c to output "0" instead of "0e+00", running xmasrch proceeds without errors without -DWALL. I haven't tried a full build with that modification though as I have some deadlines, and therefore no time to figure out how to keep my modification from being moved to old/. Regards, Erik Massop -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
