[flang][driver] Rename flang-new as flang
#74377
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llvmbot
added
clang
|
@llvm/pr-subscribers-flang-driver @llvm/pr-subscribers-clang Author: Andrzej Warzyński (banach-space) ChangesThis patch renames
A symlink called For backwards compatibility, a symlink Patch is 59.98 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/74377.diff 45 Files Affected:
diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 6f5ff81410326..9a161ffd7cfc5 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -1954,7 +1954,7 @@ void Driver::PrintHelp(bool ShowHidden) const {
void Driver::PrintVersion(const Compilation &C, raw_ostream &OS) const {
if (IsFlangMode()) {
- OS << getClangToolFullVersion("flang-new") << '\n';
+ OS << getClangToolFullVersion("flang") << '\n';
} else {
// FIXME: The following handlers should use a callback mechanism, we don't
// know what the client would like to do.
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index ab19166f18c2d..eb5bd8d033bb4 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -310,6 +310,9 @@ static const DriverSuffix *FindDriverSuffix(StringRef ProgName, size_t &Pos) {
{"cl", "--driver-mode=cl"},
{"++", "--driver-mode=g++"},
{"flang", "--driver-mode=flang"},
+ // For backwards compatibility, we create a symlink for `flang` called
+ // `flang-new`. This will be removed in the future.
+ {"flang-new", "--driver-mode=flang"},
{"clang-dxc", "--driver-mode=dxc"},
};
diff --git a/clang/lib/Driver/ToolChains/Flang.cpp b/clang/lib/Driver/ToolChains/Flang.cpp
index 98b337e60e4ff..5683240e8a435 100644
--- a/clang/lib/Driver/ToolChains/Flang.cpp
+++ b/clang/lib/Driver/ToolChains/Flang.cpp
@@ -739,14 +739,16 @@ void Flang::ConstructJob(Compilation &C, const JobAction &JA,
CmdArgs.push_back(Input.getFilename());
- // TODO: Replace flang-new with flang once the new driver replaces the
- // throwaway driver
- const char *Exec = Args.MakeArgString(D.GetProgramPath("flang-new", TC));
+ // Get the name of this executable. The `getClangProgramPath` hook predates
+ // Flang, hence the name assumes that it's a Clang program. In practice, it
+ // can be any program (e.g. a Flang program) implemented in terms of
+ // `clangDriver`.
+ const char *Exec = D.getClangProgramPath();
C.addCommand(std::make_unique<Command>(JA, *this,
ResponseFileSupport::AtFileUTF8(),
Exec, CmdArgs, Inputs, Output));
}
-Flang::Flang(const ToolChain &TC) : Tool("flang-new", "flang frontend", TC) {}
+Flang::Flang(const ToolChain &TC) : Tool("flang", "flang frontend", TC) {}
Flang::~Flang() {}
diff --git a/clang/test/Driver/flang/flang.f90 b/clang/test/Driver/flang/flang.f90
index ad4a3a3b6bd44..b52977ee66d7b 100644
--- a/clang/test/Driver/flang/flang.f90
+++ b/clang/test/Driver/flang/flang.f90
@@ -13,7 +13,7 @@
! * (no type specified, resulting in an object file)
! All invocations should begin with flang -fc1, consume up to here.
-! ALL-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! ALL-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
! Check that f90 files are not treated as "previously preprocessed"
! ... in --driver-mode=flang.
diff --git a/clang/test/Driver/flang/flang_ucase.F90 b/clang/test/Driver/flang/flang_ucase.F90
index e89c053b327bc..88aedc39fb94a 100644
--- a/clang/test/Driver/flang/flang_ucase.F90
+++ b/clang/test/Driver/flang/flang_ucase.F90
@@ -13,7 +13,7 @@
! * (no type specified, resulting in an object file)
! All invocations should begin with flang -fc1, consume up to here.
-! ALL-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! ALL-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
! Check that f90 files are not treated as "previously preprocessed"
! ... in --driver-mode=flang.
diff --git a/clang/test/Driver/flang/multiple-inputs-mixed.f90 b/clang/test/Driver/flang/multiple-inputs-mixed.f90
index 2395dbecf1fe9..98d8cab00bdfd 100644
--- a/clang/test/Driver/flang/multiple-inputs-mixed.f90
+++ b/clang/test/Driver/flang/multiple-inputs-mixed.f90
@@ -1,7 +1,7 @@
! Check that flang can handle mixed C and fortran inputs.
! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/other.c 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}clang{{[^"/]*}}" "-cc1"
! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/other.c"
diff --git a/clang/test/Driver/flang/multiple-inputs.f90 b/clang/test/Driver/flang/multiple-inputs.f90
index ada999e927a6a..3c0f22e5d3e50 100644
--- a/clang/test/Driver/flang/multiple-inputs.f90
+++ b/clang/test/Driver/flang/multiple-inputs.f90
@@ -1,7 +1,7 @@
! Check that flang driver can handle multiple inputs at once.
! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/two.f90 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"
diff --git a/flang/docs/FlangDriver.md b/flang/docs/FlangDriver.md
index 5231e78335f6a..6a3b9536a02e4 100644
--- a/flang/docs/FlangDriver.md
+++ b/flang/docs/FlangDriver.md
@@ -15,17 +15,13 @@ local:
```
There are two main drivers in Flang:
-* the compiler driver, `flang-new`
-* the frontend driver, `flang-new -fc1`
-
-> **_NOTE:_** The diagrams in this document refer to `flang` as opposed to
-> `flang-new`. Eventually, `flang-new` will be renamed as `flang` and the
-> diagrams reflect the final design that we are still working towards.
+* the compiler driver, `flang`
+* the frontend driver, `flang -fc1`
The **compiler driver** will allow you to control all compilation phases (e.g.
preprocessing, semantic checks, code-generation, code-optimisation, lowering
and linking). For frontend specific tasks, the compiler driver creates a
-Fortran compilation job and delegates it to `flang-new -fc1`, the frontend
+Fortran compilation job and delegates it to `flang -fc1`, the frontend
driver. For linking, it creates a linker job and calls an external linker (e.g.
LLVM's [`lld`](https://lld.llvm.org/)). It can also call other tools such as
external assemblers (e.g. [`as`](https://www.gnu.org/software/binutils/)). In
@@ -47,7 +43,7 @@ frontend. It uses MLIR and LLVM for code-generation and can be viewed as a
driver for Flang, LLVM and MLIR libraries. Contrary to the compiler driver, it
is not capable of calling any external tools (including linkers). It is aware
of all the frontend internals that are "hidden" from the compiler driver. It
-accepts many frontend-specific options not available in `flang-new` and as such
+accepts many frontend-specific options not available in `flang` and as such
it provides a finer control over the frontend. Note that this tool is mostly
intended for Flang developers. In particular, there are no guarantees about the
stability of its interface and compiler developers can use it to experiment
@@ -62,30 +58,30 @@ frontend specific flag from the _compiler_ directly to the _frontend_ driver,
e.g.:
```bash
-flang-new -Xflang -fdebug-dump-parse-tree input.f95
+flang -Xflang -fdebug-dump-parse-tree input.f95
```
-In the invocation above, `-fdebug-dump-parse-tree` is forwarded to `flang-new
+In the invocation above, `-fdebug-dump-parse-tree` is forwarded to `flang
-fc1`. Without the forwarding flag, `-Xflang`, you would see the following
warning:
```bash
-flang-new: warning: argument unused during compilation:
+flang: warning: argument unused during compilation:
```
-As `-fdebug-dump-parse-tree` is only supported by `flang-new -fc1`, `flang-new`
+As `-fdebug-dump-parse-tree` is only supported by `flang -fc1`, `flang`
will ignore it when used without `Xflang`.
## Why Do We Need Two Drivers?
-As hinted above, `flang-new` and `flang-new -fc1` are two separate tools. The
-fact that these tools are accessed through one binary, `flang-new`, is just an
+As hinted above, `flang` and `flang -fc1` are two separate tools. The
+fact that these tools are accessed through one binary, `flang`, is just an
implementation detail. Each tool has a separate list of options, albeit defined
in the same file: `clang/include/clang/Driver/Options.td`.
The separation helps us split various tasks and allows us to implement more
-specialised tools. In particular, `flang-new` is not aware of various
+specialised tools. In particular, `flang` is not aware of various
compilation phases within the frontend (e.g. scanning, parsing or semantic
-checks). It does not have to be. Conversely, the frontend driver, `flang-new
+checks). It does not have to be. Conversely, the frontend driver, `flang
-fc1`, needs not to be concerned with linkers or other external tools like
assemblers. Nor does it need to know where to look for various systems
libraries, which is usually OS and platform specific.
@@ -104,7 +100,7 @@ GCC](https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Archi
In fact, Flang needs to adhere to this model in order to be able to re-use
Clang's driver library. If you are more familiar with the [architecture of
GFortran](https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gfortran/About-GNU-Fortran.html)
-than Clang, then `flang-new` corresponds to `gfortran` and `flang-new -fc1` to
+than Clang, then `flang` corresponds to `gfortran` and `flang -fc1` to
`f951`.
## Compiler Driver
@@ -135,7 +131,7 @@ output from one action is the input for the subsequent one. You can use the
`-ccc-print-phases` flag to see the sequence of actions that the driver will
create for your compiler invocation:
```bash
-flang-new -ccc-print-phases -E file.f
+flang -ccc-print-phases -E file.f
+- 0: input, "file.f", f95-cpp-input
1: preprocessor, {0}, f95
```
@@ -143,13 +139,14 @@ As you can see, for `-E` the driver creates only two jobs and stops immediately
after preprocessing. The first job simply prepares the input. For `-c`, the
pipeline of the created jobs is more complex:
```bash
-flang-new -ccc-print-phases -c file.f
+flang -ccc-print-phases -c file.f
+- 0: input, "file.f", f95-cpp-input
+- 1: preprocessor, {0}, f95
+- 2: compiler, {1}, ir
+- 3: backend, {2}, assembler
4: assembler, {3}, object
```
+
The other phases are printed nonetheless when using `-ccc-print-phases`, as
that reflects what `clangDriver`, the library, will try to create and run.
@@ -158,7 +155,7 @@ command to call the frontend driver is generated (more specifically, an
instance of `clang::driver::Command`). Every command is bound to an instance of
`clang::driver::Tool`. For Flang we introduced a specialisation of this class:
`clang::driver::Flang`. This class implements the logic to either translate or
-forward compiler options to the frontend driver, `flang-new -fc1`.
+forward compiler options to the frontend driver, `flang -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
@@ -193,26 +190,29 @@ driver, `clang -cc1` and consists of the following classes:
This list is not exhaustive and only covers the main classes that implement the
driver. The main entry point for the frontend driver, `fc1_main`, is
implemented in `flang/tools/flang-driver/driver.cpp`. It can be accessed by
-invoking the compiler driver, `flang-new`, with the `-fc1` flag.
+invoking the compiler driver, `flang`, with the `-fc1` flag.
The frontend driver will only run one action at a time. If you specify multiple
action flags, only the last one will be taken into account. The default action
is `ParseSyntaxOnlyAction`, which corresponds to `-fsyntax-only`. In other
-words, `flang-new -fc1 <input-file>` is equivalent to `flang-new -fc1 -fsyntax-only
+words, `flang -fc1 <input-file>` is equivalent to `flang -fc1 -fsyntax-only
<input-file>`.
## The `flang-to-external-fc` script
-The `flang-to-external-fc` wrapper script for `flang-new` was introduced as a
-development tool and to facilitate testing. The `flang-to-external-fc` wrapper
-script will:
-* use `flang-new` to unparse the input source file (i.e. it will run `flang-new
- -fc1 -fdebug-unparse <input-file>`), and then
+The `flang-to-external-fc` wrapper script for `flang` was introduced as a
+development tool and to facilitate testing. While code-generation is not
+available in Flang, you can use it as a drop-in replacement for other Fortran
+compilers in your build scripts.
+
+The `flang-to-external-fc` wrapper script will:
+* use `flang` to unparse the input source file (i.e. it will run `flang -fc1
+ -fdebug-unparse <input-file>`), and then
* call a host Fortran compiler, e.g. `gfortran`, to compile the unparsed file.
Here's a basic breakdown of what happens inside `flang-to-external-fc` when you
run `flang-to-external-fc file.f90`:
```bash
-flang-new -fc1 -fdebug-unparse file.f90 -o file-unparsed.f90
+flang -fc1 -fdebug-unparse file.f90 -o file-unparsed.f90
gfortran file-unparsed.f90
```
This is a simplified version for illustration purposes only. In practice,
@@ -334,14 +334,14 @@ where `<version>` corresponds to the LLVM Flang version.
# Testing
In LIT, we define two variables that you can use to invoke Flang's drivers:
-* `%flang` is expanded as `flang-new` (i.e. the compiler driver)
-* `%flang_fc1` is expanded as `flang-new -fc1` (i.e. the frontend driver)
+* `%flang` is expanded as `flang` (i.e. the compiler driver)
+* `%flang_fc1` is expanded as `flang -fc1` (i.e. the frontend driver)
For most regression tests for the frontend, you will want to use `%flang_fc1`.
In some cases, the observable behaviour will be identical regardless of whether
`%flang` or `%flang_fc1` is used. However, when you are using `%flang` instead
of `%flang_fc1`, the compiler driver will add extra flags to the frontend
-driver invocation (i.e. `flang-new -fc1 -<extra-flags>`). In some cases that might
+driver invocation (i.e. `flang -fc1 -<extra-flags>`). In some cases that might
be exactly what you want to test. In fact, you can check these additional
flags by using the `-###` compiler driver command line option.
@@ -361,7 +361,7 @@ plugins. The process for using plugins includes:
* [Creating a plugin](#creating-a-plugin)
* [Loading and running a plugin](#loading-and-running-a-plugin)
-Flang plugins are limited to `flang-new -fc1` and are currently only available /
+Flang plugins are limited to `flang -fc1` and are currently only available /
been tested on Linux.
## Creating a Plugin
@@ -446,14 +446,14 @@ static FrontendPluginRegistry::Add<PrintFunctionNamesAction> X(
## Loading and Running a Plugin
In order to use plugins, there are 2 command line options made available to the
-frontend driver, `flang-new -fc1`:
+frontend driver, `flang -fc1`:
* [`-load <dsopath>`](#the--load-dsopath-option) for loading the dynamic shared
object of the plugin
* [`-plugin <name>`](#the--plugin-name-option) for calling the registered plugin
Invocation of the example plugin is done through:
```bash
-flang-new -fc1 -load flangPrintFunctionNames.so -plugin print-fns file.f90
+flang -fc1 -load flangPrintFunctionNames.so -plugin print-fns file.f90
```
Both these options are parsed in `flang/lib/Frontend/CompilerInvocation.cpp` and
@@ -474,7 +474,7 @@ reports an error diagnostic and returns `nullptr`.
## Enabling In-Tree Plugins
For in-tree plugins, there is the CMake flag `FLANG_PLUGIN_SUPPORT`, enabled by
-default, that controls the exporting of executable symbols from `flang-new`,
+default, that controls the exporting of executable symbols from `flang`,
which plugins need access to. Additionally, there is the CMake flag
`LLVM_BUILD_EXAMPLES`, turned off by default, that is used to control if the
example programs are built. This includes plugins that are in the
diff --git a/flang/docs/ImplementingASemanticCheck.md b/flang/docs/ImplementingASemanticCheck.md
index 5b583d4f8031b..598ef696ad14b 100644
--- a/flang/docs/ImplementingASemanticCheck.md
+++ b/flang/docs/ImplementingASemanticCheck.md
@@ -68,7 +68,7 @@ of the call to `intentOutFunc()`:
I also used this program to produce a parse tree for the program using the command:
```bash
- flang-new -fc1 -fdebug-dump-parse-tree testfun.f90
+ flang -fc1 -fdebug-dump-parse-tree testfun.f90
```
Here's the relevant fragment of the parse tree produced by the compiler:
@@ -296,7 +296,7 @@ In `lib/Semantics/check-do.cpp`, I added an (almost empty) implementation:
I then built the compiler with these changes and ran it on my test program.
This time, I made sure to invoke semantic checking. Here's the command I used:
```bash
- flang-new -fc1 -fdebug-unparse-with-symbols testfun.f90
+ flang -fc1 -fdebug-unparse-with-symbols testfun.f90
```
This produced the output:
diff --git a/flang/docs/Overview.md b/flang/docs/Overview.md
index 561e9cfcf95c3..af0e4cc661094 100644
--- a/flang/docs/Overview.md
+++ b/flang/docs/Overview.md
@@ -65,8 +65,8 @@ See [Preprocessing.md](Preprocessing.md).
**Entry point:** `parser::Parsing::Prescan`
**Commands:**
- - `flang-new -fc1 -E src.f90` dumps the cooked character stream
- - `flang-new -fc1 -fdebug-dump-provenance src.f90` dumps provenance
+ - `flang -fc1 -E src.f90` dumps the cooked character stream
+ - `flang -fc1 -fdebug-dump-provenance src.f90` dumps provenance
information
## Parsing
@@ -80,10 +80,10 @@ representing a syntactically correct program, rooted at the program unit. See:
**Entry point:** `parser::Parsing::Parse`
**Commands:**
- - `flang-new -fc1 -fdebug-dump-parse-tree-no-sema src.f90` dumps the parse tree
- - `flang-new -fc1 -fdebug-unparse src.f90` converts the parse tree to normalized Fortran
- - `flang-new -fc1 -fdebug-dump-parsing-log src.f90` runs an instrumented parse and dumps the log
- - `flang-new -fc1 -fdebug-measure-parse-tree src.f90` measures the parse tree
+ - `flang -fc1 -fdebug-dump-parse-tree-no-sema src.f90` dumps the parse tree
+ - `flang -fc1 -fdebug-unparse src.f90` converts the parse tree to normalized Fortran
+ - `flang -fc1 -fdebug-dump-parsing-log src.f90` runs an instrumented parse and dumps the log
+ - `flang -fc1 -fdebug-measure-parse-tree src.f90` measures the parse tree
## Semantic processing
diff --git a/flang/examples/FlangOmpReport/FlangOmpReport.cpp b/flang/examples/FlangOmpReport/FlangOmpReport.cpp
index 9c1f304b9741e..709c5c5d305e5 100644
--- a/flang/examples/FlangOmpReport/FlangOmpReport.cpp
+++ b/flang/examples/FlangOmpReport/FlangOmpReport.cpp
@@ -9,7 +9,7 @@
// all the OpenMP constructs and clauses and which line they're located on.
//
// The plugin may be invoked as:
-// ./bin/flang-new -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report
+// ./bin/flang -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report
// -fopenmp
//
//===----------------------------------------------------------------------===//
diff --git a/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp b/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
index bc09dec17b7ae..b461676bc5075 100644
--- a/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ b/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -152,8 +152,7 @@ bool executeCompilerInvocation(CompilerInstance *flang) {
// Honor -help.
if (flang->getFrontendOpts().showHelp) {
clang::driver::getDriverOptTable().printHelp(
- llvm::outs(), "flang-new -fc1 [options] file...",
- "LLVM 'Flang' Compiler",
+ llvm::outs(), "flang -fc1 [options] file...", "LLVM 'Flang' Compiler",
/*ShowHidden=*/false, /*ShowAllAliases=*/false,
llvm::opt::Visibility(clang::driver::options::FC1Option));
return true;
diff --git a/flang/test/CMakeLists.txt b/flang/test/CMakeLists.txt
index 7d96a72e5f36d..d4241ea90810b 100644
--- a/flang/test/CMakeLists.txt
+++ b/flang/test/CMakeLists.txt
@@ -48,7 +48,7 @@ set(FLANG_TEST_PARAMS
flang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py)
set(FLANG_TEST_DEPENDS
- flang-new
+ flang
llvm-config
FileCheck
count
diff --git a/flang/test/Driver/compiler_options.f90 b/flang/test/Driver/compiler_options.f90
index 3edebb915c095..cf874249b90b1 100644
--- a/flang/test/Driver/compiler_options.f90
+++ b/flang/test/Driver/compiler_options....
[truncated]
|
|
Are you going to add an entry to the Release Notes? |
Once this change lands, yes. |
|
Clang PRs often update the release notes and features. ala: The LLVM 19 release will not contain flang-new. |
|
I am assuming you have got a go-ahead from the code owner and others involved in the discourse discussion. It is probably good to post a link to this patch in the relevant discourse post for information and confirmation. |
|
The CI errors are Flang specific on Windows... Do we care about those? |
We do care about those, I just need to ping somebody with a Windows machine to help me fix that. |
banach-space
force-pushed
the
andrzej/rename_flang_new
branch
2 times, most recently
from
3e36752
to
2473bc3
Compare
|
I have a Windows test machine. How can I help? |
Thank you for the offer, but it looks like CI is now passing 🥳 @DavidTruby kindly helped me offline 🙏🏻 |
h-vetinari
reviewed
Dec 11, 2023
MaskRay
reviewed
Dec 11, 2023
MaskRay
reviewed
Dec 11, 2023
|
It appears this PR now has conflicts that need resolving... |
This patch renames `flang-new` as `flang`. Similarly to Clang, Flang's driver executable will be called: * `flang-<MAJOR_VERSION>` A symlink called `flang` pointing at `flang-<MAJOR_VERSION>` will be created at build time. This is consistent with Clang. For backwards compatibility, a symlink `flang-new` pointing to `flang-<MAJOR_VERSION>` is also created. This will be removed in the future.
Update tests to fix Windows failures
Make correct frontend driver exec is used
Update tests and docs
banach-space
force-pushed
the
andrzej/rename_flang_new
branch
from
5faacb0
to
4ad4739
Compare
Thanks, I've just rebased this branch, so that should be resolved. |
|
It's all green lights. Anything holding this up? |
|
Still gathering feedback https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/54 |
|
Not that it's the end of the world if this doesn't get in before the this release, but @sscalpone , exactly what feedback are we wanting before merging? |
IIUC, this: https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/55 |
ok, but is there some threshold of percent that pass, or a specific list that we want to be sure pass? My understanding is that we've been running (at least a subset of) the gfortran test suite for a while now. What makes the current results not sufficient? |
I think it's more of take flang-new and run it through the test suite and provide the output results. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch renames
flang-newasflang. Similarly to Clang, Flang'sdriver executable will be called:
flang-<MAJOR_VERSION>A symlink called
flangpointing atflang-<MAJOR_VERSION>will becreated at build time. This is consistent with Clang.
For backwards compatibility, a symlink
flang-newpointing toflang-<MAJOR_VERSION>is also created. This will be removed in thefuture.