Possible compiler bug

[Wiebke_T_]

There's a possible bug in the icc  installed with Composer XE 2013 SP1 Update 5 (2013.1.5.239). The compiler compiiles the code but the result leads to a run-time crash.

Here is a c++ programs that can reproduce the crash:

If executed it leads to this error:

"Run-Time Check Failure #2 - Stack around the variable 'os_.1016' was corrupted."

//------------------------------------------------
#include <new>
 
struct base
{
  virtual ~base() {}
};

struct test_type : virtual base
{
};

template<class T>
struct opt
{
  bool init_;
  char buffer_[sizeof(T)];

  opt() : init_(false) {}

  void recreate()
  {
    clear();
    construct();
  }

  void clear()
  {
    if (init_)
    {
      destroy();
    }
  }

  ~opt()
  {
    clear();
  }

  T& operator*()
  {
    return *address();
  }

private:
  void* raw_storage()
  {
    return &buffer_;
  }

  T* address()
  {
    return static_cast<T*>(raw_storage());
  }

  void construct()
  {
    ::new (raw_storage()) T();
    init_ = true;
  }

  void destroy()
  {
    address()->T::~T();
    init_ = false;
  }
};

void test()
{
  opt<test_type>os_;
  os_.recreate();
  os_.clear();
}

int main()
{
  test();
}
//------------------------------------------------

The program compile and runs correctly in gcc, clang, and vc110. (Tried here: http://melpon.org/wandbox and in VS2012)

[Wiebke_T_]

After internal discussion, we decided that this case is resolved for us.

The code that originally caused problems with our logging system was this one:

#include <sstream>
#include "boost/optional.hpp"

#include <chrono>
#include <thread>

void test()
{
   std::this_thread::sleep_for(std::chrono::seconds(10));
   boost::optional<std::ostringstream> os_;
   os_ = boost::in_place();
   (*os_) << "Hu!" << std::flush;
   os_ = boost::none; // Crash here
}

int main()
{
   test();
}

This one seems to have been fixed, it works now (see https://software.intel.com/en-us/forums/topic/515054 for the original thread). The above program was a simplification to try to reproduce the behavior without STL and boost, and it probably violates the C++ aliasing rules.

[Kittur_G_Intel]

Thanks Wiebke for letting us know and makes sense, appreciate much.

_Kittur