Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: [OMPI users] Addendum to: Assembler instruction errors for push and pop during make
From: Richard Haney (rfhaney_at_[hidden])
Date: 2013-08-19 01:18:24

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.
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

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 <rfhaney_at_[hidden]>
Date: Sat, Aug 17, 2013 at 9:29 PM
Subject: Assembler instruction errors for push and pop during make
To: users_at_[hidden]
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
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 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*