Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

em++ fails to generate copy constructor calls for 32-bit sized objects #5114

Closed
mkl-ableton opened this issue Apr 5, 2017 · 2 comments
Closed

Comments

@mkl-ableton
Copy link

When compiling the following code, em++ does not generate a copy constructor call for the line tested = make_tested();. Instead, it just copies the object's data as if the object was trivially copyable. The copy constructor does get called when increasing the object's size.

This happens with:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.37.9
clang version 4.0.0 (https://github.com/kripken/emscripten-fastcomp-clang/ d4b1e0785f1ee15ab78207de4380e82e3407c6ea) (https://github.com/kripken/emscripten-fastcomp/ 09aaa022c31e247bfb7b00882372733e6b27f007) (emscripten 1.37.9 : 1.37.9)
Target: x86_64-apple-darwin15.6.0

#include <cassert>

class Tested;

std::vector<Tested*> objects_that_were_constructed;

class Tested
{
public:
  Tested() {
    objects_that_were_constructed.push_back(this);
  }

  Tested(const Tested& other) {
    objects_that_were_constructed.push_back(this);
  }

  Tested& operator=(const Tested& other) {
    auto constructor_of_other_was_called =
     objects_that_were_constructed.end() != std::find(objects_that_were_constructed.begin(), objects_that_were_constructed.end(), &other);

    assert(constructor_of_other_was_called);

    // Leaving out the actual assignment code, as it's not relevant

    return *this;
  }

private:
  int state0 = 0;

  // Uncommenting the following line makes the test work
  // int state1 = 0;
};

Tested make_tested()
{
  return Tested();
}


int main() {
  Tested tested;
  tested = make_tested();

  return 0;
}
@kripken
Copy link
Member

kripken commented Apr 5, 2017

I assume this happens even without optimizations? If so, then it's almost certainly an upstream clang issue. I'd recommend verifying it still happens with upstream clang, and if so, filing a bug there.

@mkl-ableton
Copy link
Author

This happens without optimizations and also with https://github.com/kripken/emscripten-fastcomp/tree/incoming, but only with asmjs-unknown-emscripten as a target. I'll close this issue and reopen it on https://github.com/kripken/emscripten-fastcomp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants