Skip to content

Fix: Intel classic (icpc) build error "EKinetic is not a template" - #7929

Merged
mohanchen merged 2 commits into
deepmodeling:developfrom
Flying-dragon-boxing:fix-icpc-ekinetic
Sep 8, 2026
Merged

Fix: Intel classic (icpc) build error "EKinetic is not a template"#7929
mohanchen merged 2 commits into
deepmodeling:developfrom
Flying-dragon-boxing:fix-icpc-ekinetic

Conversation

@Flying-dragon-boxing

Copy link
Copy Markdown
Collaborator

Reminder

  • I have read AGENTS.md and docs/developers_guide/agent_governance.md.
  • I have linked an issue or explained why this PR does not need one.
  • I have added adequate unit tests and/or case tests, or explained why not.
  • I have listed the exact verification commands run and their results.
  • I have described user-visible behavior changes, including INPUT parameter changes.
  • I have explained core-module impact for ESolver, HSolver, ElecState, Hamilt, Operator, Psi, or other source/ changes.
  • I have requested any needed governance exception below.

Linked Issue

Fix #7927

Unit Tests and/or Case Tests for my changes

  • Commands run:
    • icpc 2022.1 (Intel classic, Rocky Linux 8.8, LCAO+LIBRI+PEXSI+MLALGO enabled): direct compilation of source/source_lcao/module_operator_lcao/ekinetic.cpp — previously failing with error: EKinetic is not a template, now compiles.
    • g++ -std=gnu++14 -fsyntax-only source/source_lcao/module_operator_lcao/ekinetic.cpp with the standard ABACUS define set (__EXX, __LCAO, __MPI, ...), GCC 11.4.0.
    • g++ -std=gnu++14 -fsyntax-only source/source_pw/module_pwdft/op_pw_ekin.cpp (same flags).
    • Forced dual-include TUs (op_pw_ekin.h + ekinetic.h, both include orders) with g++ -std=gnu++11 -fsyntax-only: previously failing on GCC with 'EKinetic'/'Ekinetic' is not a class template; now clean in both orders.
  • Result summary: all pass.
  • Checks not run, with reason: no new unit test added — this is a compile-compatibility fix with zero runtime behavior change; no Intel classic CI exists, and the affected TUs are covered by the existing GCC/icpx CI builds.

What's changed?

  • source_lcao/module_operator_lcao/ekinetic.cpp: the out-of-line destructor of the partial specialization EKinetic<OperatorLCAO<TK,TR>> is named plainly again (~EKinetic()), reverting the template-argument form ~EKinetic<hamilt::OperatorLCAO<TK, TR>>() introduced by bbd23ca (DFT+U refactor, step 6 #7879), which icpc's EDG frontend cannot resolve ("EKinetic is not a template"; the injected-class-name of the partial specialization is found as a type and cannot take a template argument list in this context). GCC/Clang(icpx) accept both forms, so GCC CI never caught it.
  • source_lcao/module_operator_lcao/ekinetic.h, source_pw/module_pwdft/op_pw_ekin.h: removed the inner #ifndef __EKINETICTEMPLATE guard blocks. Both headers shared that one macro, so any TU including both headers (in either order) skipped the second primary template and failed — on any compiler, GCC included (currently unreachable in our build graph, but a latent hazard). The outer include guards already prevent double inclusion, and the change also drops the reserved double-underscore identifier.

Governance Notes

  • INPUT/docs changes: none; no user-visible behavior change.
  • Core module impact: Operator layer only (LCAO kinetic operator definition + PW kinetic operator header). No runtime behavior change.
  • Exceptions requested: none.

ekinetic.h (hamilt::EKinetic) and op_pw_ekin.h (hamilt::Ekinetic) share
the __EKINETICTEMPLATE guard around their primary template declarations,
but the two class templates have different names. A TU that includes
op_pw_ekin.h before ekinetic.h would skip the EKinetic primary template
and fail on the EKinetic<OperatorLCAO<TK,TR>> specialization with
'EKinetic is not a template' on any compiler. Declare each primary
template unconditionally inside its own header guard.
icpc (Intel Classic 2021.6/2022.1) rejects the out-of-line destructor
definition

  hamilt::EKinetic<hamilt::OperatorLCAO<TK, TR>>::~EKinetic<hamilt::OperatorLCAO<TK, TR>>()

with 'EKinetic is not a template', while GCC and icpx accept it. Naming
the destructor with the plain form ~EKinetic() is accepted by all three
compilers. This is the actual cause of the ekinetic.cpp build failure
with icpc reported for v3.11.0-beta9.
Copilot AI lite review requested due to automatic review settings September 7, 2026 13:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The changes are narrowly scoped to a verified compile-compatibility fix and remove a latent include-order hazard without altering runtime behavior.

Pull request overview

This pull request fixes a compiler-compatibility regression affecting Intel classic (icpc/EDG) by correcting the out-of-line destructor spelling for a partial specialization of hamilt::EKinetic, and removes a shared internal macro guard that could break translation units including both LCAO and PW kinetic-operator headers.

Changes:

  • Fix icpc build failure by changing the out-of-line destructor definition of EKinetic<OperatorLCAO<TK,TR>> to use the injected-class-name form ::~EKinetic().
  • Remove the shared __EKINETICTEMPLATE inner guard blocks from both ekinetic.h and op_pw_ekin.h to prevent order-dependent missing template declarations (and drop a reserved double-underscore identifier).
  • Keep changes limited to compile-time behavior (no runtime logic changes).
File summaries
File Description
source/source_pw/module_pwdft/op_pw_ekin.h Removes shared inner macro guard around the primary Ekinetic template to avoid include-order hazards.
source/source_lcao/module_operator_lcao/ekinetic.h Removes shared inner macro guard around the primary EKinetic template (outer include guard remains).
source/source_lcao/module_operator_lcao/ekinetic.cpp Fixes the partial-specialization destructor out-of-line definition to be EDG/icpc-compatible.
Review details
  • Files reviewed: 3/3 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@mohanchen
mohanchen merged commit 6ea5cb4 into deepmodeling:develop Sep 8, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bugs Bugs that only solvable with sufficient knowledge of DFT Refactor Refactor ABACUS codes

Projects

None yet

4 participants