This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ object model and dynamic type


Hi, this is interesting discussion. It turns out also very relevant to
another analysis/optimization -- C++ virtual function call aliasing
(related to vptr, vtbl accesses) (see bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560).  The plan is to
perform live-across-call analysis (of polymorphic objects). This
requires the assumption that the dynamic type of the storage does not
change across a call if the storage is used across call -- this
guarantees the invariance of the vptr field.

Thanks,

David

On Wed, Feb 3, 2010 at 9:46 AM, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
>
> Please find below a response to my raising the issue at the core of the
> discussion 'Fix C++ strict-aliasing issues with memcpy folding'.
>
> I hope it does clarify the intent of 'memory reuse', and also the
> abstract object model.
>
>
>
> ---------- Forwarded message ----------
> From:?"William M. \(Mike\) Miller" <william.m.miller@gmail.com>
> To:?undisclosed-recipients:;
> Date:?Wed, 3 Feb 2010 12:13:18 -0500
> Subject:?Re: C++ object model and dynamic type
> To: C++ core language mailing list
> Message c++std-core-15735
>
> On Wed, Feb 3, 2010 at 11:56 AM, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
>> To: C++ core language mailing list
>> Message c++std-core-15734
>>
>> Hi,
>>
>> Consider the following program fragment
>>
>> ? ?extern void f(int*);
>>
>> ? ?int g() {
>> ? ? ? int i = 3;
>> ? ? ? int* p = &i;
>> ? ? ? f(p); ? ? ? ? ? ? // #1
>> ? ? ? return i;
>> ? ?}
>>
>> We can assume that the function 'f' does not 'free' its arguments, nor
>> does it use funny memcpy().
>>
>> A question: can a C++ compiler optimizer (that uses a type-based alias
>> analysis) assume that, during a call to g(), the *variable* 'i' always
>> designates an object of type 'int', especially after the call to 'f'?
>>
>> Said, differently is it accurate to say that a variable definition
>> prescribes "forever" the types of objects that it can hold? ?Can
>> that storage be reused to store objects of any type, or just objects of
>> compatible types?
>> For example, would the following be a valid definition of 'f'?
>>
>> ? ? ?void f(int* p) {
>> ? ? ? ? new (p) float(1.2);
>> ? ? ?}
>>
>>
>> Answers to these questions have practical consequences in terms of
>> optimizations that a C compiler is permitted to do, but would not be
>> applicable to a C++ program -- the old myth of C++ intrinsic slowness
>> will finally come true. ?In a sense, C++ would become a sort of
>> dynamic language with declared types saying very little about runtime
>> values.
>>
>>
>> My sense is that only objects of compatible types may be stored in
>> a variable, however I do not see a clear statement to that effect in the
>> standard text. ?Note that restricting to objects of compatible types
>> still allows allocators that use static or automatic storage (since they
>> would be using arrays of characters.)
>
> 3.8p7-9 are intended to address concerns such as these. ?The
> existing wording primarily addresses class objects and particularly
> class objects with destructors (p7, for instance, which most directly
> applies to your example and requires that the old and new objects
> have the same type, only applies after the lifetime of the original
> object has ended, which only occurs for scalar objects when their
> storage is freed), so we probably need to tweak it a bit to make it
> clear that non-class objects are also covered.
>
> I'll open an issue for this.
>
> --
> William M. (Mike) Miller | Edison Design Group
> william.m.miller@gmail.com
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]