Flang implementation for COMPILER_VERSION and COMPILER_OPTIONS intrinsics

[hussainjk]

Summary

This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.

Fixes #59233

[PeteSteinfeld]

There's something wonky about this patch. I was unable to apply it against the latest sources. Can you please rebase?

[ktras]

Is there a test you could add to this patch to show that the changes work as expected?

[klausler]

flang/include/flang/Common/Version.h

22

Don't indent the contents of a namespace.

Use capitalized names.

flang/lib/Lower/IntrinsicCall.cpp

747

This intrinsic function must be folded during semantics, not implemented in code generation.

[rouson]

flang/lib/Lower/IntrinsicCall.cpp

747

@klausler could you explain how one knows whether an intrinsic function must be folded during semantics or implemented in code generation?

[klausler]

flang/lib/Lower/IntrinsicCall.cpp

747

F'2018 subclause "10.1.12 Constant expression" reads:

A constant expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is ...

... (6) a reference to a standard intrinsic function that is transformational, other than COMMAND_ARGUMENT_COUNT, GET_TEAM, NULL, NUM_IMAGES, TEAM_NUMBER, THIS_IMAGE, or TRANSFER, where each argument is a constant expression,

16.10.2.7 COMPILER_VERSION ( )
1 Description. Processor-dependent string identifying the program translation phase.
2 Class. Transformational function.
3 Argument. None.

A reference to COMPILER_VERSION() is a primary that is a reference to a standard intrinsic transformational function other than COMMAND_ARGUMENT_COUNT, GET_TEAM, NULL, NUM_IMAGES, TEAM_NUMBER, THIS_IMAGE, or TRANSFER, and it has no argument that is not a constant expression, so it satisfies the requirements of point (6) in the definition of a constant expression, and so it is a constant expression.

[hussainjk]

Re-implemented compiler_version, and implemented compiler_options, using intrinsic folding pass.

[awarzynski]

Please add a test.

flang/include/flang/Frontend/CompilerInvocation.h

86 ↗

