Mixing
“std::_debug_memset” is not declared
I'm working on GCC119 from the compile farm. The machine is AIX 7.1, POWER8 with IBM XLC 13.1. I'm trying to use the debug heap:
gcc119$ cat test.cxx
#include <altivec.h>
#undef vector
#undef pixel
#undef bool
#include <cstdlib>
int main(int argc, char* argv)
{
unsigned char x[32];
std::memset(x, 0x00, 32);
return 0;
}
A compile results in:
gcc119$ xlC -DDEBUG -g3 -O0 -qheapdebug -qro test.cxx -o test.exe
"test.cxx", line 11.3: 1540-0130 (S) "std::_debug_memset" is not declared.
Both <cstring> and <string.h> result in the error. I also tried including <cstdlib> and <stdlib.h>, and they resulted in the same error.
The Optimization and Programming Guide manual has a good discussion of debugging memory functions, but the treatment is C only. It does not appear to treat C++.
How does one use debug heaps in a C++ program?
gcc119$ oslevel -s
7200-00-01-1543
gcc119$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0004
c++ aix memset xlc
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
add a comment |
I'm working on GCC119 from the compile farm. The machine is AIX 7.1, POWER8 with IBM XLC 13.1. I'm trying to use the debug heap:
gcc119$ cat test.cxx
#include <altivec.h>
#undef vector
#undef pixel
#undef bool
#include <cstdlib>
int main(int argc, char* argv)
{
unsigned char x[32];
std::memset(x, 0x00, 32);
return 0;
}
A compile results in:
gcc119$ xlC -DDEBUG -g3 -O0 -qheapdebug -qro test.cxx -o test.exe
"test.cxx", line 11.3: 1540-0130 (S) "std::_debug_memset" is not declared.
Both <cstring> and <string.h> result in the error. I also tried including <cstdlib> and <stdlib.h>, and they resulted in the same error.
The Optimization and Programming Guide manual has a good discussion of debugging memory functions, but the treatment is C only. It does not appear to treat C++.
How does one use debug heaps in a C++ program?
gcc119$ oslevel -s
7200-00-01-1543
gcc119$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0004
c++ aix memset xlc
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
1
Workaround:(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.
– MSalters
Nov 22 '18 at 9:44
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35
add a comment |
I'm working on GCC119 from the compile farm. The machine is AIX 7.1, POWER8 with IBM XLC 13.1. I'm trying to use the debug heap:
gcc119$ cat test.cxx
#include <altivec.h>
#undef vector
#undef pixel
#undef bool
#include <cstdlib>
int main(int argc, char* argv)
{
unsigned char x[32];
std::memset(x, 0x00, 32);
return 0;
}
A compile results in:
gcc119$ xlC -DDEBUG -g3 -O0 -qheapdebug -qro test.cxx -o test.exe
"test.cxx", line 11.3: 1540-0130 (S) "std::_debug_memset" is not declared.
Both <cstring> and <string.h> result in the error. I also tried including <cstdlib> and <stdlib.h>, and they resulted in the same error.
The Optimization and Programming Guide manual has a good discussion of debugging memory functions, but the treatment is C only. It does not appear to treat C++.
How does one use debug heaps in a C++ program?
gcc119$ oslevel -s
7200-00-01-1543
gcc119$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0004
c++ aix memset xlc
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
I'm working on GCC119 from the compile farm. The machine is AIX 7.1, POWER8 with IBM XLC 13.1. I'm trying to use the debug heap:
gcc119$ cat test.cxx
#include <altivec.h>
#undef vector
#undef pixel
#undef bool
#include <cstdlib>
int main(int argc, char* argv)
{
unsigned char x[32];
std::memset(x, 0x00, 32);
return 0;
}
A compile results in:
gcc119$ xlC -DDEBUG -g3 -O0 -qheapdebug -qro test.cxx -o test.exe
"test.cxx", line 11.3: 1540-0130 (S) "std::_debug_memset" is not declared.
Both <cstring> and <string.h> result in the error. I also tried including <cstdlib> and <stdlib.h>, and they resulted in the same error.
The Optimization and Programming Guide manual has a good discussion of debugging memory functions, but the treatment is C only. It does not appear to treat C++.
How does one use debug heaps in a C++ program?
gcc119$ oslevel -s
7200-00-01-1543
gcc119$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0004
c++ aix memset xlc
c++ aix memset xlc
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
edited Nov 22 '18 at 0:44
jww
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
asked Nov 21 '18 at 23:11
jwwjww
53.3k40229503
53.3k40229503
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
1
Workaround:(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.
– MSalters
Nov 22 '18 at 9:44
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35
add a comment |
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
1
Workaround:(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.
– MSalters
Nov 22 '18 at 9:44
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
1
1
Workaround:
(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.– MSalters
Nov 22 '18 at 9:44
Workaround:
(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.– MSalters
Nov 22 '18 at 9:44
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35
add a comment |
2 Answers
2
active
oldest
votes
You should try including <string.h> instead and using unqualified memset. According to the IBM XL C/C++ Programming Guide, _debug_memset lives in string.h. So the question becomes, shouldn't <cstring> make it available via std::? In the IBM XL C/C++ Standard Library reference, it shows all of the using declarations, and the debug functions are not there.
namespace std
{
using ::size_t; using ::memcmp; using ::memcpy; using ::memmove;
using ::memset; using ::strcat; using ::strcmp; using ::strcoll;
using ::strcpy; using ::strcspn; using ::strerror; using ::strlen;
using ::strncat; using ::strncmp; using ::strncpy; using ::strspn;
using ::strtok; using ::strxfrm;
}
answered Nov 21 '18 at 23:35
user10688376user10688376
211
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
add a comment |
Based on @user10688376's observation here's what I've come up with. I think it is technically undefined behavior because I am not allowed to put symbols like _debug_memset and _debug_memcpy in the std namespace. At this point potential UB is better than a failed compile and no testing.
#if defined(_AIX) && (defined(__xlc__) || defined(__xlC__) || defined(__ibmxl__))
# if defined(__DEBUG_ALLOC__)
namespace std {
using ::_debug_memset;
using ::_debug_memcpy;
}
# endif
#endif
_AIX is used because it identifies the operating system. Debug heaps are not available on the Linux gear. (Some IBM XLC compilers run on Linux, too).
__xlc__ and __xlC__ are used to detect IBM XLC compiler 13.0 and earlier. This compiler is built completely by IBM.
__ibmxl__ is used to detect IBM XLC compiler 13.1 and later. This compiler uses a Clang front-end and IBM back-end. I think this is the "LLC" compiler referred to in LLVM Review 21078.
__DEBUG_ALLOC__ is used because the compiler sets it for -qheapdebug.
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421744%2fstd-debug-memset-is-not-declared%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You should try including <string.h> instead and using unqualified memset. According to the IBM XL C/C++ Programming Guide, _debug_memset lives in string.h. So the question becomes, shouldn't <cstring> make it available via std::? In the IBM XL C/C++ Standard Library reference, it shows all of the using declarations, and the debug functions are not there.
namespace std
{
using ::size_t; using ::memcmp; using ::memcpy; using ::memmove;
using ::memset; using ::strcat; using ::strcmp; using ::strcoll;
using ::strcpy; using ::strcspn; using ::strerror; using ::strlen;
using ::strncat; using ::strncmp; using ::strncpy; using ::strspn;
using ::strtok; using ::strxfrm;
}
answered Nov 21 '18 at 23:35
user10688376user10688376
211
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
add a comment |
You should try including <string.h> instead and using unqualified memset. According to the IBM XL C/C++ Programming Guide, _debug_memset lives in string.h. So the question becomes, shouldn't <cstring> make it available via std::? In the IBM XL C/C++ Standard Library reference, it shows all of the using declarations, and the debug functions are not there.
namespace std
{
using ::size_t; using ::memcmp; using ::memcpy; using ::memmove;
using ::memset; using ::strcat; using ::strcmp; using ::strcoll;
using ::strcpy; using ::strcspn; using ::strerror; using ::strlen;
using ::strncat; using ::strncmp; using ::strncpy; using ::strspn;
using ::strtok; using ::strxfrm;
}
answered Nov 21 '18 at 23:35
user10688376user10688376
211
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
add a comment |
You should try including <string.h> instead and using unqualified memset. According to the IBM XL C/C++ Programming Guide, _debug_memset lives in string.h. So the question becomes, shouldn't <cstring> make it available via std::? In the IBM XL C/C++ Standard Library reference, it shows all of the using declarations, and the debug functions are not there.
namespace std
{
using ::size_t; using ::memcmp; using ::memcpy; using ::memmove;
using ::memset; using ::strcat; using ::strcmp; using ::strcoll;
using ::strcpy; using ::strcspn; using ::strerror; using ::strlen;
using ::strncat; using ::strncmp; using ::strncpy; using ::strspn;
using ::strtok; using ::strxfrm;
}
answered Nov 21 '18 at 23:35
user10688376user10688376
211
You should try including <string.h> instead and using unqualified memset. According to the IBM XL C/C++ Programming Guide, _debug_memset lives in string.h. So the question becomes, shouldn't <cstring> make it available via std::? In the IBM XL C/C++ Standard Library reference, it shows all of the using declarations, and the debug functions are not there.
namespace std
{
using ::size_t; using ::memcmp; using ::memcpy; using ::memmove;
using ::memset; using ::strcat; using ::strcmp; using ::strcoll;
using ::strcpy; using ::strcspn; using ::strerror; using ::strlen;
using ::strncat; using ::strncmp; using ::strncpy; using ::strspn;
using ::strtok; using ::strxfrm;
}
answered Nov 21 '18 at 23:35
user10688376user10688376
211
answered Nov 21 '18 at 23:35
user10688376user10688376
211
answered Nov 21 '18 at 23:35
user10688376user10688376
211
answered Nov 21 '18 at 23:35
user10688376user10688376
211
211
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
add a comment |
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
From that manual: "these functions will be removed in a future release". It might not be worth the trouble to get this working, only to remove the whole mechanism in 2019.
– MSalters
Nov 22 '18 at 9:42
add a comment |
Based on @user10688376's observation here's what I've come up with. I think it is technically undefined behavior because I am not allowed to put symbols like _debug_memset and _debug_memcpy in the std namespace. At this point potential UB is better than a failed compile and no testing.
#if defined(_AIX) && (defined(__xlc__) || defined(__xlC__) || defined(__ibmxl__))
# if defined(__DEBUG_ALLOC__)
namespace std {
using ::_debug_memset;
using ::_debug_memcpy;
}
# endif
#endif
_AIX is used because it identifies the operating system. Debug heaps are not available on the Linux gear. (Some IBM XLC compilers run on Linux, too).
__xlc__ and __xlC__ are used to detect IBM XLC compiler 13.0 and earlier. This compiler is built completely by IBM.
__ibmxl__ is used to detect IBM XLC compiler 13.1 and later. This compiler uses a Clang front-end and IBM back-end. I think this is the "LLC" compiler referred to in LLVM Review 21078.
__DEBUG_ALLOC__ is used because the compiler sets it for -qheapdebug.
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
add a comment |
Based on @user10688376's observation here's what I've come up with. I think it is technically undefined behavior because I am not allowed to put symbols like _debug_memset and _debug_memcpy in the std namespace. At this point potential UB is better than a failed compile and no testing.
#if defined(_AIX) && (defined(__xlc__) || defined(__xlC__) || defined(__ibmxl__))
# if defined(__DEBUG_ALLOC__)
namespace std {
using ::_debug_memset;
using ::_debug_memcpy;
}
# endif
#endif
_AIX is used because it identifies the operating system. Debug heaps are not available on the Linux gear. (Some IBM XLC compilers run on Linux, too).
__xlc__ and __xlC__ are used to detect IBM XLC compiler 13.0 and earlier. This compiler is built completely by IBM.
__ibmxl__ is used to detect IBM XLC compiler 13.1 and later. This compiler uses a Clang front-end and IBM back-end. I think this is the "LLC" compiler referred to in LLVM Review 21078.
__DEBUG_ALLOC__ is used because the compiler sets it for -qheapdebug.
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
add a comment |
Based on @user10688376's observation here's what I've come up with. I think it is technically undefined behavior because I am not allowed to put symbols like _debug_memset and _debug_memcpy in the std namespace. At this point potential UB is better than a failed compile and no testing.
#if defined(_AIX) && (defined(__xlc__) || defined(__xlC__) || defined(__ibmxl__))
# if defined(__DEBUG_ALLOC__)
namespace std {
using ::_debug_memset;
using ::_debug_memcpy;
}
# endif
#endif
_AIX is used because it identifies the operating system. Debug heaps are not available on the Linux gear. (Some IBM XLC compilers run on Linux, too).
__xlc__ and __xlC__ are used to detect IBM XLC compiler 13.0 and earlier. This compiler is built completely by IBM.
__ibmxl__ is used to detect IBM XLC compiler 13.1 and later. This compiler uses a Clang front-end and IBM back-end. I think this is the "LLC" compiler referred to in LLVM Review 21078.
__DEBUG_ALLOC__ is used because the compiler sets it for -qheapdebug.
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
Based on @user10688376's observation here's what I've come up with. I think it is technically undefined behavior because I am not allowed to put symbols like _debug_memset and _debug_memcpy in the std namespace. At this point potential UB is better than a failed compile and no testing.
#if defined(_AIX) && (defined(__xlc__) || defined(__xlC__) || defined(__ibmxl__))
# if defined(__DEBUG_ALLOC__)
namespace std {
using ::_debug_memset;
using ::_debug_memcpy;
}
# endif
#endif
_AIX is used because it identifies the operating system. Debug heaps are not available on the Linux gear. (Some IBM XLC compilers run on Linux, too).
__xlc__ and __xlC__ are used to detect IBM XLC compiler 13.0 and earlier. This compiler is built completely by IBM.
__ibmxl__ is used to detect IBM XLC compiler 13.1 and later. This compiler uses a Clang front-end and IBM back-end. I think this is the "LLC" compiler referred to in LLVM Review 21078.
__DEBUG_ALLOC__ is used because the compiler sets it for -qheapdebug.
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
edited Nov 25 '18 at 19:37
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
answered Nov 22 '18 at 10:13
jwwjww
53.3k40229503
53.3k40229503
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421744%2fstd-debug-memset-is-not-declared%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I might have already said that C++ is problematic even on popular platforms like MS Windows or GnuLinux, but on exotic platforms like AIX it is downright deadly. Also there are gcc's include-fixed header-files: they are usually not match with the actual header file they silently replace. gcc.gnu.org/onlinedocs/gcc/Fixed-Headers.html
– Lorinczy Zsigmond
Nov 22 '18 at 4:31
1
Workaround:
(std::memset)(x, 0x00, 32);. If at all possible, develop on a normal system like MSVC++, Clang or G++, and then port to XLC. Don't try to debug heap errors on such exotics.– MSalters
Nov 22 '18 at 9:44
@MSalters - Thanks. Yeah, we are clean on BSDs, Linux, OS X, Solaris, and Windows using the tools described at Analysis Tools. We are trying to track down the cause of Clang 7.0 self test failures on PowerPC. Clang 7.0 is the latest and I just got it to build from sources for the platform. I suspect it is a buggy compiler (we already filed a few bugs, like LLVM Issue 39704).
– jww
Nov 22 '18 at 9:55
@MSalters - The LLVM patch by Nemanja Ivanovic for Issue 39704 fixed out failed self tests. It seems Clang was removing some of our loads and stores because the LLVM functions were annotated incorrectly. LLVM thought they needed to be 16-byte aligned when they only needed 1-byte alignment.
– jww
Nov 25 '18 at 19:35