Travis Vitek wrote:
I spent some time looking through these results and it looks like the HP
compiler is generating code that results in many unexpected UMR
[Uninitialized Memory Read] errors. I'm not exactly sure what to do with
the information I've gathered, so I'm posting it here. Here is my simple
testcase and other relevant information.
[EMAIL PROTECTED] ~]$ cat t.cpp
struct random_access_iterator_tag
{
#ifdef _TAG
random_access_iterator_tag () : _C_dummy(0) {}
char _C_dummy;
#endif
};
void distance(random_access_iterator_tag)
{
}
int main()
{
const random_access_iterator_tag __tag;
distance (__tag); // <-- umr here
The UMR is real, isn't it? I.e., __tag is not initialized but
it's being copied to the function argument. Do other compilers
eliminate the copy?
Martin
return 0;
}
[EMAIL PROTECTED] ~]$ purify -log-file=t.log -windows=no aCC -g t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
UMR: Uninitialized memory read:
[EMAIL PROTECTED] ~]$ purify -log-file=t.log -windows=no aCC -D_TAG -g t.cpp
2> /dev/null && ./a.out && grep "^UMR" t.log
[EMAIL PROTECTED] ~]$
Here is the purify message...
UMR: Uninitialized memory read:
* This is occurring while in:
main [t.cpp:17]
_start [libc.2]
$START$ [crt0.o]
$START$ [crt0.o]
* Reading 1 byte from 0x7f7f0b88 on the stack.
* Address 0x7f7f0b88 is local variable "__tag" in function main.
Here is the disassembly for the original code. You can see that a byte
from -0x38(%sp) is loaded into %r17, but nothing was ever stored there.
0x5296c <main+0x20>: nop
0x52970 <main+0x24>: call,n 0x5293c <_main>
0x52974 <main+0x28>: break 0,0
0x52978 <main+0x2c>: be,l -0xdd8(%sr3,%r18),%sr0,%r31
0x5297c <main+0x30>: copy %sp,%r17
;;; 17 distance (__tag);
0x52980 <main+0x34>: be,l -0xfb8(%sr3,%r18),%sr0,%r31
0x52984 <main+0x38>: ldo -0x38(%sp),%r17 ; <-- load here, but no
previous store
0x52988 <main+0x3c>: ldb -0x38(%sp),%r26 ; <-- load here, but no
previous store
0x5298c <main+0x40>: be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
0x52990 <main+0x44>: nop
Here is the disassembly for the case that gets no UMR message. You can
see that a byte is stored at -0x38(%sp) before it is loaded.
0x5296c <main+0x20>: nop
0x52970 <main+0x24>: call,n 0x5293c <_main>
0x52974 <main+0x28>: break 0,0
0x52978 <main+0x2c>: be,l -0xdd8(%sr3,%r18),%sr0,%r31
0x5297c <main+0x30>: copy %sp,%r17
;;; 16 const random_access_iterator_tag __tag;
0x52980 <main+0x34>: be,l -0xef8(%sr3,%r18),%sr0,%r31
0x52984 <main+0x38>: ldo -0x38(%sp),%r17
0x52988 <main+0x3c>: stb %r0,-0x38(%sp) ; <-- store here
;;; 17 distance (__tag);
0x5298c <main+0x40>: be,l -0xfb8(%sr3,%r18),%sr0,%r31
0x52990 <main+0x44>: ldo -0x38(%sp),%r17 ; <-- load here
0x52994 <main+0x48>: ldb -0x38(%sp),%r26 ; <-- load here
0x52998 <main+0x4c>: be,l,n -0xdfc(%sr3,%r18),%sr0,%r31
0x5299c <main+0x50>: nop
This issue causes Purify warnings in any function that passes an empty
class as a parameter to a function by value. Nearly any function that
touches the iterator tag types will give a UMR warning because of this
problem.
Travis
From: Andrew Black
Greetings all.
As I mentioned in my previous email, I've performed a test build of the
apache standard library using Rational
PurifyPlus 7.0 ( http://www.ibm.com/software/awdtools/purifyplus/ ).
This build was performed on an HPUX 11.23 machine, using the
HP acc 3.73
compiler and subversion trunk at
r580086 plus the makefile.rules part of the purify.diff patch attached
to STDCXX-573. PURE_OPTS was set to '[EMAIL PROTECTED]
-windows=no -append-logfile=yes [EMAIL PROTECTED]
-always-use-cache-dir=yes -cache-dir=/tmp/ablack-purecache-stdcx'. If
anyone wishes to look at the results of this build, it can be retrieved
from http://people.apache.org/~ablack/stdcxx-4.2.0-rc-5-purify.tar.gz .
This build was a 15d build, which was processed with `make clean` and
`make dependclean` prior to being compressed.
Note that some of the .log files were truncated by Purify
during the run
process due to their length. These files are
22.locale.money.put.log, tests/22.locale.moneypunct.log,
tests/22.locale.num.get.log, tests/23.deque.modifiers.log,
tests/25.find.end.log, and tests/25.search.log.
--Andrew Black
