Incidentally, there is a script that compares two or more config
headers. I don't see it in Subversion so it must not have been
migrated from Perforce yet:
//stdlib/dev/etc/stdlib/scripts/cfgcmp
We might want to dust it off at some point in the future and start
using it. It can be quite handy when porting to new versions of
compilers or compilers on new platforms.
Martin
Martin Sebor wrote:
The two versions of aCC are very different (based on a different
C++ front ends). Each also runs on a different OS and hardware.
I think significant differences are to be expected. That doesn't
mean that there isn't a problem in our aCC 6.16 configuration,
but neither does it imply there is one.
Eric Lemings wrote:
In regards to STDCXX-709, note that there are no config differences
in the delete operators, only the new operators.
These should be benign and unrelated to STDCXX-709.
FWIW, if you still suspect a mismatch between the allocation and
deallocation functions called from the tests I would suggest to
try to create a small test case reproducing it. I.e., create an
archive lib that allocates memory using the new expression and
a program that replaces operators new and delete, links with the
library and attempts to deallocate the memory allocated by the
library. See if the right operators are being called.
Martin
Brad.
-----Original Message-----
From: Eric Lemings [mailto:[EMAIL PROTECTED] Sent: Monday,
March 24, 2008 3:21 PM
To: [email protected]
Subject: RE: [STDCXX-709] ContainerData ctor and UserClass::from_char()
I was just comparing the configuration differences for these
two platforms:
HP-UX B.11.21/HP aCC 3.73
HP-UX B.11.31/HP aCC 6.16
See http://people.apache.org/~elemings/diff.out.
There seems to be way to many configuation differences. I think
we may have a much more serious problem on HP-UX ia64.
Brad.
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
Martin Sebor
Sent: Friday, March 21, 2008 5:10 PM
To: [email protected]
Subject: Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday,
March 21, 2008 3:32 PM
To: [email protected]
Subject: Re: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
...
So you think there's a mismatch between the allocation function
invoked in value.cpp and the deallocation function called in the
header? Why would that be? IIUC, tests that replace operator new
and operator delete (such as 23.list.assign) replace it for the
whole process. If there's a mismatch, it can only be because
the operators aren't replaced consistently. Making sure this
replacement happens across the whole process, including any
libraries, is the responsibility of the C++ runtime (i.e.,
the compiler). If your analysis is correct, the C++ runtime
on IPF would have to be buggy.
Or did I misunderstand what you were trying to say?
Sounds about right.
I just noticed there's a runtime link error in the config test
OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
culprit.
[EMAIL PROTECTED] ./include/OPERATOR_NEW_ARRAY_PLACEMENT
/usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
Killed
That's a check for placement new in the runtime library. I don't
think that has any bearing on the replaceability of operator new.
I.e., the first one is not replaceable:
void* operator new(size_t, void*) throw();
void* operator new[](size_t, void*) throw();
while the second one is:
void* operator(size_t) throw (bad_alloc);
void* operator[](size_t) throw (bad_alloc);
The first form is usually defined inline in <new>, like so:
inline void* operator new(size_t, void *ptr) throw() {
return ptr;
}
and so it's not defined in the runtime library. That's why I assume
the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares
the operator
and calls it without providing a definition to see if one exists in
the runtime. Unless the test finds one we need to provide our own
definition in our <new>. Otherwise we just declare it.
Martin
