The DSCR is heterogeneous, that is, there are two fundamentally different types of machines within it (in addition to a variety of CPU speeds) -- 32-bit and 64-bit machines.
The older, 32-bit, machines will only run 32-bit executables. The newer, 64-bit, machines will run either 64-bit or 32-bit executables. The older, 32-bit, front-ends (dscr-login-01 and dscr-login-02) will only compile 32-bit executables. The newer, 64-bit, front-ends (dscr-login-03 and dscr-login-04) will only compile 64-bit executables.
Note the difference there: 64-bit machines will run either kind of executable but can only compile 64-bit ones.
dscr-login-01 or dscr-login-02
dscr-login-03 or dscr-login-04
% qsub -l arch=*-amd64
This means you have to be careful where you compile your code and where you run it. You may want to adopt some simple system to keep 32- and 64-bit executables separate from each other, even just renaming them or keeping them in separate subdirectories will work. E.g. instead of 'myprog.exe', use 'myprog.i686.exe' and 'myprog.x86_64.exe'.
In Linux, you can use the "uname -p" command -- it will show 'i686' for 32-bit machines and 'x86_64' for 64-bit machines. From within SGE job scripts, you can check the value of the environment variable "$ARC" -- it will be 'lx26-x86' for 32-bit machines and 'lx26-amd64' for 64-bit machines. You may want to include something like this in your .cshrc file:
setenv BITSIZE `uname -p`
Then you can use myprog.$BITSIZE.exe as your executable name and it will work for either bit-size.
Note that the 64 DSCR "Core" nodes (shared by all users) are 32-bit machines and hence cannot run 64-bit programs.
Note also that the Unix make utility is easily confused. When it sees file.o, it will assume that the file is the correct type and will NOT compile it again -- even if it is the wrong bit-size! As a precaution, always do "rm *.o" or "make clean" before you compile for another platform.