Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ VS2010 VC++
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
Edited 4-Feb-13 3:23am
v2
Comments
nv3 at 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 at 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 at 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 at 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 at 4-Feb-13 13:55pm
   
You're most welcome, Matthew!
Philip Stuyck at 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 at 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

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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.
  Permalink  
Comments
Philip Stuyck at 4-Feb-13 16:07pm
   
since this is the solution i give you 5
nv3 at 4-Feb-13 16:54pm
   
Thanks Philip!

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

  Print Answers RSS
0 OriginalGriff 554
1 Gihan Liyanage 338
2 RyanDev 268
3 Sergey Alexandrovich Kryukov 263
4 ChauhanAjay 220
0 Sergey Alexandrovich Kryukov 8,936
1 OriginalGriff 7,891
2 CPallini 2,603
3 Richard MacCutchan 2,121
4 Abhinav S 1,928


Advertise | Privacy | Mobile
Web04 | 2.8.140827.1 | Last Updated 4 Feb 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100