@@ -11530,6 +11530,8 @@ def note_omp_nested_teams_construct_here : Note<
"nested teams construct here">;
def note_omp_nested_statement_here : Note<
"%select{statement|directive}0 outside teams construct here">;
+def err_omp_nowait_with_arg_unsupported : Error<
+ "'nowait'
@@ -11530,6 +11530,8 @@ def note_omp_nested_teams_construct_here : Note<
"nested teams construct here">;
def note_omp_nested_statement_here : Note<
"%select{statement|directive}0 outside teams construct here">;
+def err_omp_nowait_with_arg_unsupported : Error<
+ "'nowait'
mjklemm wrote:
I think the error message is still misleading because:
- it refers to "bitwise operators" which is not something that goes into
`notwait`, but rather an expression that should be of a logical type; and
- it should IMHO not be "floating type", but "floating-point type".
https://
https://github.com/mjklemm requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/135030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -8,11 +8,11 @@ int main(int argc, char **argv) {
#pragma omp nowait target update to(i) // expected-error {{expected an
OpenMP directive}}
#pragma omp target nowait update to(i) // expected-error {{unexpected OpenMP
clause 'update' in directive '#pragma omp target'}} ex
@@ -7,13 +7,13 @@ void foo() {
int main(int argc, char **argv) {
int i;
-#pragma omp target teams distribute parallel for simd nowait( //
expected-warning {{extra tokens at the end of '#pragma omp target teams
distribute parallel for simd' are ignored}}
+#pragma omp target
@@ -7,13 +7,13 @@ void foo() {
int main(int argc, char **argv) {
int i;
-#pragma omp target teams distribute simd nowait( // expected-warning {{extra
tokens at the end of '#pragma omp target teams distribute simd' are ignored}}
+#pragma omp target teams distribute simd nowa
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/128742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7,13 +7,13 @@ void foo() {
int main(int argc, char **argv) {
int i;
-#pragma omp target teams distribute parallel for nowait( // expected-warning
{{extra tokens at the end of '#pragma omp target teams distribute parallel for'
are ignored}}
+#pragma omp target teams dis
@@ -7,13 +7,13 @@ void foo() {
int main(int argc, char **argv) {
int i;
- #pragma omp target parallel for nowait( // expected-warning {{extra tokens
at the end of '#pragma omp target parallel for' are ignored}}
+ #pragma omp target parallel for nowait( // expected-error
@@ -6,13 +6,11 @@ void foo() {
}
int main(int argc, char **argv) {
-#pragma omp target teams nowait( // expected-warning {{extra tokens at the end
of '#pragma omp target teams' are ignored}}
- foo();
-#pragma omp target teams nowait (argc)) // expected-warning {{extra tokens
@@ -7,13 +7,14 @@ void foo() {
int main(int argc, char **argv) {
int i;
- #pragma omp target simd nowait( // expected-warning {{extra tokens at the
end of '#pragma omp target simd' are ignored}}
+ #pragma omp target simd nowait( // expected-error {{expected expression}}
@@ -6,13 +6,13 @@ void foo() {
}
int main(int argc, char **argv) {
- #pragma omp target parallel nowait( // expected-warning {{extra tokens at
the end of '#pragma omp target parallel' are ignored}}
- foo();
+ #pragma omp target parallel nowait( // expected-error {{expecte
@@ -11530,6 +11530,8 @@ def note_omp_nested_teams_construct_here : Note<
"nested teams construct here">;
def note_omp_nested_statement_here : Note<
"%select{statement|directive}0 outside teams construct here">;
+def err_omp_nowait_with_arg_unsupported : Error<
+ "'nowait'
@@ -7,13 +7,12 @@ void foo() {
int main(int argc, char **argv) {
int i;
-#pragma omp target teams distribute nowait( // expected-warning {{extra tokens
at the end of '#pragma omp target teams distribute' are ignored}}
- for (i = 0; i < argc; ++i) foo();
-#pragma omp target
@@ -7,13 +7,13 @@ void foo() {
int main(int argc, char **argv) {
int i;
- #pragma omp target parallel for simd nowait( // expected-warning {{extra
tokens at the end of '#pragma omp target parallel for simd' are ignored}}
+ #pragma omp target parallel for simd nowait( //
https://github.com/mjklemm requested changes to this pull request.
Please put this under 6.0 version guard. Otherwise, LGTM for now.
https://github.com/llvm/llvm-project/pull/128742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
mjklemm wrote:
> Should the `nowait(EXPR)` behavior be guarded by the OpenMP version flag? It
> seems to me that the tests would currently not respect which OpenMP version
> is selected and always generate the error.
I agree. This should be under `-fopenmp-version=6.0`
https://github.com/llv
https://github.com/mjklemm approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/128640
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/126026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mjklemm wrote:
One warning per source file is what is being done for -fopenmp at the moment.
So, it should be fine to do that.
https://github.com/llvm/llvm-project/pull/126026
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
@@ -0,0 +1,380 @@
+
+
+# `DO CONCURENT` mapping to OpenMP
+
+```{contents}
+---
+local:
+---
+```
+
+This document seeks to describe the effort to parallelize `do concurrent` loops
+by mapping them to OpenMP worksharing constructs. The goals of this document
+are:
+* Describing ho
https://github.com/mjklemm approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/125648
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6910,6 +6910,10 @@ defm loop_versioning : BoolOptionWithoutMarshalling<"f",
"version-loops-for-stri
def fhermetic_module_files : Flag<["-"], "fhermetic-module-files">,
Group,
HelpText<"Emit hermetic module files (no nested USE association)">;
+
+def do_concurrent_paral
@@ -6910,6 +6910,10 @@ defm loop_versioning : BoolOptionWithoutMarshalling<"f",
"version-loops-for-stri
def fhermetic_module_files : Flag<["-"], "fhermetic-module-files">,
Group,
HelpText<"Emit hermetic module files (no nested USE association)">;
+
+def do_concurrent_paral
https://github.com/mjklemm approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm requested changes to this pull request.
Please address @saiislam's questions. I also think that the title and
description of the PR should reflect that this PR not only introduces the 6.0
flag, but also moves several of the tests to test against 5.1 and 6.0.
https:
mjklemm wrote:
Please resolve open feedback items before the next round of reviews. Thanks.
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/mjklemm approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/101701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4174,7 +4174,7 @@ bool CompilerInvocation::ParseLangArgs(LangOptions &Opts,
ArgList &Args,
}
// Check if -fopenmp is specified and set default version to 5.0.
- Opts.OpenMP = Args.hasArg(OPT_fopenmp) ? 51 : 0;
+ Opts.OpenMP = Args.hasArg(OPT_fopenmp) ? 60 : 0;
-
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4192,7 +4192,7 @@ bool CompilerInvocation::ParseLangArgs(LangOptions &Opts,
ArgList &Args,
if (Opts.OpenMP || Opts.OpenMPSimd) {
if (int Version = getLastArgIntValue(
Args, OPT_fopenmp_version_EQ,
-(IsSimdSpecified || IsTargetSpecified) ? 51 :
https://github.com/mjklemm requested changes to this pull request.
The PR seems to have two components:
1) Upgrade the compiler code to be able to accept OpenMP 6.0 features
2) switch the default to be OpenMP 6.0
Part 1 is fine, as the community is starting to implement 6.0 features and,
there
mjklemm wrote:
> Is NONE special enough to have a dedicated option, or could we have
> `-fopenmp-default=` for any dsa?
I have thought about this, but that's going to be dangerous. I intended this
option to be solely for detecting potential races through unintended sharing.
https://github.co
@@ -2276,7 +2281,8 @@ void OmpAttributeVisitor::Post(const parser::Name &name) {
if (Symbol * found{currScope().FindSymbol(name.source)}) {
if (symbol != found) {
name.symbol = found; // adjust the symbol within region
-} else if (GetContext().de
@@ -2276,7 +2281,8 @@ void OmpAttributeVisitor::Post(const parser::Name &name) {
if (Symbol * found{currScope().FindSymbol(name.source)}) {
if (symbol != found) {
name.symbol = found; // adjust the symbol within region
-} else if (GetContext().de
mjklemm wrote:
> Would it be a lot of work to add this flag for clang as well? It seems like
> the behaviour would be equally useful there and I would prefer us to keep
> flags available for both compilers where it makes sense.
I will ask one of the Clang adepts in the team to provide a PR or
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/120287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3596,6 +3596,9 @@ def fopenmp : Flag<["-"], "fopenmp">, Group,
Flags<[NoArgumentUnused]>,
Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
HelpText<"Parse OpenMP pragmas and generate parallel code.">;
+def fopenmp_default_none : Flag<["-"], "fopenmp-defau
@@ -2276,7 +2281,8 @@ void OmpAttributeVisitor::Post(const parser::Name &name) {
if (Symbol * found{currScope().FindSymbol(name.source)}) {
if (symbol != found) {
name.symbol = found; // adjust the symbol within region
-} else if (GetContext().de
@@ -2268,6 +2268,11 @@ void OmpAttributeVisitor::CreateImplicitSymbols(
void OmpAttributeVisitor::Post(const parser::Name &name) {
auto *symbol{name.symbol};
+ // if -fopenmp-default-none was given on the command line, act as if
+ // DEFAULT(NONE) was present at the direct
@@ -3596,6 +3596,9 @@ def fopenmp : Flag<["-"], "fopenmp">, Group,
Flags<[NoArgumentUnused]>,
Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
HelpText<"Parse OpenMP pragmas and generate parallel code.">;
+def fopenmp_default_none : Flag<["-"], "fopenmp-defau
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/120287
>From ef9b76ad1dfb4b6c99bbdf6391fe57b944ffbfa2 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Tue, 17 Dec 2024 18:34:06 +0100
Subject: [PATCH 1/4] Implement -fopenmp-default-none compiler flag
---
clang/in
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/120287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm created
https://github.com/llvm/llvm-project/pull/120287
This PR adds `-fopenmp-default-none` command line flag to the Flang compiler.
Similarly, to `-fimplicit-none` it provides error checking for OpenMP
directives by behaving as if `DEFAULT(NONE)` was specified at
https://github.com/mjklemm approved this pull request.
LGTM, I think this simplifies using the compiler a bit when it comes to OpenMP
and more complex `atomic` regions.
https://github.com/llvm/llvm-project/pull/112202
___
cfe-commits mailing list
cfe-
mjklemm wrote:
Since we are making this change now, should this PR be updated to follow
clang's scheme of having `clang` point to `clang-$version`?
https://github.com/llvm/llvm-project/pull/110023
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
mjklemm wrote:
I have seen some more matches for flang-new in the tree:
```
1:.github/workflows/release-binaries.yml:331: ninja -C ${{
steps.setup-stage.outputs.build-prefix }}/build/tools/clang/stage2-bins/ -j2
flang-new bbc
2:openmp/CMakeLists.txt:72:set(OPENMP_TEST_Fortran_COMP
https://github.com/mjklemm approved this pull request.
This looks good to me and should be NFC.
https://github.com/llvm/llvm-project/pull/96814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
https://github.com/mjklemm edited
https://github.com/llvm/llvm-project/pull/96814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm closed
https://github.com/llvm/llvm-project/pull/96799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm created
https://github.com/llvm/llvm-project/pull/96799
This PR re-enables the command line option `-print-resources-dir` after PR
#96557 has reverted the changes made.
The way this works now, is that it simply prints the current resource dir,
which points to clang/
mjklemm wrote:
Yeah, go ahead and revert. I can create a new PR from it just print the
resource dir.
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
mjklemm wrote:
@tblah @banach-space Thanks for the reviews!
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm closed
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/90886
>From 1a994159025f127f0f7d11da80b74035788d52c9 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Thu, 2 May 2024 14:50:45 +0200
Subject: [PATCH 1/8] Enable -print-resource-dir also for Flang
---
clang/include/
mjklemm wrote:
@tblah Ping :-)
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mjklemm wrote:
> and for addressing my comments
More than happy to! Still learning how to be a proper Flang developer, so I'm
thankful for all the comments!
https://github.com/llvm/llvm-project/pull/90886
___
cfe-commits mailing list
cfe-commits@lis
mjklemm wrote:
> Do you know the meaning for Classic Flang?
The way `-print-resource-dir` now works should be consistent with how Classic
Flang works. If that's not the right response, I guess I got my wires crossed
and you need to explain it to me. :-)
https://github.com/llvm/llvm-project/
@@ -5474,7 +5474,7 @@ def print_prog_name_EQ : Joined<["-", "--"],
"print-prog-name=">,
Visibility<[ClangOption, CLOption]>;
def print_resource_dir : Flag<["-", "--"], "print-resource-dir">,
HelpText<"Print the resource directory pathname">,
- Visibility<[ClangOption, CLO
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/90886
>From 1a994159025f127f0f7d11da80b74035788d52c9 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Thu, 2 May 2024 14:50:45 +0200
Subject: [PATCH 1/7] Enable -print-resource-dir also for Flang
---
clang/include/
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/90886
>From 1a994159025f127f0f7d11da80b74035788d52c9 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Thu, 2 May 2024 14:50:45 +0200
Subject: [PATCH 1/6] Enable -print-resource-dir also for Flang
---
clang/include/
@@ -5474,7 +5474,7 @@ def print_prog_name_EQ : Joined<["-", "--"],
"print-prog-name=">,
Visibility<[ClangOption, CLOption]>;
def print_resource_dir : Flag<["-", "--"], "print-resource-dir">,
HelpText<"Print the resource directory pathname">,
- Visibility<[ClangOption, CLO
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/90886
>From 1a994159025f127f0f7d11da80b74035788d52c9 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Thu, 2 May 2024 14:50:45 +0200
Subject: [PATCH 1/5] Enable -print-resource-dir also for Flang
---
clang/include/
@@ -0,0 +1,3 @@
+! RUN: %flang -print-resource-dir -resource-dir=%S/Inputs/resource_dir \
+! RUN: | FileCheck -check-prefix=PRINT-RESOURCE-DIR
-DFILE=%S/Inputs/resource_dir %s
mjklemm wrote:
I'll make the variable a bit clearer in the next update. That's a goo
@@ -0,0 +1,3 @@
+! RUN: %flang -print-resource-dir -resource-dir=%S/Inputs/resource_dir \
+! RUN: | FileCheck -check-prefix=PRINT-RESOURCE-DIR
-DFILE=%S/Inputs/resource_dir %s
+! PRINT-RESOURCE-DIR: [[FILE]]
mjklemm wrote:
It does not. The `/Inputs/resource_di
mjklemm wrote:
> How does this compare to GFortran and Classic Flang? Anything resembling this
> flag?
GFortran does not have it, but Classic Flang does. So, it's closing a gap to
Classic Flang here as well.
https://github.com/llvm/llvm-project/pull/90886
mjklemm wrote:
> What's the definition of "resource dir" for Fortran?
I'd like to at least have it point to where the MODULE files live.
When I look at what clang emits, then Flang's resource directory should rather
point to the place, where Flang has its `lib` and `include` directories. So,
@@ -250,6 +247,25 @@ void Driver::setDriverMode(StringRef Value) {
Diag(diag::err_drv_unsupported_option_argument) << OptName << Value;
}
+void Driver::setResourceDirectory() {
+ // Compute the path to the resource directory, depending on the driver mode.
+ switch (Mode)
https://github.com/mjklemm created
https://github.com/llvm/llvm-project/pull/90886
This should be a NFC change for all drivers, but Flang.
>From 1a994159025f127f0f7d11da80b74035788d52c9 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Thu, 2 May 2024 14:50:45 +0200
Subject: [PATCH 1/3] Enabl
mjklemm wrote:
Should this PR be closed at some point? It seems to be obsolete with the work
that has been done in the recent past to improve the situation.
https://github.com/llvm/llvm-project/pull/78152
___
cfe-commits mailing list
cfe-commits@list
https://github.com/mjklemm approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/79016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mjklemm wrote:
I'm OK with landing this for Linux only at this point.
https://github.com/llvm/llvm-project/pull/79016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mjklemm wrote:
> Maybe we should merge a deprecation warning on -lFortran_main before the LLVM
> release, then make these changes only after the release has branched?
That sounds like a good idea for now. Then, we can buy a bit of time for the
RFC and to make decision how we want to deal with
mjklemm wrote:
> In a long run, I still think that we need to get rid of `Fortran_main`.
> Perhaps, for the minimal, we can rename it to remove `Fortran` in the name to
> make people think that it is not required (by the users) to do any linking
> for Fortran code.
I'd agree to that! The way
mjklemm wrote:
I'm kind of split brain on this. While I do see the issue, I'm not sure if
this should be considered a bug or a user error.
One thing that come to my mind though is (remotely related to this) to have a
command line flag that reports the proper libraries needed to successfully l
mjklemm wrote:
Thanks for all the good suggestions!
https://github.com/llvm/llvm-project/pull/75816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm closed
https://github.com/llvm/llvm-project/pull/75816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From b3fa63a02f63e6fe0dacc25d584eba2012a5a8c5 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/8] Remove -lFortran_main from the link line when -shared is
pre
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From b3fa63a02f63e6fe0dacc25d584eba2012a5a8c5 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/7] Remove -lFortran_main from the link line when -shared is
pre
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From 511f3a4537267284554bf6b33470a01d747b8a94 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/7] Remove -lFortran_main from the link line when -shared is
pre
@@ -163,6 +163,62 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
@@ -163,6 +163,62 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From 511f3a4537267284554bf6b33470a01d747b8a94 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/6] Remove -lFortran_main from the link line when -shared is
pre
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
mjklemm wrote:
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From 511f3a4537267284554bf6b33470a01d747b8a94 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/5] Remove -lFortran_main from the link line when -shared is
pre
https://github.com/mjklemm approved this pull request.
LGTM, but please add to the TODO comment in line 1177 that for AIX a better
solution needs to be found.
https://github.com/llvm/llvm-project/pull/76039
___
cfe-commits mailing list
cfe-commits@lis
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
mjklemm wrote:
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
@@ -163,6 +163,40 @@ forward compiler options to the frontend driver,
`flang-new -fc1`.
You can read more on the design of `clangDriver` in Clang's [Driver Design &
Internals](https://clang.llvm.org/docs/DriverInternals.html).
+## Linker Driver
+When used as a linker, Flang's
mjklemm wrote:
@banach-space How did you draw the pictures in the MD file that I'm changing?
If you have some sort of source file, I can try to add a nice chart to the
explanation, I'm adding.
https://github.com/llvm/llvm-project/pull/75816
___
cfe-
mjklemm wrote:
> May be I missed it when reading through the comments of this PR, why there is
> a definition of `main()` being generated on the Fortran side when the Fortran
> sources are procedures or modules?
It was always generated before, but the bug was hidden by the linker doing the
ri
mjklemm wrote:
> I would probably create a section on building executables and just mention
> that 3 runtime libs will be linked auto-magically. Unless somebody uses
> `-fno-fortran-main` ;-) Make it as short or as long as you prefer - your
> contribution is greatly appreciated 🙏🏻 :)
If have
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From 511f3a4537267284554bf6b33470a01d747b8a94 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/4] Remove -lFortran_main from the link line when -shared is
pre
https://github.com/mjklemm updated
https://github.com/llvm/llvm-project/pull/75816
>From 511f3a4537267284554bf6b33470a01d747b8a94 Mon Sep 17 00:00:00 2001
From: Michael Klemm
Date: Sat, 16 Dec 2023 20:15:17 +0100
Subject: [PATCH 1/3] Remove -lFortran_main from the link line when -shared is
pre
mjklemm wrote:
> I see. So Fortran and C interoperability of F2003/F2008 is not supported yet
> in Flang?
It's rather untested and I'm working hard to get it fixed, so that we have
well-defined behavior that is similar to other Fortran compilers like ifx and
gfortran.
> Those ~100ish regres
mjklemm wrote:
> > Also, not sure what defines `_QQEnvironmentDefaults ` and what exactly
> > makes it problematic?
>
> The `main` entrypoint also calls `_QQEnvironmentDefaults` to treat `argc`,
> `argv`, etc. So, when `main` is included in the shared object, so will be
> those symbols are us
1 - 100 of 181 matches
Mail list logo
