[PATCH] Fix asserts about emitting constexpr methods twice during dllexport explicit instantiation (PR21718)

Richard Smith richard at metafoo.co.uk
Wed Dec 17 11:11:06 PST 2014


After some investigation, it seems that the issue is a more fundamental problem in the `ASTConsumer` interface; there are various cases where we call `HandleTopLevelDecl` multiple times on the same declaration. We get away with this if `DeclMustBeEmitted` is false for the declaration, but not otherwise. Here's another testcase not involving `constexpr` nor `dllexport`:

  template<typename T> struct S { __attribute__((used)) auto f() { return 0; } };
  int k = S<int>().f();
  template struct S<int>;

We also observed that we're missing `HandleTopLevelDecl` (or similar) calls when implicitly defining special member functions (which also acts to mask the issue in a lot of cases). This causes seemingly-wrong code generation for cases like:

  struct S { __attribute__((used)) S() = default; } s;

GCC generates and retains a definition of S::S() in this case.

One possible fix:

- stop calling `HandleTopLevelDecl` except in cases where we just finished defining the entity (remove the call from explicit instantiation and from the `dllexport` code and perhaps add calls to `DefineImplicit*`)
- add a new `ASTConsumer` callback for the case where the properties of an existing declaration have changed (for instance, it's switched from being not-`dllexport` to being `dllexport`, or it's switched from being an implicit instantiation to being an explicit instantiation)

We might also wish to switch away from using `HandleTopLevelDecl` for template instantiations (and special member function definitions, if we ever add it there) because they're not really top-level declarations (they're adding a definition to an existing declaration in many cases), and instead call something like `HandleInlineMethodDefinition` in those cases. However, that appears to be merely a cleanup rather than a correctness fix.


http://reviews.llvm.org/D6674

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list