(On Diff #509597)

This doesn't feel right. One of the task of the frontend driver is to parse command line arguments and split them into various fields in this class. There should be no dedicated field for ALL arguments (on top of other fields).

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

Wouldn't this forward all command line arguments to set_compilerOptionsString?

[ktras]

flang/lib/Evaluate/intrinsics.cpp

2135 ↗

(On Diff #509597)

Please delete this line of commented out code.

[hussainjk]

Rebasing and formatting.

[hussainjk]

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

Pretty much. It wasn't clear to me to what extent should compiler_options be reporting command-line flags. Should it be more narrow?

[awarzynski]

The summary states "Implementation for COMPILER_VERSION intrinsic procedure", but it looks like this patch implements COMPILER_VERSION and COMPILER_OPTIONS. Please, could you update it accordingly? Also, please add the missing tests.

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

I think that we are referring to two different things:

• IIUC, you are referring to COMPILER_OPTIONS Fortran intrinsic,
• I am referring to the design of the Flang driver and various implementation details, e.g. the fact that that the CompilerInvocation encapsulates a compiler invocation and that it groups compilation options into various sets, e.g. [[ flang/lib/Frontend/CompilerInvocation.cpp | parserOpts ]].

Please add a comment to explain that all compiler options are forwarded to the semantics context in order to implement COMPILER_OPTIONS. Also, rather than duplicating compiler options in commandLineArgs, please use the existing fields in CompilerInvocaiton.

[hussainjk]

Adding test for compiler_version.

[hussainjk]

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

So I did some tinkering around regarding this. The problem with the compiler option groupings is that they are encapsulated into a few different nonstandard classes, for which there is no method to iterate through, and which don't all have methods to retrieve a command-line string representation. So setting the compiler options string would then involve a lot of lines manually going through struct fields and appending option strings and corresponding values, which is a lot more fragile than just storing the original string. It seems like the current way should be preferred for maintainability.

[kiranchandramohan]

Thanks for this patch. This patch fixes the following issue. If you can add `Fixes #59233 then the issue will automatically be closed when you submit.
https://github.com/llvm/llvm-project/issues/59233
You can consider using the test in the issue.

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

It is not clear to me what options should be made visible to the user. Is it the options provided in the command line or the internal options that are used?

The current handling in the frontend driver captures the internal options and not the original options entered by the user. If we want the command line options then the compiler driver has this information and should pass it to the frontend driver as a string.

For eg: Currently, the following output is produced, which is not what the user provided.

$ ./bin/flang-new -flang-experimental-exec -O3 co.f90                                                                           
$ ./a.out 
 -triple aarch64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +neon -target-feature +v8a -O3 -o /tmp/co-cd57e2.o -x f95-cpp-input co.f90

I see that other compilers also provide some internal options but fewer.

$ gfortran -O3 co.f90 
$ ./a.out 
 -mlittle-endian -mabi=lp64 -O3 -fpre-include=/usr/include/finclude/math-vector-fortran.h

$ nvfortran -O3 co.f90 
$ ./a.out 
 co.f90 -O3 -Mvect=simd -Mflushz -Mcache_align -Mrecip-div -Mfactorize

flang/test/Evaluate/compiler_version.f90

1 ↗

(On Diff #516430)

We generally do not have emit-llvm tests here.

You can test this with either -fdebug-unparse or -fdebug-dump-parse-tree tests.

Please add a test for both compiler_version and compiler_options.

[tschuett]

flang/include/flang/Common/Version.h

23

Subversion should be Git.

30

Upstream LLVM is a monorepo. I don't believe that having flang and llvm in different repositories is supported.

[klausler]

flang/include/flang/Common/Version.h

30

Out-of-tree builds work just fine.

[hussainjk]

Rewriting compiler_version test per review comments.

[hussainjk]

Minor typo fix.

[hussainjk]

Re-implemented compiler_options to be based on the options passed in by the user. Added a test for compiler_options.

[hussainjk]

fixing build bugs.

[hussainjk]

flang/lib/Frontend/CompilerInvocation.cpp

959 ↗

(On Diff #509597)

I rewrote this so that the compiler options string is instead set to the original command line invocation made by the user.
This information needs to be passed from the parent frontend process to the internal cc1 process which is subsequently launched. Currently it is doing this by setting an environment variable, but it could also be done with a command-line option passed to the cc1 stage, if that would be preferred.

Right now it is not including any internal expanded options, but that should be easy to do if we identify some that should be.

[kiranchandramohan]

flang/lib/Frontend/CompilerInvocation.cpp

882 ↗

(On Diff #523818)

Not sure whether this style of using environment variables in the Driver to pass options between the Flang driver and the Flang frontend driver is OK. I was hoping you will pass it as an option with a string value to the Flang frontend driver.
-fc1 -co "<OPTIONS>"``

Please wait for @awarzynski for an opinion.

959 ↗

(On Diff #509597)

Thanks @hussainjk. See comment inline regarding using environment variables for passing info.

[awarzynski]

@hussainjk , thanks for the updates!

The idea of using an environment variable to pass something from flang-new to flang-new -fc1 bypasses the "separation of concerns" in the driver design:

• flang-new drives the frontend driver (flang-new -fc1), assembler and linker (i.e. creates invocations of these tools).
• Once invoked, the frontend driver (flang-new -fc1) has no access to the compiler driver invocation - it doesn't need to. Indeed, why would the frontend be concerned with e.g. linker flags?

Passing it as a string, as @kiranchandramohan suggested, would help avoid requiring env variables. However, it would pollute the frontend driver invocation (flang-new -fc1 <args>) that people may want to use for debugging. I wish that we could avoid both, but I have no better suggestions. IMHO, this is inherently a Fortran issue. I am not a language expert, but do feel that COMPILER_OPTIONS is trying to expose information that belongs in the toolchain rather than language implementation.

Personally I am leaning towards accepting the approach with env variables. @kiranchandramohan, would that work? @hussainjk , could you add comments discouraging people from using similar mechanism for other things? Hopefully this is the only exception that we need to make.

Also, @hussainjk, your effort is much appreciated, thank you for experimenting with different approaches!

flang/lib/Frontend/CompilerInvocation.cpp

882 ↗

(On Diff #523818)

883–884 ↗

(On Diff #523818)

Please document that in one case the compiler will use "compiler driver" options (flang-new) and in the other "frontend driver" options (flang-new -fc1).

flang/test/Evaluate/compiler_options.f90

1 ↗

(On Diff #523818)

Similar test without -fc1 would be helpful too. Also, could you verify that with flang-new the user will only see the user specified options (so no flang-new -fc1 options)?

flang/tools/flang-driver/fc1_main.cpp

53 ↗

(On Diff #523818)

This change is no longer required, right?

[hussainjk]

Addressing some review comments.

[hussainjk]

flang/tools/flang-driver/fc1_main.cpp

53 ↗

(On Diff #523818)

In the case when the frontend driver is invoked directly (and hence no env var), createFromArgs will set the COMPILER_OPTIONS string based on the actual command line, but it needs to be passed argv0 because it otherwise only gets the rest of argv.

[hussainjk]

flang/test/Evaluate/compiler_options.f90

1 ↗

(On Diff #523818)

It seems that -fc1 is necessary for -fdebug-unparse. So I could do this but using -emit-llvm. Thoughts, @kiranchandramohan?

[hussainjk]

@awarzynski thanks! I was also concerned about polluting the frontend invocation, as well as the scope creep of adding new command line option definitions.

[awarzynski]

Thanks again for the updates. This is heading in the right direction, but I'd like to see the documentation for introducing FLANG_COMPILER_OPTIONS_STRING and compilerOptionsString a bit more refined. See my suggestions inline.

flang/include/flang/Frontend/CompilerInvocation.h

85 ↗

(On Diff #524153)

Naming is hard and I don't claim my suggestion is perfect. My main point is that there's no need to include variable type in variable's name ;-)

Please also add a comment that explains what this string is for.

flang/lib/Frontend/CompilerInvocation.cpp

880 ↗

(On Diff #524153)

881–883 ↗

(On Diff #524153)

I think that this comment is missing some detail. Please see my suggestion and feel free to re-use and/or edit.

flang/test/Evaluate/compiler_options.f90

1 ↗

(On Diff #523818)

You can add a test with -emit-llvm in flang/test/Driver. Just document that that would be specifically to test communicating COMPILER_OPTIONS from flang-new to flang-new -fc1.

7 ↗

(On Diff #524153)

?

flang/tools/flang-driver/driver.cpp

140–141 ↗

(On Diff #524153)

Please be more specific.

1. I am aware of COMPILER_OPTIONS Fortran intrinsic and compilerOptionsString string in Flang's CompilerInvocation.h (that I suggested to be renamed). Which one is it?
2. Why is this env variable being passed to the frontend driver like this? Please document that this is specifically for the COMPILER_OPTIONS intrinsic and that there is no other mechanism to communicate the original invocation between the compiler and the frontend drivers.

We are making an exception here to avoid excessive polution of the frontend invocation.

Not quite. An exception is being made, because we haven't been able to identify a better alternative to implement COMPILER_OPTIONS intrinsics. We could, instead, add an additional option to the frontend driver invocation, but that wouldn't be 100% problem-free.

How about:

Set the environment variable, FLANG_COMPILER_OPTIONS_STRING, to contain all the compiler options. This is intended for the frontend driver, flang-new -fc1, to enable the implementation of the COMPILER_OPTIONS intrinsic. To this end, the frontend driver requires the list of the original compiler options, which is not available through other means.
TODO: This way of passing information between the compiler and frontend drivers is discouraged. We should find a better way not involving env variables.

146 ↗

(On Diff #524153)

IMHO, compilerOptsAsOneString would be more descriptive. In either way, please adhere to the coding style and use camelCase.

flang/tools/flang-driver/fc1_main.cpp

53 ↗

(On Diff #523818)

Please, could you maintain consistency with Clang and add a default value for argv0: https://github.com/llvm/llvm-project/blob/7ca1bcbc6043b7ab4635f04746d1b9480960e384/clang/include/clang/Frontend/CompilerInvocation.h#L207-L210.

[awarzynski]

flang/lib/Frontend/CompilerInvocation.cpp

820 ↗

(On Diff #524153)

[tschuett]

Clang and other tools use response files when the command line gets too long, e.g.
https://reviews.llvm.org/D4897#change-Me6ZMDruqhhS

Note the @

[tschuett]

flang-* seems to support response files:
https://github.com/llvm/llvm-project/blob/8a4e3675d88ecd0413d89dea1e3578a4696b05da/flang/tools/flang-driver/driver.cpp#L96

[hussainjk]

Addressing review comments.

[hussainjk]

Addressing review comments.

[awarzynski]

The driver logic LGTM, thank you for addressing my comments (I've added one more formatting suggestion)! Please wait a day or two before landing this - I've only really looked at the bits I'm familiar with (i.e. the driver).

Also, could you update the summary/commit message. I would appreciate if you could "introduce" the rationale for adding the env variable. Thank you!

flang/include/flang/Frontend/CompilerInvocation.h

85–87 ↗

(On Diff #526625)

[klausler]

The out-of-tree build is now broken and there are a number of style problems with a new source file; see #general on Slack. Please address the out-of-tree build failure in a timely manner.

[sscalpone]

flang/test/Driver/compiler_options.f90

12 ↗

(On Diff #527460)

Why close?

[klausler]

The out-of-tree build bot is still failing.

[klausler]

Scratch that; the out-of-tree build bot has now built successfully with your latest commit. Thank you for that.

Please clean up the other issues that I enumerated on Slack.

flang/include/flang/Common/Version.h

+//===- Version.h - Flang Version Number ---------------------*- Fortran -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+///
+/// \file
+/// Defines version macros and version-related utility functions
+/// for Flang.
+///
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_FLANG_COMMON_VERSION_H
+#define LLVM_FLANG_COMMON_VERSION_H
+
+#include "flang/Version.inc"
+#include "llvm/ADT/StringRef.h"
+
+namespace Fortran::common {
+  /// Retrieves the repository path (e.g., Subversion path) that
+  /// identifies the particular Flang branch, tag, or trunk from which this
+  /// Flang was built.
+  std::string getFlangRepositoryPath();
+
+  /// Retrieves the repository path from which LLVM was built.
+  ///
+  /// This supports LLVM residing in a separate repository from flang.
+  std::string getLLVMRepositoryPath();
+
+  /// Retrieves the repository revision number (or identifier) from which
+  /// this Flang was built.
+  std::string getFlangRevision();
+
+  /// Retrieves the repository revision number (or identifier) from which
+  /// LLVM was built.
+  ///
+  /// If Flang and LLVM are in the same repository, this returns the same
+  /// string as getFlangRevision.
+  std::string getLLVMRevision();
+
+  /// Retrieves the full repository version that is an amalgamation of
+  /// the information in getFlangRepositoryPath() and getFlangRevision().
+  std::string getFlangFullRepositoryVersion();
+
+  /// Retrieves a string representing the complete flang version,
+  /// which includes the flang version number, the repository version,
+  /// and the vendor tag.
+  std::string getFlangFullVersion();
+
+  /// Like getFlangFullVersion(), but with a custom tool name.
+  std::string getFlangToolFullVersion(llvm::StringRef ToolName);
+}
+
+#endif // LLVM_FLANG_COMMON_VERSION_H
+

flang/lib/Common/CMakeLists.txt

+find_first_existing_vc_file("${LLVM_MAIN_SRC_DIR}" llvm_vc)
+find_first_existing_vc_file("${FLANG_SOURCE_DIR}" flang_vc)
+
+# The VC revision include that we want to generate.
+set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
+
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
+
+if(llvm_vc AND LLVM_APPEND_VC_REV)
+  set(llvm_source_dir ${LLVM_MAIN_SRC_DIR})
+endif()
+if(flang_vc AND LLVM_APPEND_VC_REV)
+  set(flang_source_dir ${FLANG_SOURCE_DIR})
+endif()
+
+# Create custom target to generate the VC revision include.
+add_custom_command(OUTPUT "${version_inc}"
+  DEPENDS "${llvm_vc}" "${flang_vc}" "${generate_vcs_version_script}"
+  COMMAND ${CMAKE_COMMAND} "-DNAMES=\"LLVM;FLANG\""
+                           "-DLLVM_SOURCE_DIR=${llvm_source_dir}"
+                           "-DFLANG_SOURCE_DIR=${flang_source_dir}"
+                           "-DHEADER_FILE=${version_inc}"
+                           -P "${generate_vcs_version_script}")
+
+# Mark the generated header as being generated.
+set_source_files_properties("${version_inc}"
+  PROPERTIES GENERATED TRUE
+             HEADER_FILE_ONLY TRUE)
+
+if(FLANG_VENDOR)
+  set_source_files_properties(Version.cpp
+    PROPERTIES COMPILE_DEFINITIONS "FLANG_VENDOR=\"${FLANG_VENDOR} \"")
+endif()
+
 
 add_flang_library(FortranCommon
   Fortran.cpp
   Fortran-features.cpp
   default-kinds.cpp
   idioms.cpp
+  Version.cpp
+  ${version_inc}
 
   LINK_COMPONENTS
   Support
 )

flang/lib/Common/Version.cpp

+//===- Version.cpp - Flang Version Number -------------------*- Fortran -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines several version-related utility functions for Flang.
+//
+//===----------------------------------------------------------------------===//
+
+#include "flang/Common/Version.h"
+#include "llvm/Support/raw_ostream.h"
+#include <cstdlib>
+#include <cstring>
+
+#include "VCSVersion.inc"
+
+namespace Fortran::common {
+
+std::string getFlangRepositoryPath() {
+#if defined(FLANG_REPOSITORY_STRING)
+  return FLANG_REPOSITORY_STRING;
+#else
+#ifdef FLANG_REPOSITORY
+  return FLANG_REPOSITORY;
+#else
+  return "";
+#endif
+#endif
+}
+
+std::string getLLVMRepositoryPath() {
+#ifdef LLVM_REPOSITORY
+  return LLVM_REPOSITORY;
+#else
+  return "";
+#endif
+}
+
+std::string getFlangRevision() {
+#ifdef FLANG_REVISION
+  return FLANG_REVISION;
+#else
+  return "";
+#endif
+}
+
+std::string getLLVMRevision() {
+#ifdef LLVM_REVISION
+  return LLVM_REVISION;
+#else
+  return "";
+#endif
+}
+
+std::string getFlangFullRepositoryVersion() {
+  std::string buf;
+  llvm::raw_string_ostream OS(buf);
+  std::string Path = getFlangRepositoryPath();
+  std::string Revision = getFlangRevision();
+  if (!Path.empty() || !Revision.empty()) {
+    OS << '(';
+    if (!Path.empty())
+      OS << Path;
+    if (!Revision.empty()) {
+      if (!Path.empty())
+        OS << ' ';
+      OS << Revision;
+    }
+    OS << ')';
+  }
+  // Support LLVM in a separate repository.
+  std::string LLVMRev = getLLVMRevision();
+  if (!LLVMRev.empty() && LLVMRev != Revision) {
+    OS << " (";
+    std::string LLVMRepo = getLLVMRepositoryPath();
+    if (!LLVMRepo.empty())
+      OS << LLVMRepo << ' ';
+    OS << LLVMRev << ')';
+  }
+  return buf;
+}
+
+std::string getFlangFullVersion() {
+  return getFlangToolFullVersion("flang");
+}
+
+std::string getFlangToolFullVersion(llvm::StringRef ToolName) {
+  std::string buf;
+  llvm::raw_string_ostream OS(buf);
+#ifdef FLANG_VENDOR
+  OS << FLANG_VENDOR;
+#endif
+  OS << ToolName << " version " FLANG_VERSION_STRING;
+
+  std::string repo = getFlangFullRepositoryVersion();
+  if (!repo.empty()) {
+    OS << " " << repo;
+  }
+
+  return buf;
+}
+
+
+} // end namespace Fortran::common

flang/lib/Lower/IntrinsicCall.cpp

 //===-- IntrinsicCall.cpp -------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // Helper routines for constructing the FIR dialect of MLIR. As FIR is a
 // dialect of MLIR, it makes extensive use of MLIR interfaces and MLIR's coding
 // style (https://mlir.llvm.org/getting_started/DeveloperGuide/) is used in this
 // module.
 //
 //===----------------------------------------------------------------------===//
 
 #include "flang/Lower/IntrinsicCall.h"
 #include "flang/Common/static-multimap-view.h"
+#include "flang/Common/Version.h"
 #include "flang/Lower/Mangler.h"
 #include "flang/Lower/Runtime.h"
 #include "flang/Lower/StatementContext.h"
 #include "flang/Lower/SymbolMap.h"
 #include "flang/Optimizer/Builder/Character.h"
 #include "flang/Optimizer/Builder/Complex.h"
 #include "flang/Optimizer/Builder/FIRBuilder.h"
 #include "flang/Optimizer/Builder/MutableBox.h"
 #include "flang/Optimizer/Builder/Runtime/Character.h"
 #include "flang/Optimizer/Builder/Runtime/Command.h"
 #include "flang/Optimizer/Builder/Runtime/Inquiry.h"
 #include "flang/Optimizer/Builder/Runtime/Numeric.h"
 #include "flang/Optimizer/Builder/Runtime/RTBuilder.h"
 #include "flang/Optimizer/Builder/Runtime/Reduction.h"
 #include "flang/Optimizer/Builder/Runtime/Stop.h"
 #include "flang/Optimizer/Builder/Runtime/Transformational.h"
 #include "flang/Optimizer/Builder/Todo.h"
 #include "flang/Optimizer/Dialect/FIROpsSupport.h"
 #include "flang/Optimizer/Support/FatalError.h"
+#include "flang/Version.inc"
 #include "mlir/Dialect/LLVMIR/LLVMDialect.h"
 #include "mlir/Dialect/Math/IR/Math.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
 
 #define DEBUG_TYPE "flang-lower-intrinsic"
 
 #define PGMATH_DECLARE
struct IntrinsicLibrary {
   mlir::Value genCmplx(mlir::Type, llvm::ArrayRef<mlir::Value>);
   mlir::Value genConjg(mlir::Type, llvm::ArrayRef<mlir::Value>);
   fir::ExtendedValue genCount(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
   void genCpuTime(llvm::ArrayRef<fir::ExtendedValue>);
   fir::ExtendedValue genCshift(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
   void genCFPointer(llvm::ArrayRef<fir::ExtendedValue>);
   fir::ExtendedValue genCFunLoc(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
   fir::ExtendedValue genCLoc(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
+  fir::ExtendedValue genCompilerVersion(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
   void genDateAndTime(llvm::ArrayRef<fir::ExtendedValue>);
   mlir::Value genDim(mlir::Type, llvm::ArrayRef<mlir::Value>);
   fir::ExtendedValue genDotProduct(mlir::Type,
                                    llvm::ArrayRef<fir::ExtendedValue>);
   mlir::Value genDprod(mlir::Type, llvm::ArrayRef<mlir::Value>);
   mlir::Value genDshiftl(mlir::Type, llvm::ArrayRef<mlir::Value>);
   mlir::Value genDshiftr(mlir::Type, llvm::ArrayRef<mlir::Value>);
   fir::ExtendedValue genEoshift(mlir::Type, llvm::ArrayRef<fir::ExtendedValue>);
static constexpr IntrinsicHandler handlers[]{
     {"c_funloc", &I::genCFunLoc, {{{"x", asBox}}}, /*isElemental=*/false},
     {"c_loc", &I::genCLoc, {{{"x", asBox}}}, /*isElemental=*/false},
     {"ceiling", &I::genCeiling},
     {"char", &I::genChar},
     {"cmplx",
      &I::genCmplx,
      {{{"x", asValue}, {"y", asValue, handleDynamicOptional}}}},
     {"command_argument_count", &I::genCommandArgumentCount},
+    {"compiler_version", &I::genCompilerVersion},
     {"conjg", &I::genConjg},
     {"count",
      &I::genCount,
      {{{"mask", asAddr}, {"dim", asValue}, {"kind", asValue}}},
      /*isElemental=*/false},
     {"cpu_time",
      &I::genCpuTime,
      {{{"time", asAddr}}},
fir::ExtendedValue IntrinsicLibrary::genCommandArgumentCount(
   assert(args.size() == 0);
   assert(resultType == builder.getDefaultIntegerType() &&
          "result type is not default integer kind type");
   return builder.createConvert(
       loc, resultType, fir::runtime::genCommandArgumentCount(builder, loc));
   ;
 }
 
+// COMPILER_VERSION
+fir::ExtendedValue IntrinsicLibrary::genCompilerVersion(
+    mlir::Type resultType, llvm::ArrayRef<fir::ExtendedValue> args) {
+  assert(args.size() == 0);
+  return fir::factory::createStringLiteral(builder, loc, Fortran::common::getFlangFullVersion());
+}
+
+
 // CONJG
 mlir::Value IntrinsicLibrary::genConjg(mlir::Type resultType,
                                        llvm::ArrayRef<mlir::Value> args) {
   assert(args.size() == 1);
   if (resultType != args[0].getType())
     llvm_unreachable("argument type mismatch");
 
   mlir::Value cplx = args[0];