<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/flang/lib/Lower/CallInterface.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[flang] Fix lowering of unused dummy procedure pointers (#155649)</title>
<updated>2025-09-08T11:39:07+00:00</updated>
<author>
<name>Leandro Lupori</name>
<email>leandro.lupori@linaro.org</email>
</author>
<published>2025-09-08T11:39:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3dc314b8519099b1da43d01302d3d1710a6ccb3c'/>
<id>3dc314b8519099b1da43d01302d3d1710a6ccb3c</id>
<content type='text'>
Fixes #126453</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes #126453</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Migrate away from std::nullopt (NFC) (#145928)</title>
<updated>2025-06-26T19:41:49+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-26T19:41:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=938cdb30f16f4fefc4c7177d7a47fb571a297c43'/>
<id>938cdb30f16f4fefc4c7177d7a47fb571a297c43</id>
<content type='text'>
ArrayRef has a constructor that accepts std::nullopt.  This
constructor dates back to the days when we still had llvm::Optional.

Since the use of std::nullopt outside the context of std::optional is
kind of abuse and not intuitive to new comers, I would like to move
away from the constructor and eventually remove it.

This patch replaces std::nullopt with {}.  There are a couple of
places where std::nullopt is replaced with TypeRange() to accommodate
perfect forwarding.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ArrayRef has a constructor that accepts std::nullopt.  This
constructor dates back to the days when we still had llvm::Optional.

Since the use of std::nullopt outside the context of std::optional is
kind of abuse and not intuitive to new comers, I would like to move
away from the constructor and eventually remove it.

This patch replaces std::nullopt with {}.  There are a couple of
places where std::nullopt is replaced with TypeRange() to accommodate
perfect forwarding.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][openacc] Allow open acc routines from other modules. (#136012)</title>
<updated>2025-05-09T18:12:24+00:00</updated>
<author>
<name>Andre Kuhlenschmidt</name>
<email>andre.kuhlenschmidt@gmail.com</email>
</author>
<published>2025-05-09T18:12:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4d9479fa8f4e949bc4c5768477cd36687c1c6b29'/>
<id>4d9479fa8f4e949bc4c5768477cd36687c1c6b29</id>
<content type='text'>
OpenACC routines annotations in separate compilation units currently get
ignored, which leads to errors in compilation. There are two reason for
currently ignoring open acc routine information and this PR is
addressing both.
- The module file reader doesn't read back in openacc directives from
module files.
  - Simple fix in `flang/lib/Semantics/mod-file.cpp`
- The lowering to HLFIR doesn't generate routine directives for symbols
imported from other modules that are openacc routines.
- This is the majority of this diff, and is address by the changes that
start in `flang/lib/Lower/CallInterface.cpp`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
OpenACC routines annotations in separate compilation units currently get
ignored, which leads to errors in compilation. There are two reason for
currently ignoring open acc routine information and this PR is
addressing both.
- The module file reader doesn't read back in openacc directives from
module files.
  - Simple fix in `flang/lib/Semantics/mod-file.cpp`
- The lowering to HLFIR doesn't generate routine directives for symbols
imported from other modules that are openacc routines.
- This is the majority of this diff, and is address by the changes that
start in `flang/lib/Lower/CallInterface.cpp`.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Add lowering of volatile references (#132486)</title>
<updated>2025-04-30T15:46:33+00:00</updated>
<author>
<name>Asher Mancinelli</name>
<email>ashermancinelli@gmail.com</email>
</author>
<published>2025-04-30T15:46:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8836bce84208737f5807c396345a41e688d3ec11'/>
<id>8836bce84208737f5807c396345a41e688d3ec11</id>
<content type='text'>
[RFC on
discourse](https://discourse.llvm.org/t/rfc-volatile-representation-in-flang/85404/1)

Flang currently lacks support for volatile variables. For some cases,
the compiler produces TODO error messages and others are ignored. Some
of our tests are like the example from _C.4 Clause 8 notes: The VOLATILE
attribute (8.5.20)_ and require volatile variables.

Prior commits:
```
c9ec1bc753b0 [flang] Handle volatility in lowering and codegen (#135311)
e42f8609858f [flang][nfc] Support volatility in Fir ops (#134858)
b2711e1526f9 [flang][nfc] Support volatile on ref, box, and class types (#134386)
```</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[RFC on
discourse](https://discourse.llvm.org/t/rfc-volatile-representation-in-flang/85404/1)

Flang currently lacks support for volatile variables. For some cases,
the compiler produces TODO error messages and others are ignored. Some
of our tests are like the example from _C.4 Clause 8 notes: The VOLATILE
attribute (8.5.20)_ and require volatile variables.

Prior commits:
```
c9ec1bc753b0 [flang] Handle volatility in lowering and codegen (#135311)
e42f8609858f [flang][nfc] Support volatility in Fir ops (#134858)
b2711e1526f9 [flang][nfc] Support volatile on ref, box, and class types (#134386)
```</pre>
</div>
</content>
</entry>
<entry>
<title>[Flang] Move non-common headers to FortranSupport (#124416)</title>
<updated>2025-02-06T14:29:10+00:00</updated>
<author>
<name>Michael Kruse</name>
<email>llvm-project@meinersbur.de</email>
</author>
<published>2025-02-06T14:29:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b815a3942a0b0a9e7aab6b269ffdb0e93abc4368'/>
<id>b815a3942a0b0a9e7aab6b269ffdb0e93abc4368</id>
<content type='text'>
Move non-common files from FortranCommon to FortranSupport (analogous to
LLVMSupport) such that

* declarations and definitions that are only used by the Flang compiler,
but not by the runtime, are moved to FortranSupport

* declarations and definitions that are used by both ("common"), the
compiler and the runtime, remain in FortranCommon

* generic STL-like/ADT/utility classes and algorithms remain in
FortranCommon

This allows a for cleaner separation between compiler and runtime
components, which are compiled differently. For instance, runtime
sources must not use STL's `&lt;optional&gt;` which causes problems with CUDA
support. Instead, the surrogate header `flang/Common/optional.h` must be
used. This PR fixes this for `fast-int-sel.h`.

Declarations in include/Runtime are also used by both, but are
header-only. `ISO_Fortran_binding_wrapper.h`, a header used by compiler
and runtime, is also moved into FortranCommon.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move non-common files from FortranCommon to FortranSupport (analogous to
LLVMSupport) such that

* declarations and definitions that are only used by the Flang compiler,
but not by the runtime, are moved to FortranSupport

* declarations and definitions that are used by both ("common"), the
compiler and the runtime, remain in FortranCommon

* generic STL-like/ADT/utility classes and algorithms remain in
FortranCommon

This allows a for cleaner separation between compiler and runtime
components, which are compiled differently. For instance, runtime
sources must not use STL's `&lt;optional&gt;` which causes problems with CUDA
support. Instead, the surrogate header `flang/Common/optional.h` must be
used. This PR fixes this for `fast-int-sel.h`.

Declarations in include/Runtime are also used by both, but are
header-only. `ISO_Fortran_binding_wrapper.h`, a header used by compiler
and runtime, is also moved into FortranCommon.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Don't take corank from actual intrinsic argument (#124029)</title>
<updated>2025-01-27T19:57:01+00:00</updated>
<author>
<name>Peter Klausler</name>
<email>pklausler@nvidia.com</email>
</author>
<published>2025-01-27T19:57:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d732c86c928271cf3a829d95a1fcc560894ab8e4'/>
<id>d732c86c928271cf3a829d95a1fcc560894ab8e4</id>
<content type='text'>
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed reference to local
coarray data as an actual argument, don't add the corank of the actual
argument to those characteristics.

Also clean up the TypeAndShape characteristics class a little; the
Attr::Coarray is redundant since the corank() accessor can be used to
the same effect.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed reference to local
coarray data as an actual argument, don't add the corank of the actual
argument to those characteristics.

Also clean up the TypeAndShape characteristics class a little; the
Attr::Coarray is redundant since the corank() accessor can be used to
the same effect.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Add FIR attributes and apply them to dummy arguments (#115686)</title>
<updated>2024-11-14T05:18:26+00:00</updated>
<author>
<name>s-watanabe314</name>
<email>watanabe.shu-06@fujitsu.com</email>
</author>
<published>2024-11-14T05:18:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0b54e33fd5ab362dfa5eacb61d7cbdb9cc3a89ac'/>
<id>0b54e33fd5ab362dfa5eacb61d7cbdb9cc3a89ac</id>
<content type='text'>
To determine if a function's dummy argument is nocapture, add the
asynchronous attribute to the FIR attribute. The volatile attribute will
also be used to determine nocapture assignment, but this will remain a
TODO until other processing using volatile is implemented.

I will post another patch to apply nocapture. See also the discussion in
the following discourse post.

https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To determine if a function's dummy argument is nocapture, add the
asynchronous attribute to the FIR attribute. The volatile attribute will
also be used to determine nocapture assignment, but this will remain a
TODO until other processing using volatile is implemented.

I will post another patch to apply nocapture. See also the discussion in
the following discourse post.

https://discourse.llvm.org/t/applying-the-nocapture-attribute-to-reference-passed-arguments-in-fortran-subroutines/81401</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] add fir.proc_attrs attributes to func.func (#110002)</title>
<updated>2024-09-26T09:11:44+00:00</updated>
<author>
<name>jeanPerier</name>
<email>jperier@nvidia.com</email>
</author>
<published>2024-09-26T09:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d9250061e10b82f82d9833009f6565775578ee58'/>
<id>d9250061e10b82f82d9833009f6565775578ee58</id>
<content type='text'>
BIND(C) ABI need care in the TargetRewrite pass. currently, we are not
able to accurately identify fun.func that are BIND(C) in FIR (the
fir.bindc_name is used in other contexts, like for program names).

This patch adds the fir.proc_attrs to func.func just like it was done
for calls recently. This replace the previous named attribute for
PURE/ELEMENTAL/RECURSIVE (note that RECURSIVE is changed to
NON_RECURSIVE, which brings more data since RECURSIVE is the default for
procedures that do not have explicit RECURSIVE/NON_RECUSRIVE
attributes).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BIND(C) ABI need care in the TargetRewrite pass. currently, we are not
able to accurately identify fun.func that are BIND(C) in FIR (the
fir.bindc_name is used in other contexts, like for program names).

This patch adds the fir.proc_attrs to func.func just like it was done
for calls recently. This replace the previous named attribute for
PURE/ELEMENTAL/RECURSIVE (note that RECURSIVE is changed to
NON_RECURSIVE, which brings more data since RECURSIVE is the default for
procedures that do not have explicit RECURSIVE/NON_RECUSRIVE
attributes).</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] translate pure and elemental attribute in FIR (#109954)</title>
<updated>2024-09-25T14:45:47+00:00</updated>
<author>
<name>jeanPerier</name>
<email>jperier@nvidia.com</email>
</author>
<published>2024-09-25T14:45:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3be8e3ad0c424dbeb9e4c8401174335e106a2d5d'/>
<id>3be8e3ad0c424dbeb9e4c8401174335e106a2d5d</id>
<content type='text'>
Follow-up from a previous patch that turned bind_c into an enum for
procedure attribute.

This patch carries the elemental and pure Fortran attribute into FIR so
that the optimizer can leverage that info in the future (I think debug
info may also need to know these aspects since DWARF has DW_AT_elemental
and DW_AT_pure nodes).

SIMPLE from F2023 will be translated once it is handled in the
front-end.

NON_RECURSIVE is only meaningful on func.func since we are not
guaranteed to know that aspect on the caller side (it is not part of
Fortran characteristics). There is a DW_AT_recursive DWARF node. I will
do it while dealing with func.func attributes.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Follow-up from a previous patch that turned bind_c into an enum for
procedure attribute.

This patch carries the elemental and pure Fortran attribute into FIR so
that the optimizer can leverage that info in the future (I think debug
info may also need to know these aspects since DWARF has DW_AT_elemental
and DW_AT_pure nodes).

SIMPLE from F2023 will be translated once it is handled in the
front-end.

NON_RECURSIVE is only meaningful on func.func since we are not
guaranteed to know that aspect on the caller side (it is not part of
Fortran characteristics). There is a DW_AT_recursive DWARF node. I will
do it while dealing with func.func attributes.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] harden TypeAndShape for assumed-ranks (#96234)</title>
<updated>2024-06-24T08:21:04+00:00</updated>
<author>
<name>jeanPerier</name>
<email>jperier@nvidia.com</email>
</author>
<published>2024-06-24T08:21:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=73cf014223fed1947f725f7debcf19b8f54448b5'/>
<id>73cf014223fed1947f725f7debcf19b8f54448b5</id>
<content type='text'>
SIZEOF and C_SIZEOF were broken for assumed-ranks because
`TypeAndShape::MeasureSizeInBytes` behaved as a scalar because the
`TypeAndShape::shape_` member was the same for scalar and assumed-ranks.

The easy fix would have been to add special handling in
`MeasureSizeInBytes` for assumed-ranks using the TypeAndShape
attributes, but I think this solution would leave `TypeAndShape::shape_`
manipulation fragile to future developers. Hence, I went for the
solution that turn shape_ into a `std::optional&lt;Shape&gt;`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SIZEOF and C_SIZEOF were broken for assumed-ranks because
`TypeAndShape::MeasureSizeInBytes` behaved as a scalar because the
`TypeAndShape::shape_` member was the same for scalar and assumed-ranks.

The easy fix would have been to add special handling in
`MeasureSizeInBytes` for assumed-ranks using the TypeAndShape
attributes, but I think this solution would leave `TypeAndShape::shape_`
manipulation fragile to future developers. Hence, I went for the
solution that turn shape_ into a `std::optional&lt;Shape&gt;`.</pre>
</div>
</content>
</entry>
</feed>
