Wierd intrinsic function behaviour VS2010, is this a bug?

Question

4.00/5 (1 vote)

See more:

VS2010

, +

I have code like this

void* __cdecl memcpy( void* dest, const void* src, size_t count );
char* __cdecl strcpy( char* strDest, const char* strSource );

#pragma intrinsic(memcpy)
void* CCompiler::memcpy( void* dest, const void* src, size_t count )
{
  return ::memcpy( dest, src, count );
}

#pragma intrinsic(strcpy)
char* CCompiler::strcpy( char* strDest, const char* strSrouce )
{
  return ::strcpy( strDest, strSource );
}

#pragma function(memcpy)
#pragma function(strcpy)

Whereas strcpy is perfectly happy I get a

LNK2019 unresolved external symbol _memcpy referenced in function "public: void * __cdecl nsCompiler::CCompiler::memcpy(void*,void const*,unsigned int)"

when I try to build the this into a Dll.
FYI nsCompiler::CCompiler is exported and I know that's done right.

No warning that memcpy intrinsic is not available despite warning level 4 and no compile error claiming it can't generate nsCompiler::CCompiler::memcpy

Any help, known bug pointers, or workarounds would be much appreciated.

Posted 4-Feb-13 3:18am

Matthew Faithfull

Updated 4-Feb-13 3:23am

v2

Add a Solution

Comments

nv3 4-Feb-13 10:04am

Just a guess into the blue: The intrinsic pragma documentation says: "... The compiler may call the function and not replace the function call with inline instructions, if it will result in better performance."

So in case of memcpy the compiler might decide to call the library function and not generate inline code (as it probably did for strcpy). Now, if you haven set the linker settings correctly to link in the runtime library, that might produce the unresolved external.

Matthew Faithfull 4-Feb-13 10:15am

Thanks that might just be it although I have no idea why it would consider calling an external library function in another DLL more efficient. Linking the runtime would probably solve it if I wasn't implementing the runtime rather than using it in this case. You would think it would flag a level 4 warning at least.

nv3 4-Feb-13 11:41am

Memcpy is a function that benefits from heavy optimization, while strcpy does not. That might be the reason why the compiler generally prefers calling memcpy, while using inline code for strcpy.

Guessing why they didn't issue a warning: Compiler developers might have assumed that one normally links with the runtime. So a normal user won't even notice the difference except for the performance gain.

Matthew Faithfull 4-Feb-13 11:58am

Yes, I think you're right and it's an undocumented behaviour change between compiler versions as well. I need to investigate further to see how far it goes back but I'm reasonably confident VS2005 didn't do that. It's also the only intrinsic causing this issue despite that I've done the same thing with all 27 architecture independent ones. Anyway thanks for your input. I'll have to make a special case like _outpw where they changed the signature between VC8 and VC9.
If you post you explanation as a solution I'll accept it.

nv3 4-Feb-13 13:55pm

You're most welcome, Matthew!

Philip Stuyck 4-Feb-13 13:51pm

Are you sure you need the forward declaration of memcpy and strcpy ? Just include the proper header file. If the forward declaration is not correct, this will explain your link problem.

Matthew Faithfull 4-Feb-13 14:00pm

It would indeed explain the problem to some degree if I had the forwrd decl of memcpy wrong. But if I make it wrong or remove it as you suggest then I do get a warning telling me I can't pragma intrinsic something that isn't declared. This tells me I do need to declare it and that the declaration is working because the warning goes away. In this case there are no headers to include rather I'm writing the library headers. Thanks for your input, thinking it through to comment all help to clarify the situation.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

nv3 · Accepted Answer · 2013-02-04T07:56:00

Just a guess into the blue: The intrinsic pragma documentation says: "... The compiler may call the function and not replace the function call with inline instructions, if it will result in better performance." So in case of memcpy the compiler might decide to call the library function and not generate inline code (as it probably did for strcpy). Now, if you haven't set the linker settings correctly to link in the runtime library, that might produce the unresolved external.