This patch updates the code added in D143888 to avoid
overwriting some part of the types when updating it
for unlimited polymorphic types.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| flang/unittests/Optimizer/FIRTypesTest.cpp | ||
|---|---|---|
| 150 | The unit test seems to fail somewhere in a dyn_cast. | |
| flang/unittests/Optimizer/FIRTypesTest.cpp | ||
|---|---|---|
| 150 | I'll try to reproduce this on my machine. | |
All builds and tests correctly for me using GCC 9.3.0. But you should fix Jean's problem before updating.
| flang/include/flang/Optimizer/Dialect/FIRType.h | ||
|---|---|---|
| 347 | "intrinsic type" should read "intrinsic types" | |
| 353 | This function seems to call itself recursively. Given that, what's the effect of the "inline" declaration? | |
LGTM
| flang/include/flang/Optimizer/Dialect/FIRType.h | ||
|---|---|---|
| 353 | In C++, 'the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred"' (quote from [1]). The keyword "inline" allows one to define a (non-member) function in a header that may be included in several compilation unit (it would otherwise be an error since there would be multiple definition). Hence it is required here. It is actually not a guarantee that the compiler will inline the function at the call sites, but only a strong hint to try. So there is no issue using it on recursive functions: the C++ compiler won't blindly inline it again and again until it blows. See [1] for a better explanation. | |
"intrinsic type" should read "intrinsic types"