incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
Date Mon, 24 Mar 2008 21:53:39 GMT
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:Eric.Lemings@roguewave.com] Sent: Monday, 
>>> March 24, 2008 3:21 PM
>>> To: dev@stdcxx.apache.org
>>> 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:msebor@gmail.com] On Behalf Of 
>>> Martin Sebor
>>>> Sent: Friday, March 21, 2008 5:10 PM
>>>> To: dev@stdcxx.apache.org
>>>> Subject: Re: [STDCXX-709] ContainerData ctor and UserClass::from_char()
>>>>
>>>> Eric Lemings wrote:
>>>>>  
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Martin Sebor [mailto:sebor@roguewave.com] Sent: Friday, 
>>>>>> March 21, 2008 3:32 PM
>>>>>> To: dev@stdcxx.apache.org
>>>>>> 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.
>>>>>
>>>>> [user@host]$ ./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
>>>>
>>
> 
> 


Mime
View raw message