Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7956 Discussions

Can compile source code but incorrect executable

twcdynetix_com
Beginner
418 Views
I'm trying the icc and icpc (11.0) compiler on my software product on Red Hat Enterprise Linux v4.7.
The software compiled OK, but when I ran it I got incorrect results, I'd tried -O3, -02, -O1 and -Os
they all failed. The only option works is -O0.

Pl. help?


icc -DLINUX -DLINUX9 -DSUN -DSOLARIS -DJDK1_1_1 -Wno-deprecated -static -DSUSE -L/opt/intel/Compiler/11.0/081/lib/intel64 -O1 -DNO_THREAD -DNO_REG -DNO_JAVA -DDQOUT -DPRODUCTION ../o5/a.o ../o5/b.o ../o5/msg.o -o ../exe/vcdgen -lm -L../lib -lnsl -lcxaguard -ldecimal -lguide -lguide_stats -limf -liomp5 -liompprof5 -liompstubs5 -lipgo -lirc -lirc_s -lompstub -lsvml -lstdc++ -lm


Terry Chan
0 Kudos
1 Solution
TimP
Honored Contributor III
418 Views
Quoting - twcdynetix.com

icc -DLINUX -DLINUX9 -DSUN -DSOLARIS -DJDK1_1_1 -Wno-deprecated -static -DSUSE -L/opt/intel/Compiler/11.0/081/lib/intel64 -O1 -DNO_THREAD -DNO_REG -DNO_JAVA -DDQOUT -DPRODUCTION ../o5/a.o ../o5/b.o ../o5/msg.o -o ../exe/vcdgen -lm -L../lib -lnsl -lcxaguard -ldecimal -lguide -lguide_stats -limf -liomp5 -liompprof5 -liompstubs5 -lipgo -lirc -lirc_s -lompstub -lsvml -lstdc++ -lm

If you're so tempted to link all the alternate libraries together, please desist, and use the compiler options to make a choice. There's no reason to link any of the OpenMP or OpenMP stub libraries, if you haven't set -openmp or -parallel. Likewise, there's no need for -lsvml if you use similar compile and link options, and no need for -lstdc++ -lm if you use icpc to drive the link.
If the objective, hinted at in some other replies, is to use options resembling MSVC++, you should consider which options you use for that compiler and pick something similar for icpc. If using /fp:fast for MSVC++, consider -fp-model source, or, if using the VC default /fp:precise, use -fp-model precise. -O1 is OK if the intention is to avoid auto-vectorization. Certainly, if you find that optimization causes your code to break, you should try one of those -fp-model options, as well as trying icpc -diag-enable sc to hunt for problems.
There's no way we can know the meaning of all those defines, but I would be concerned that LINUX9 might mean Red Hat 9, and so would probably conflict with SUSE.

View solution in original post

0 Kudos
2 Replies
Om_S_Intel
Employee
418 Views

We could help you if you can share your test acse with us. You could also submit the issue to Intel Premier support at http://premier.intel.com.
0 Kudos
TimP
Honored Contributor III
419 Views
Quoting - twcdynetix.com

icc -DLINUX -DLINUX9 -DSUN -DSOLARIS -DJDK1_1_1 -Wno-deprecated -static -DSUSE -L/opt/intel/Compiler/11.0/081/lib/intel64 -O1 -DNO_THREAD -DNO_REG -DNO_JAVA -DDQOUT -DPRODUCTION ../o5/a.o ../o5/b.o ../o5/msg.o -o ../exe/vcdgen -lm -L../lib -lnsl -lcxaguard -ldecimal -lguide -lguide_stats -limf -liomp5 -liompprof5 -liompstubs5 -lipgo -lirc -lirc_s -lompstub -lsvml -lstdc++ -lm

If you're so tempted to link all the alternate libraries together, please desist, and use the compiler options to make a choice. There's no reason to link any of the OpenMP or OpenMP stub libraries, if you haven't set -openmp or -parallel. Likewise, there's no need for -lsvml if you use similar compile and link options, and no need for -lstdc++ -lm if you use icpc to drive the link.
If the objective, hinted at in some other replies, is to use options resembling MSVC++, you should consider which options you use for that compiler and pick something similar for icpc. If using /fp:fast for MSVC++, consider -fp-model source, or, if using the VC default /fp:precise, use -fp-model precise. -O1 is OK if the intention is to avoid auto-vectorization. Certainly, if you find that optimization causes your code to break, you should try one of those -fp-model options, as well as trying icpc -diag-enable sc to hunt for problems.
There's no way we can know the meaning of all those defines, but I would be concerned that LINUX9 might mean Red Hat 9, and so would probably conflict with SUSE.
0 Kudos
Reply