TTobias Hieta[flang][test] Don't require .exe suffix.
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang][driver] Add -fintrinsic-modules-path option Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D97080 | 5 年前 | |
[flang] Runs FIR SimplifyRegionLitePass pass after calling the inliner In flang pipeline, the inliner calls createCanonicalizerPass with the region simplification disabled. The inliner pass does canonicalization even if no inlining happens. After canonicalization, FIR lite region simplification must be called to get rid of unreachable regions. This code exposes the need to run SimplifyRegionLitePass after the inliner is called with FIR pipeline. Differential Revision: https://reviews.llvm.org/D130484 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][Driver] Refine _when_ driver diagnostics are formatted This patch refines //when// driver diagnostics are formatted so that flang-new and flang-new -fc1 behave consistently with clang and clang -cc1, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ! file.f90 program m integer :: i = k end In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k Before this change, none of the above would be formatted. Note also that the default behaviour in flang-new is different to flang-new -fc1 (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in createAndPopulateDiagOpts in driver.cpp. That's where the driver's DiagnosticEngine options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling getLastArg rather than in driver.cpp. In Clang's Options.td, defm color_diagnostics is replaced with two separate definitions: def fcolor_diagnostics and def fno_color_diagnostics. That's because originally color_diagnostics derived from OptInCC1FFlag, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in clang -cc1 (i.e. to keep -fno-color-diagnostics unavailable in clang -cc1) and to implement similar behaviour in flang-new -fc1, we can't re-use OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164 | 3 年前 | |
[flang][Driver] Refine _when_ driver diagnostics are formatted This patch refines //when// driver diagnostics are formatted so that flang-new and flang-new -fc1 behave consistently with clang and clang -cc1, respectively. This change only applies to driver diagnostics. Scanning, parsing and semantic diagnostics are separate and not covered here. **NEW BEHAVIOUR** To illustrate the new behaviour, consider the following input file: ! file.f90 program m integer :: i = k end In the following invocations, "error: Semantic errors in file.f90" _will be_ formatted: $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 -fcolor-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k However, in the following invocations, "error: Semantic errors in file.f90" _will not be_ formatted: $ flang-new -fno-color-diagnostics file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k $ flang-new -fc1 file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k Before this change, none of the above would be formatted. Note also that the default behaviour in flang-new is different to flang-new -fc1 (this is consistent with Clang). **NOTES ON IMPLEMENTATION** Note that the diagnostic options are parsed in createAndPopulateDiagOpts in driver.cpp. That's where the driver's DiagnosticEngine options are set. Like most command-line compiler driver options, these flags are "claimed" in Flang.cpp (i.e. when creating a frontend driver invocation) by calling getLastArg rather than in driver.cpp. In Clang's Options.td, defm color_diagnostics is replaced with two separate definitions: def fcolor_diagnostics and def fno_color_diagnostics. That's because originally color_diagnostics derived from OptInCC1FFlag, which is a multiclass for opt-in options in CC1. In order to preserve the current behaviour in clang -cc1 (i.e. to keep -fno-color-diagnostics unavailable in clang -cc1) and to implement similar behaviour in flang-new -fc1, we can't re-use OptInCC1FFlag`. Formatting is only available in consoles that support it and will normally mean that the message is printed in bold + color. Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D126164 | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][driver] Fix opt-level option parsing This update makes sure that flang-new -O2 -O0 will run at -O0 rather than -O2. This bug was identified and originally fixed by Vyacheslav Zakharin in https://reviews.llvm.org/D130035. I've extracted the fix into a separate patch. co-authored by: Vyacheslav Zakharin <vyacheslav.p.zakharin@intel.com> Differential Revision: https://reviews.llvm.org/D130104 | 3 年前 | |
[flang] Add ExternalNameConversionPass to pass pipeline This seems to be the consensus in https://github.com/flang-compiler/f18-llvm-project/issues/1316 The patch adds ExternalNameConversion to the default FIR CodeGen pass pipeline, right before the FIRtoLLVM pass. It also adds a flag to optionally disable it, and sets it in tco. In other words, flang-new and flang-new -fc1 will both run the pass by default, whereas tco will not, so none of the tests need to be updated. Differential Revision: https://reviews.llvm.org/D121171 | 4 年前 | |
[flang][test] Remove RUN COMMAND/EXPECTED OUTPUT/INPUT markers from other directories | 3 年前 | |
[flang][test] Remove RUN COMMAND/EXPECTED OUTPUT/INPUT markers from other directories | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][driver] Add support for -save-temps This patch adds support for -save-temps in flang-new, Flang's compiler driver. The semantics of this option are inherited from Clang. The file extension for temporary Fortran preprocessed files is set to i. This is identical to what Clang uses for C (or C++) preprocessed files. I have tried researching what other compilers do here, but I couldn't find any definitive answers. One GFortran thread [1] suggests that indeed it is not clear what the right approach should be. Normally, various phases in Clang/Flang are combined. The -save-temps option works by forcing the compiler to run every phase separately. As there is no integrated assembler driver in Flang, user will have to use -save-temps together with -fno-integrated-as. Otherwise, an invocation to the integrated assembler would be generated generated, which is going to fail (i.e. something equivalent to clang -cc1as from Clang). There are no specific plans for implementing an integrated assembler for Flang for now. One possible solution would be to share it entirely with Clang. Note that on Windows you will get the following error when using -fno-integrated-as: bash flang-new: error: there is no external assembler that can be used on this platform Unfortunately, I don't have access to a Windows machine to investigate this. Instead, I marked the tests in this patch as unsupported on Windows. [1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615 Differential Revision: https://reviews.llvm.org/D124669 | 4 年前 | |
[flang][nfc] Move a test All option forwarding tests should be added to frontend-forwarding.f90 rather than files corresponding to various options. This patch moves such test for -mllvm accordingly. | 4 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][nfc] Remove flang-new-driver from LIT After merging https://reviews.llvm.org/D105811, flang-new-driver is no longer required. Differential Revision: https://reviews.llvm.org/D107990 | 4 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Don't require .exe suffix. The suffix is only added then the path the (lld-)link.exe is fully resolved. Otherwise it may stay "link" or "lld-link". On non-Windows platforms, lld-link also exists as a symbolic link to lld, such that the full the path to lld-link might also be resolved without .exe suffix in this case. Note that CLANG_DEFAULT_LINKER could be set to other linkers such as mold, in which case the test may still fail. This also applies to the non-Windows tests that require "ld" in the linker name. Fixes issue #56955 (cherry picked from commit 8c0979c8f7723306862b33583c6bdb1f4566a969) | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang] Runs FIR SimplifyRegionLitePass pass after calling the inliner In flang pipeline, the inliner calls createCanonicalizerPass with the region simplification disabled. The inliner pass does canonicalization even if no inlining happens. After canonicalization, FIR lite region simplification must be called to get rid of unreachable regions. This code exposes the need to run SimplifyRegionLitePass after the inliner is called with FIR pipeline. Differential Revision: https://reviews.llvm.org/D130484 | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang] Make the frontend driver error out when requesting multiple actions With this change, the following invocations will be treated as errors (multiple actions are specified): $ flang-new -fc1 -E -fsyntax-only file.95 $ flang-new -fc1 -fsyntax-only -fdebug-dump-symbols file.95 In the examples above it is not clear whether it is -fsyntax-only or the other action that is run (i.e. -E or -fdebug-dump-symbols). It makes sense to disallow such usage. This should also lead to cleaner and clearer tests (the RUN lines using %flang_fc1 will only allow one action). This change means that flang-new -fc1 and clang -cc1 will behave differently when multiple action options are specified. As frontend drivers are mostly used by compiler developers, this shouldn't affect or confuse the compiler end-users. Also, flang-new and clang remain consistent. Tests are updated accordingly. More specifically, I've made sure that every test specifies only one action. I've also taken the opportunity to simplify "multiple-input-files.f90" a bit. Differential Revision: https://reviews.llvm.org/D111781 | 4 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN COMMANDS/EXPECTED OUTPUT/INPUT markers from test/Driver Uses of these markers are contrary to all other llvm-project subprojects and carry no information for people who know the basics of a lit test. I understand that there is an argument "this makes beginners get started quickly" but I am unsure whether this is strong enough to deviate from all other projects. https://llvm.org/docs/TestingGuide.html covers the basics. Actually, some contributors were confused by the markers. Differential Revision: https://reviews.llvm.org/D128763 | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][driver] Add print function name Plugin example Replacing Hello World example Plugin with one that counts and prints the names of functions and subroutines. This involves changing the PluginParseTreeAction Plugin base class to inherit from PrescanAndSemaAction class to get access to the Parse Tree so that the Plugin can walk it. Additionally, there are tests of this new Plugin to check it prints the correct things in different circumstances. Depends on: D106137 Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D107089 | 4 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][driver] Support parsing response files Add support for reading response files in the flang driver. Response files contain command line arguments and are used whenever a command becomes longer than the shell/environment limit. Response files are recognized via the special "@path/to/response/file.rsp" syntax, which distinguishes them from other file inputs. This patch hardcodes GNU tokenization, since we don't have a CL mode for the driver. In the future we might want to add a --rsp-quoting command line option, like clang has, to accommodate Windows platforms. Differential Revision: https://reviews.llvm.org/D124846 | 4 年前 | |
[flang][driver] Add support for -save-temps This patch adds support for -save-temps in flang-new, Flang's compiler driver. The semantics of this option are inherited from Clang. The file extension for temporary Fortran preprocessed files is set to i. This is identical to what Clang uses for C (or C++) preprocessed files. I have tried researching what other compilers do here, but I couldn't find any definitive answers. One GFortran thread [1] suggests that indeed it is not clear what the right approach should be. Normally, various phases in Clang/Flang are combined. The -save-temps option works by forcing the compiler to run every phase separately. As there is no integrated assembler driver in Flang, user will have to use -save-temps together with -fno-integrated-as. Otherwise, an invocation to the integrated assembler would be generated generated, which is going to fail (i.e. something equivalent to clang -cc1as from Clang). There are no specific plans for implementing an integrated assembler for Flang for now. One possible solution would be to share it entirely with Clang. Note that on Windows you will get the following error when using -fno-integrated-as: bash flang-new: error: there is no external assembler that can be used on this platform Unfortunately, I don't have access to a Windows machine to investigate this. Instead, I marked the tests in this patch as unsupported on Windows. [1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615 Differential Revision: https://reviews.llvm.org/D124669 | 4 年前 | |
[flang][driver] Remove %flang-new from the LIT configuration %flang-new was introduced in the early days of the new driver to make a clear distinction between the tests for the current and the new driver. We have since introduced %flang (compiler driver) and %flang_fc1 (frontend driver) as the long term solution. This has allowed us to share tests between flang-new and f18. This patch replaces all uses of %flang-new with %flang and %flang_fc1. Some tests are reformatted so that all tests look uniform and are easier to follow. Where possible, ! REQUIRES: new-flang-driver is deleted so that more tests can be shared with f18. To facilitate this, f{no-}implicit-none are introduced in f18 with semantics identical to flang-new. Two tests are deleted rather than updated: * flang/test/Frontend/print-preprocess-C-file.f90 * flang/test/Frontend/print-preprocessed-file.f90 Instead, there is plenty of preprocessor tests in flang/test/Preprocessing/. Differential Revision: https://reviews.llvm.org/D100174 | 5 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][test] Remove RUN LINES?/EXPECTED OUTPUT.*/INPUT markers from test/Driver Follow-up to D128763. | 3 年前 | |
[flang][driver] Make driver accept -module-dir<value> -module-dir is Flang's equivalent for -J from GFortran (in fact, -J is an alias for -module-dir in Flang). Currently, only -module-dir <value> is accepted. However, -J (and other options for specifying various paths) accepts -J<value> as well as -J <value>. This patch makes sure that -module-dir behaves consistently with other such flags. Differential Revision: https://reviews.llvm.org/D125957 | 4 年前 |