On Dec 2, 2009, at 3:46 PM, strogdon wrote: > On Dec 2, 2:28 pm, François Bissey <f.r.bis...@massey.ac.nz> wrote: >> On Thu, 03 Dec 2009 08:03:44 strogdon wrote:> So, it would appear >> that it is not the CFLAGS but whether CFLAGS has >>> been set to something. The no-strict-aliasing is suspiciously >>> missing. >>> The documentation I have on gcc 4.3.4 indicates that optimization >>> levels O2 and O3 turn on strict-aliasing. Therefore if no-strict- >>> aliasing is needed to built sage spkg then this may be the problem. >>> But why for amd64 only? >> >> I am sure there are aliasing differences between x86 and amd64. >> So one may be more resilient than the other. >> If just adding -fno-strict-aliasing is solving the problem that >> would be >> nice, however you say tests are successful with CFLAGS unset and that >> the compiler is called with: >> gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict- >> prototypes -fPIC >> in that case. -O3 is after -fno-strict-aliasing so if -O3 turns on >> strict >> aliasing it should override the previous flag - unless I am very >> mistaken. >> If it is just a matter of strict aliasing you probably could add >> -fno-strict-aliasing at the end of your CFLAGS and see what happens. >> >> Francois > > Yes, I believe you are correct about what takes precedence. However, > when I set > > CFLAGS="-march=opteron -O2 -pipe -fno-strict-aliasing" > > sage and the documentation builds without error. Go figure this one > out?
Given it's the sage-x.y.z spkg, I would play around with scons and/or distutils to see if they're doing something funny with the C flags. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
