[qt/clang/llvm-project]: Summary of bulk changes made
KDE Git Services - Bulk Change <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/skatrak/allocate-module-02-ctor'.
Changed from 0000000000000000000000000000000000000000 to 3aaf57f85f8829b6207c3dc1b915be2f6bb34fce
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.
This change contains the following new commits:
Git commit b04f5be2d7087e5538023b1a848ac7483fc2edc4 by Sergio Afonso on 13/08/2026 at 15:46..
[Flang][OpenMP] Prevent allocate directive ICE on module variables
The current lowering implementation for `allocate` directives assumes
the MLIR function in which it is creating operations will still be there
by finalization time, so that it can add a deallocation call.
When lowering Fortran modules, this is not the case (lowering happens
in a temporary dummy function) and it results in a compiler crash
while running cleanup callbacks. This patch adds a TODO for this case.
https://invent.kde.org/qt/clang/llvm-project/-/commit/b04f5be2d7087e5538023b1a848ac7483fc2edc4
Git commit 3aaf57f85f8829b6207c3dc1b915be2f6bb34fce by Sergio Afonso on 13/08/2026 at 15:46..
[Flang][OpenMP] PoC module support for allocate directives
This patch implements partial support for `allocate` on Fortran
module variables, based on adding global constructor functions for each
impacted variable.
Shared as a proof of concept, because I have a few concerns about it:
1. It appears that Clang ignores `allocate` directives on global
variables instead. Is that the expected behavior?
2. The existing implementation for `allocate` in Flang doesn't
actually impact where the memory used for a variable resides. It
allocates/deallocates extra memory for it using OpenMP internal
compiler calls but then that storage is never used. The original
alloca is still used. This addition suffers from the same issue:
global constructors allocate extra memory that is never used to
update in any way the associated global variable or its users.
3. No `omp.allocate_free` (should be `omp.allocate.free`) can be added
by this approach.
4. The representation of `omp.allocate_dir` (should be `omp.allocate`)
doesn't seem prepared to actually allow the new value to be used by
other operations, as it returns no values.
I think that, before even thinking about adding module support for this
directive (if ignoring it isn't what the spec prescribes), proper
end-to-end basic support for it should be implemented first. What it
currently does is miscompiling and silently ignoring it rather than
warning the user about this directive being unimplemented.
Assisted-by: Claude Opus 4.6
https://invent.kde.org/qt/clang/llvm-project/-/commit/3aaf57f85f8829b6207c3dc1b915be2f6bb34fce