Serious apparent bug when allocating byte-objects with new[] and constructors

[Ian_Mallett1]

Hi,

Here is a simple example:

#include <cstdint>

class Foo final {
    public:
        uint8_t packed;

    public:
        inline Foo(void) : packed(0xFF) {} //causes error
        inline ~Foo(void) = default;
};
static_assert(sizeof(Foo)==sizeof(uint8_t),"Implementation error!");

int main(int /*argc*/, char* /*argv*/[]) {
    Foo* arr = new Foo[4]; //Tried a bunch of different sizes.  All fail.
    delete [] arr;

    return 0;
}

This program is valid C++, yet erroneously corrupts its own memory when run, and crashes. The constructor line appears to be the culprit. The program was compiled with Intel C++ 16.0.

For your convenience, here is a link to a complete solution that demonstrates the problem. Here is a link to the assembled code.

-i

[Melanie_B_Intel]

I can reproduce this problem. I opened DPD200408393 in our internal bug tracking database.  Thank you for reporting this.

(The wrong delete operator is being called, if you remove the explicit call to delete the main program will terminate normally.)

 --Melanie

[Melanie_B_Intel]

More information on this problem:

This only happens with

inline ~Foo(void) = default;

If you remove “default”, things are okay.

Thanks again for the bug report. --Melanie

[Ian_Mallett1]

N.B., removing the constructor also fixes it. The constructor/destructor use case is just for testing, so I'm not desperate for a workaround. But . . . this is still a pretty serious bug. I will be glad when it is fixed.
Best,

[Ian_Mallett1]

Now we're seeing this bug everywhere. Not to be pushy, but . . . will this be fixed soon, I hope?

There seems to be a related problem where the correct overload of `new` is called, but the value ultimately stored into the pointer is different from the one returned. So e.g. the "ptr" in "Foo* ptr=new Foo[6];" is different from value returned by the "new[]" overload. I stepped through the assembly, but didn't really understand what was going on. It seemed to happen during something like Foo::'vector constructor'. I don't really have time to isolate it, but again, I think this is a related problem.

--Ian

[Anoop_M_Intel]

Hi Ian,

This issue is fixed internally and the fix will be available in public domain in our next v16.0 update.

Thanks and Regards
Anoop