Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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*