generated code depends on where I compile?

[Laszlo_Ladanyi]

I have noticed something strange. We use icc version 2016.1.150 to compile our code. I have compiled the same source code on 4 different linux machines. All of them are running redhat, though different versions, and they have different hardware as well: ladanyi@mach1:/home/ladanyi$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.11 (Tikanga) mach1 cpu: Intel(R) Xeon(R) CPU X5160 ladanyi@mach2:/home/ladanyi$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.11 (Tikanga) mach2 cpu: Intel(R) Xeon(R) CPU X5260 ladanyi@mach3:/home/ladanyi$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) mach3 cpu: Intel(R) Xeon(R) CPU X5650 ladanyi@mach4:/home/ladanyi$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.0 (Maipo) mach4 cpu: Intel(R) Xeon(R) CPU E5-2630 v2 When I compile the very same code with the same compiler I get differently sized executables: ladanyi@mach1:/home/ladanyi/$ ls -l cplex-orwell* -rwxr-xr-x 1 ladanyi cplex 57712071 May 9 07:28 exe-mach1 -rwxr-xr-x 1 ladanyi cplex 57712071 May 9 09:05 exe-mach2 -rwxr-xr-x 1 ladanyi cplex 59260087 May 9 07:02 exe-mach3 -rwxr-xr-x 1 ladanyi cplex 59247186 May 9 09:10 exe-mach4 mach1 and mach2 are nearly identical (same cpu family, same OS) so the identical executable size is not surprising. The other two machines have very different hardware and have different OS level. The OS (and thus glibc) is different, so a small difference I could accept since, who knows..., maybe in one OS something is a macro, in the other one its a function, or an inlined function... there can be many reason. But 2MB? That looks a lot. Also, I have looked at the defined symbols in the executables using nm, and the list of symbols is the same. So I'm wondering whether the different CPU matter or not? Does icc perform different optimizations depending on the hardware? Thanks, --Laszlo PS: The flags used when compiling the source are: -gdwarf-2 -O -fno-builtin-strlen -fno-builtin-strcat -fno-builtin-strcmp -fno-builtin-strcpy -fno-builtin-strncat -fno-builtin-strncmp -fno-builtin-strrchr -m64 -DSSE2 -fPIC -fno-strict-aliasing -diag-disable 1419 -w1 -Wcheck -fvisibility=hidden -Wall -Wmissing-declarations -Wmissing-prototypes -Wshadow The flags used when linking are (INTEL=/opt/intel/Linux-x86_64/2016.1/compilers_and_libraries_2016.1.150/linux) -gdwarf-2 -static-intel -Wl,--start-group $INTEL/compiler/lib/intel64/libirc.a $INTEL/mkl/lib/intel64/libmkl_intel_lp64.a $INTEL/mkl/lib/intel64/libmkl_sequential.a $INTEL/mkl/lib/intel64/libmkl_core.a -Wl,--end-group -lm -lpthread -fPIC -fno-strict-aliasing -diag-disable 10237 -ldl -rdynamic -ldl

[Laszlo_Ladanyi]

BTW, if I build without -gdwarf-2, there is still a sizable difference in the executable size: mach1, with -gdwarf-2: 57657911 bytes mach1, w/o -gdwarf-2: 23197473 bytes mach3, with -gdwarf-2: 59210047 bytes mach3, w/o -gdwarf-2: 23713209 bytes --Laszlo

[KitturGanesh]

Hi Laszio,
Since you've not used any processor specific switch such as -xHOST the only other possibility one can think of is that the versions of GCC on the different systems could be different.  Since iCC is GNU based and relies on the GNU distro (uses its asm, ln etc) the compiler doesn't include replacements for std C++ headers (except for some very specific scenarios) and will use whatever comes on the system. And, if they are different the code generated by the compiler can be different as well and hence the code size can be different accordingly. 

Other than the above reasoning, the only other difference you may see is the timestamp/date and file paths included in the binaries and that again shouldn't be too significant of a difference thereof.  Hope that helps.

Kittur

[Laszlo_Ladanyi]

Problem solved. The gcc/glibc are indeed different on the different machines. When we have examined the object files generated by icc using readelf it turns out the .eh_frame section is responsible for all the differences in size. And that is dependent on glibc. Thanks for the suggestions! --Laszlo

[KitturGanesh]

Great, thanks for letting me know Laszio and glad it's resolved!

Cheers,
Kittur