Sorry about the last, attempted message being too large. I did not know that there was such a size limit. I am re-sending the last attempted message with the attachments removed. The relevant attachments were included with the original message with subject "Assembler instruction errors for push and pop during make". I would appreciate any help anyone can provide.
At present I am trying to brush up on assembly & machine coding concepts and to study the differences between 32-bit and 64-bit processing. Hopefully, that will allow me to create a fix for the problem. One hope is that, for the assembly programs in question, it does not matter whether they are assembled as 32-bit code "as is" with only an explicit invocation of the gnu assembler and a --32 flag adjustment or as 64-bit code with code adjustments. But at present that is just wishful thinking. Also, it is not clear whether building the OpenMPI package entirely as 32-bit code would limit my use of OpenMPI as a library to 64-bit programs or whether there would be a significant speed penalty. Here are some ideas that may lead to a solution, but I still need help solving this problem. http://stackoverflow.com/questions/6268745/invalid-instruction-suffix-for-push-when-assembling-with-gassuggests that the problem is caused by trying to assemble 32-bit assembly code in 64-bit mode and that an option of --32 would likely solve the problem. But in my case, would this solution create 32-bit/64-bit incompatibilities between object modules? There is also in the same source the suggestion "Prepend .code32 as your first line." But there are numerous .s modules in the openmpi-1.6.5 tree, and perhaps only some of them have this problem. Perhaps I could modify all such .s modules and then restore the time stamps so as not to confuse the makefiles. But the same question about 32-bit/64-bit incompatibilities arises. The only experience I have with assembler code is with an IBM 360 assembler (for debug tracebacks in Fortran) and embedded assembly code in Turbo Pascal and/or Turbo C/C++ coordinated with assembly output from those compilers for 8086 code and perhaps a machine-code-to-symbolic disassembler as well. I have only the vaguest idea how the gnu assembler works. There is in my C:\MinGW64\bin directory an assembler as.exe whose --version output says in part "This assembler was configured for a target of `x86_64-w64-mingw32'." There is described in "as --help" output the option: --32/--64/--x32 generate 32bit/64bit/x32 code Perhaps I could pass option --32 to the back-end assembler (as.exe ?) via the gcc option -Wa,--32 in CFLAGS, but it seems this would likely apply to back-end processing of all compilations and likely cause 32-bit/64-bit incompatibilities (especially with gfortran objects generated using the -m64 option). It seems also that this would largely negate the benefit of 64-bit processing even if no incompatibilities resulted. "configure --help" output indicates under "Some influential environment variables:" -- CCAS assembler compiler command (defaults to CC) CCASFLAGS assembler compiler flags (defaults to CFLAGS) Depending on how configure and its Makefiles work, perhaps I could use CCAS and perhaps CCASFLAGS to invoke as.exe specifically for the assembly .s source processing, but, if I use the flag --32 for the .s assembly programs, would this also create 32-bit/64-bit incompatibilities? -- *- Richard Haney* ---------- Forwarded message ---------- From: Richard Haney <rfha...@gmail.com> List-Post: users@lists.open-mpi.org Date: Sat, Aug 17, 2013 at 9:29 PM Subject: Assembler instruction errors for push and pop during make To: us...@open-mpi.org During make I get several instruction errors for push, pushl, pop, and popl at atomic-asm.S , which is included indirectly in asm.c . For example, for the first reported "Error", the instruction pushl %ebp apparently generates the error message atomic-asm.S:5: Error: invalid instruction suffix for `push' There are several more Error messages like that. --- And the instruction push %ebx apparently generates the error message atomic-asm.S:64: Error: operand type mismatch for `push' --- And the instruction pop %ebx apparently generates the error message atomic-asm.S:68: Error: operand type mismatch for `pop' --- And the instruction popl %ebp apparently generates the error message atomic-asm.S:75: Error: invalid instruction suffix for `pop' ----------------------------------------------- It seems worth noting that make does a symbolic link involving "atomic-asm.S" immediately before the processing of this file, which generates the errors, but the configure output reports checking whether ln -s works... no, using cp -p as if symbolic links will not be used. ---------------------------------------- The configure output was generated by executing the script file " mpiconfigure" via command *$ mpiconfigure &> openmpi-1.6.5_configure.out* "mpiconfigure" executes *export LD_LIBRARY_PATH=/c/MinGW64/lib/gcc/x86_64-w64-mingw32/4.6.1* just before executing ./configure ... so that I won't forget to set LD_LIBRARY_PATH . The make command used was *$ make -j 2 &> make_-j_2.out* I am using the Mingw MSYS 1.0 command-window/bash in a Windows 7 environment for processing the commands. The compilers are Mingw 64-bit as reported in config.log ; these are not "official" Mingw compiler versions, but supposedly are very nearly so -- see http://tdm-gcc.tdragon.net/ for details: configure:5375: gcc --version >&5 gcc.exe (tdm64-1) 4.6.1 configure:15880: g++ --version >&5 g++.exe (tdm64-1) 4.6.1 configure:28191: gfortran.exe --version >&5 GNU Fortran (tdm64-1) 4.6.1 The processor is an Intel Sandybridge i5, with capability for parallel execution of four threads. My guess is that these errors are due simply to a mismatch between the assembly instructions gcc can understand and the assembly instructions that OpenMPI assumes gcc can understand. Is there some flag I can set to tell gcc that a particular assembly language (dialect) is being used? And, if so, can I set it for make without having to re-run configure? -- *- Richard Haney* * *
