| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Flang] Don't use FortranDecimal for runtime (#121997) Avoid using the same library for runtime and compiler. FortranDecimal was used in two ways: 1. As an auxiliary library needed for libFortranRuntime.a. This patch adds the two source files of FortranDecimal directly into FortranRuntime, so FortranRuntime is not used anymore. 2. As a library used by the Flang compiler. As the only remaining use of the library, extra CMake code to make it compatible with the runtime can be removed. Before this PR, enable_cuda_compilation is applied to FortranDecimal which causes everything that links to it, including flang (the compiler), to depend on libcudart when CUDA support is enabled. Having two runtime library just makes everything more complicated while the user ideally should not be concerned with how the runtime is structured internally. Some logic was copied for FortranDecimal because of this, such as the ability to be compiled out-of tree (b75a3c9f31c1ffdc9856aee32991d8129b372ee7) which is undocumented, the logic to link against the various versions of Microsofts runtime library (#70833), and avoiding dependency on the C++ runtime (7783bba22c7add678d796741d30669c73159b3d8). | 1 年前 | |
[flang] Disable some warnings with ineluctable false positives (#167714) There are a few well-meaning warnings for some cases of the FPTR= argument to C_F_POINTER() that can be false positives, since the restrictions in the standard are dependent on the source of the CPTR= argument. Further, there is no way to alter a program to avoid these warnings, so one cannot compile a correct and conforming program with -pedantic -Werror. Disable these warnings. Fixes https://github.com/llvm/llvm-project/issues/167470. | 9 个月前 | |
Revert " [clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)" (#169397) This reverts commit 3773bbe and relands the last revert attempt 40334b8. 3773bbe broke the build for the build configuration described in here: https://github.com/llvm/llvm-project/pull/165277#issuecomment-3572432250 | 8 个月前 | |
Reland "[clang] Refactor option-related code from clangDriver into new clangOptions library" (#167374) This relands #167348. The original PR was reverted due to a reported build failure, which was later diagnosed as a local issue in the developer’s checkout or build state. See discussion here: https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964 No additional changes have been made in this reland. | 9 个月前 | |
[flang][OpenMP] Tolerate compiler directives in loop constructs (#169346) PR168884 flagged compiler directives (!dir$ ...) inside OpenMP loop constructs as errors. This caused some customer applications to fail to compile (issue 169229). Downgrade the error to a warning, and gracefully ignore compiler directives when lowering loop constructs to MLIR. Fixes https://github.com/llvm/llvm-project/issues/169229 | 8 个月前 | |
[flang][cuda] Add support for cluster_block_index in cooperative groups (#169427) | 8 个月前 | |
[flang][OpenMP] Better diagnostics for invalid or misplaced directives (#168885) Add two more AST nodes, one for a misplaced end-directive, and one for an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ"). Emit error messages when either node is encountered in semantic analysis. | 8 个月前 | |
[flang][OpenMP] Tolerate compiler directives in loop constructs (#169346) PR168884 flagged compiler directives (!dir$ ...) inside OpenMP loop constructs as errors. This caused some customer applications to fail to compile (issue 169229). Downgrade the error to a warning, and gracefully ignore compiler directives when lowering loop constructs to MLIR. Fixes https://github.com/llvm/llvm-project/issues/169229 | 8 个月前 | |
[flang] Implement IGNORE_TKR(P) (#165469) Implemented IGNORE_TKR(P), which allows ignoring pointer and allocatable matching (can pass an allocatable array to routine with pointer array argument and vice versa). Updated documentation. | 9 个月前 | |
[Flang/Flang-RT] Fix OldUnit tests on Windows (#150734) Flang and Flang-RT have two flavours of unittests: 1. GTest unittests, using lit's lit.formats.GoogleTest format ending with Tests${CMAKE_EXECUTABLE_SUFFIX} 2. "non-GTest" or "OldUnit" unittests, a plain executable ending with .test${CMAKE_EXECUTABLE_SUFFIX} Both executables are emitted into the same unittests/ subdirectory. When running ... 1. tests/Unit/lit.cfg.py, only considers executable ending with Tests (or Tests.exe on Windows), hence skips the non-GTest tests. 2. tests/NonGtestUnit/lit.cfg.py considers all tests ending with .test or .exe. On Windows, The GTest unitests also end with .exe. In Flang-RT, .exe is considered an extension for non-GTest unitests which causes tests such as Flang's RuntimeTests.exe to be executed for both on Windows. This particular test includes a file write test, using a hard-coded filename ucsfile. If the two instances are executed concurrently, they might interfere with each other reading/writing ucsfile which results in a flaky test. This patch avoids the redundant execution by requiring the suffix .test.exe on Windows. lit has to be modified because it uses os.path.splitext the extract the extension, which would only recognize the last component. It was changed from the orginal endswith in c865abe747aa72192f02ebfdcabe730f2553e42f for unknown reasons. In Flang, .exe is not considered a suffix for non-GTest unittests and hence they are not run at all. Fixing by also added .test.exe as valid suffix, like with Flang-RT. Unfortunately, the Evaluate/real.test.exe test was failing on Windows: FAIL: flang-OldUnit :: Evaluate/real.test.exe (3592 of 3592) ******************** TEST 'flang-OldUnit :: Evaluate/real.test.exe' FAILED ******************** ..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10 0 0x800001 * 0xbf7ffffe ..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10 0 0x800001 * 0x3f7ffffe ..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10 0 0x80800001 * 0xbf7ffffe ..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10 0 0x80800001 * 0x3f7ffffe ... This is due to the __x86_64__ macro not being set by Microsoft's cl.exe and hence floating point status flags not being read out. The equivalent macro for Microsofts compiler is _M_X64 (or _M_X64). | 1 年前 | |
[flang][mlir] Migrate to free create functions. NFC. (#164657) See https://discourse.llvm.org/t/psa-opty-create-now-with-100-more-tab-complete/87339. I plan to mark these as deprecated in https://github.com/llvm/llvm-project/pull/164649. | 9 个月前 | |
[NFC][flang][OpenMP] Create FortranUtils lib and move createMapInfoOp to it (#154483) | 11 个月前 |