Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

code calling memcpy.asm

Ryan_Smith
Beginner
765 Views
Why is my code randomly calling memcpy.asm? And what is memcpy.asm? It appears to be happening when character variables are assigned a value, but only sometimes. Any ideas?
0 Kudos
5 Replies
TimP
Honored Contributor III
765 Views
Unless you can specify a compiler and show a small example, I don't see how we can mention more than generalities. It's usual for a Fortran compiler to call a memcpy type library function when implementing a variable or long length string assignment.
0 Kudos
nvaneck
New Contributor I
765 Views
Quoting - tim18
Unless you can specify a compiler and show a small example, I don't see how we can mention more than generalities. It's usual for a Fortran compiler to call a memcpy type library function when implementing a variable or long length string assignment.

It irritates me, too. It seems to be called for every character assignment I use, large or small. It used to be a simple MVC in assembler, but now with variaous other language contraints it seems to be called all the time. Good thing computers have gotten much faster and memory much cheaper....
0 Kudos
nvaneck
New Contributor I
765 Views
Quoting - nvaneck

It irritates me, too. It seems to be called for every character assignment I use, large or small. It used to be a simple MVC in assembler, but now with variaous other language contraints it seems to be called all the time. Good thing computers have gotten much faster and memory much cheaper....

In fact, I just tested assigning one exact 10-character string to another and it took 39 assembler steps to do it. Fortunately, it only takes 8 steps when optimized. My irritation comes from inadvertently trying to step through code and suddenly getting thrown into memcpy.asm before I catch myself...
0 Kudos
IanH
Honored Contributor II
765 Views
Quoting - nvaneck
My irritation comes from inadvertently trying to step through code and suddenly getting thrown into memcpy.asm before I catch myself...

Are you using Step Into (F11) or Step Over (F10)? I see this behaviour only when using Step Into (so its justifiable in that sometimes it is handy to be able to debug inside the runtime) on a character assignment when the source and destination lengths match exactly (ie CHARACTER(10) :: ten_chars; ten_chars = '1234567890').

Depending on your version of Visual Studio, you might be able to explicitly tell the debugger not to go into the memcpy call: http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx. Just putting "memcpy" in the data for a new string value in the relevant key seems to work under VS2005. Newer versions of VS might allow you to do this a little more transparently.

Solution properties also include directories for the debugger to search (which by default include the C-runtime source directories that contains memcpy.asm) - not sure of the signficance of that here, but I've vague recollections that I've used this on a C++ project previously to avoid this sort of problem. When I experimented today debugging Fortran code I didn't have any luck and I found at least the exclude files part of that dialog appears to be buggy. Others may know better.

If you have unintentionally landed in the runtime source, then Step Out (Shift-F11) should get you back to recognisable territory pretty quickly

0 Kudos
nvaneck
New Contributor I
765 Views
Quoting - IanH

Are you using Step Into (F11) or Step Over (F10)? I see this behaviour only when using Step Into (so its justifiable in that sometimes it is handy to be able to debug inside the runtime) on a character assignment when the source and destination lengths match exactly (ie CHARACTER(10) :: ten_chars; ten_chars = '1234567890').

Depending on your version of Visual Studio, you might be able to explicitly tell the debugger not to go into the memcpy call: http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx. Just putting "memcpy" in the data for a new string value in the relevant key seems to work under VS2005. Newer versions of VS might allow you to do this a little more transparently.

Solution properties also include directories for the debugger to search (which by default include the C-runtime source directories that contains memcpy.asm) - not sure of the signficance of that here, but I've vague recollections that I've used this on a C++ project previously to avoid this sort of problem. When I experimented today debugging Fortran code I didn't have any luck and I found at least the exclude files part of that dialog appears to be buggy. Others may know better.

If you have unintentionally landed in the runtime source, then Step Out (Shift-F11) should get you back to recognisable territory pretty quickly


Sure could step over, but usually I'm stepping through a bit more rapidly and watching variable changes, until it's too late. Not a major issue, just an annoyance I have yet to train myself out of...:)

Thanks for the tip on Shift-F11!
0 Kudos
Reply