This is the mail archive of the 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: IPA: Devirtualization versus placement new

On 25 April 2014 13:01, Richard Biener wrote:
> On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely <> wrote:
>> On 25 April 2014 11:22, Andrew Haley wrote:
>>> Summary: Devirtualization uses type information to determine if a
>>> virtual method is reachable from a call site.  If type information
>>> indicates that it is not, devirt marks the site as unreachable.  I
>>> think this is wrong, and it breaks some programs.  At least, it should
>>> not do this if the user specifies -fno-strict-aliasing.
>>> Consider this class:
>>> class Container {
>>>   void *buffer[5];
>>> public:
>>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>>   Container() { new (buffer) EmbeddedObject(); }
>>> };
>>> Placement new is used to embed an object in a buffer inside another
>>> object.  Its address can be retrieved.  This usage of placement new is
>>> common, and it even appears as the canonical use of placement new in
>>> the in the C++ FAQ at
>>>  (I am aware that
>>> this is not strictly legal.  For one thing, the memory at buffer may
>>> not be suitably aligned.  Please bear with me.)
>> I think the program is strictly legal if you define Container like this:
>> class Container {
>>   alignas(EmbeddedObject) char buffer[sizeof(EmbeddedObject)];
>> public:
>>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>>   Container() { new (buffer) EmbeddedObject(); }
>> };
>> But GCC still does the same transformation and prints nothing, which I
>> agree is wrong (even with -fstrict-aliasing).
> I agree, -fstrict-aliasing has nothing to do with this.  Sounds simply like
> a genuine bug (please open a bugzilla).
> Thanks,
> Richard.
>> With ubsan that program gives:
>> runtime error: load of null pointer of type '<unknown> *'
>> Segmentation fault (core dumped)

I created for the ubsan error. The testcase
there is a single file which crashes with ubsan and returns the wrong
value without.  Changing the return statement to
__builtin_printf("%d\n", o.obj()->val()) prints nothing, like Andrew's
original example.

If it's not really a ubsan problem feel free to re-categorise that as
a devirt bug rather than open a new one, whatever's most appropriate.

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