Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-303

Investigate why explicit instantiations are needed when they weren't before

    Details

    • Type: Bug
    • Status: Won't Fix
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw
    • Labels:
    • Team:
      Alert Production

      Description

      There are a few undefined symbols in meas_algorithms due to missing explicit instantiations in afw. I'll give this a shot.

        Attachments

          Issue Links

            Activity

            Hide
            jbosch Jim Bosch added a comment -

            I've taken a look at the SchemaImpl::find case, and I think the new instantiation may indeed be necessary. At least based on that one case, I have no objection to leaving the new instantiations in. One of two things may have changed to trigger the break:

            1. One of the methods in afw::table that calls it is inlineable (it's a one-liner defined in Schema.h). If the compiler is now choosing to inline that in code that calls it in meas_algorithms, it could appear that meas_algorithms needs access to the implementation, which is only present in Schema.cc in afw.

            2. However, the implementation in Schema.cc in afw is definitely always instantiated, even though it wasn't previously explicitly instantiated: it's called by another function in the same file which is explicitly instantiated. All the google searches I've tried on this subject result in answers to simpler questions, but my understanding is that the standard is silent on whether implicit template instantiations in one library must be available to another library, which is what we'd then be relying on here. In any case, GCC's page on how it handles cross-library template instantiations says that their implementation model (the "Borland model") isn't the only one, and it sounds like behavior might be different under the other model. If this is what changed in Clang's behavior, that's potentially more problematic, as I think we rely on this trick (relying on one explicit instantiation to instantiate something else implicitly) in other places, and we could be seeing mysterious new linker errors for a while as we write new code that relies on things we haven't truly explicitly instantiated. The good news is that the areas where I've seen us use this trick the most are in the plugin framework in meas_algorithms and the Formatters, and those are already slated for replacement.

            Show
            jbosch Jim Bosch added a comment - I've taken a look at the SchemaImpl::find case, and I think the new instantiation may indeed be necessary. At least based on that one case, I have no objection to leaving the new instantiations in. One of two things may have changed to trigger the break: 1. One of the methods in afw::table that calls it is inlineable (it's a one-liner defined in Schema.h). If the compiler is now choosing to inline that in code that calls it in meas_algorithms, it could appear that meas_algorithms needs access to the implementation, which is only present in Schema.cc in afw. 2. However, the implementation in Schema.cc in afw is definitely always instantiated, even though it wasn't previously explicitly instantiated: it's called by another function in the same file which is explicitly instantiated. All the google searches I've tried on this subject result in answers to simpler questions, but my understanding is that the standard is silent on whether implicit template instantiations in one library must be available to another library, which is what we'd then be relying on here. In any case, GCC's page on how it handles cross-library template instantiations says that their implementation model (the "Borland model") isn't the only one, and it sounds like behavior might be different under the other model. If this is what changed in Clang's behavior, that's potentially more problematic, as I think we rely on this trick (relying on one explicit instantiation to instantiate something else implicitly) in other places, and we could be seeing mysterious new linker errors for a while as we write new code that relies on things we haven't truly explicitly instantiated. The good news is that the areas where I've seen us use this trick the most are in the plugin framework in meas_algorithms and the Formatters, and those are already slated for replacement.
            Hide
            ktl Kian-Tat Lim added a comment -

            I don't think this is currently a problem; if it recurs, we can open a new ticket.

            Show
            ktl Kian-Tat Lim added a comment - I don't think this is currently a problem; if it recurs, we can open a new ticket.

              People

              • Assignee:
                krughoff Simon Krughoff
                Reporter:
                krughoff Simon Krughoff
                Watchers:
                Jim Bosch, Kian-Tat Lim, Simon Krughoff
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel