> Am 22.09.2016 um 17:20 schrieb Mahmood Naderan <mahmood...@gmail.com>: > > Although this problem is not related to OMPI *at all*, I think it is good to > tell the others what was going on. Finally, I caught the illegal instruction > :) > > Briefly, I built the serial version of Siesta on the frontend and ran it > directly on the compute node. Fortunately, "x/i $pc" from GDB showed that the > illegal instruction was a FMA3 instruction. More detail is available at > https://gcc.gnu.org/ml/gcc-help/2016-09/msg00084.html > > According to the Wikipedia, > > • FMA4 is supported in AMD processors starting with the Bulldozer > architecture. FMA4 was realized in hardware before FMA3. > • FMA3 is supported in AMD processors starting with the Piledriver > architecture and Intel starting with Haswell processors and Broadwell > processors since 2014. > Therefore, the frontend (piledriver) inserts a FMA3 instruction while the > compute node (Bulldozer) doesn't recognize it.
Thx for sharing, quite interesting. But does this mean, that there is no working command line flag for gcc to switch this off (like -march=bdver1 what Gilles mentioned) or to tell me what he thinks it should compile for? For pgcc there is -show and I can spot the target it discovered in the USETPVAL= line. -- Reuti > > The solution was (as stated by guys) building Siesta on the compute node. I > have to say that I tested all related programs (OMPI, Scalapack, OpenBLAS) > sequentially on the compute node in order to find who generate the illegal > instruction. > > Anyway... thanks a lot for your comments. Hope this helps others in the > future. > > > > Regards, > Mahmood > > > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/users _______________________________________________ users mailing list users@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/users
