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
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
>
>
