Re: IPA: Devirtualization versus placement new

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 25 April 2014 13:01, Richard Biener wrote:
> On Fri, Apr 25, 2014 at 1:18 PM, Jonathan Wakely <jwakely.gcc@gmail.com> 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
>>> http://www.parashift.com/c++-faq/placement-new.html.  (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:
>>
>> sa.cc:9:24: runtime error: load of null pointer of type '<unknown> *'
>> Segmentation fault (core dumped)

I created http://gcc.gnu.org/60963 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.