https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/133775
>From aeca7c2c7bf4cc7aef87374f3890f2a42e61d07d Mon Sep 17 00:00:00 2001
From: David Truby
Date: Mon, 31 Mar 2025 19:39:37 +0100
Subject: [PATCH 1/2] [flang] Complete alignment of -x language modes with
gfort
https://github.com/DavidTruby approved this pull request.
LGTM thanks!
https://github.com/llvm/llvm-project/pull/134002
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
@@ -817,8 +817,13 @@ void Flang::ConstructJob(Compilation &C, const JobAction
&JA,
// 'flang -E' always produces output that is suitable for use as fixed form
// Fortran. However it is only valid free form sourc
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/133775
>From aeca7c2c7bf4cc7aef87374f3890f2a42e61d07d Mon Sep 17 00:00:00 2001
From: David Truby
Date: Mon, 31 Mar 2025 19:39:37 +0100
Subject: [PATCH 1/2] [flang] Complete alignment of -x language modes with
gfort
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
@@ -863,6 +863,12 @@ static void
parsePreprocessorArgs(Fortran::frontend::PreprocessorOptions &opts,
(currentArg->getOption().matches(clang::driver::options::OPT_cpp))
? PPMacrosFlag::Include
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
@@ -817,8 +817,13 @@ void Flang::ConstructJob(Compilation &C, const JobAction
&JA,
// 'flang -E' always produces output that is suitable for use as fixed form
// Fortran. However it is only valid free form sourc
@@ -88,8 +88,8 @@ TYPE("assembler-with-cpp", Asm, PP_Asm,
"S", phases
// modules when Flang needs to emit pre-processed files. Therefore, the
// `PP_TYPE` is set to `PP_Fortran` so that the driver is fine with
// "pre-processing a pre-processed fil
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
DavidTruby wrote:
I've created a PR at #133775 cleaning up the meanings of the `-x` options in
the compiler driver, which I believe resolves the above issue but leaves this
fix in place. If you could check that it still works for you
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/133775
This fixes an issue where, since the alignment of the -x lanaguage
modes, .f90 files were being preprocessed by default. This patch
completes the alignment of the meaning of the f95-pp-input and f95
language m
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/130268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/130268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
https://github.com/DavidTruby approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/132801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
https://github.com/DavidTruby approved this pull request.
This LGTM now when @tarunprabhu is happy, thanks for seeing this through
despite my lengthy comments!
This isn't to hold up this patch, but as a separate thought: I wonder if
=?utf-8?q?Iñaki?= Amatria Barral
Message-ID:
In-Reply-To:
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/130268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
DavidTruby wrote:
Some extra context: there was a discussion quite some time ago about moving
lots of the driver/diagnostic code from `clang` to a separate top-level LLVM
project, and I believe it was generally agreed that this would be a good idea:
https://discourse.llvm.org/t/rfc-refactor-cl
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6980,3 +6980,37 @@ void driver::applyOverrideOptions(SmallVectorImpl &Args,
++S;
}
}
+
+/// Vectorize at all optimization levels greater than 1 except for -Oz.
+/// For -Oz the loop vectorizer is disabled, while the slp vectorizer is
+/// enabled.
+bool driver::shou
@@ -3986,11 +3986,15 @@ defm assumptions : BoolFOption<"assumptions",
"Disable codegen and compile-time checks for C++23's [[assume]]
attribute">,
PosFlag>;
+
+let Visibility = [ClangOption, FlangOption] in {
DavidTruby wrote:
The docs
[here](ht
DavidTruby wrote:
It looks like the force push has worked this time. Sorry it took so long to do,
I was on holiday.
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/119718
>From af135a1a4156be9076931ceeb92f75171a0cb7ad Mon Sep 17 00:00:00 2001
From: David Truby
Date: Thu, 12 Dec 2024 14:50:19 +
Subject: [PATCH] [flang] Add -f[no-]vectorize flags
---
clang/include/clang/Dr
DavidTruby wrote:
Sorry, I managed to have a better look at our CI and this seems to be a
downstream build system issue. I assumed because the upstream CI was also
broken that it was an issue in both but that seems to be unrelated.
No need to revert, sorry for the noise!
https://github.com/ll
DavidTruby wrote:
At a quick glance it looks like we're still trying to link FortranDecimal
somewhere so this might be #121997 instead..
https://github.com/llvm/llvm-project/pull/122341
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
DavidTruby wrote:
This has broken Windows builds but I'm not fully sure why and I can't
investigate as I'm on holiday. Can we revert until we can work out why Windows
builds are broken?
https://github.com/llvm/llvm-project/pull/122341
___
cfe-commits
DavidTruby wrote:
I have force pushed this to my branch but github doesn't seem to be picking it
up on this review?? I don't really know how to fix this.
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.l
DavidTruby wrote:
Ugh it looks like my editor just clang-formatted everything instead of only
changes...
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/119718
>From 0dc613d94560cbe4e8a57eed35d985e9d6dae752 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Thu, 12 Dec 2024 14:50:19 +
Subject: [PATCH] [flang] Add -f[no-]vectorize flags
---
clang/include/clang/Dr
DavidTruby wrote:
I guess the tests in this should have had --target= for the targets I checked
them on (x86_64 and aarch64). I can add those and remove the xfail?
https://github.com/llvm/llvm-project/pull/122906
___
cfe-commits mailing list
cfe-commi
https://github.com/DavidTruby approved this pull request.
LGTM, I'm glad we're matching clang's behaviour here. Thanks!
https://github.com/llvm/llvm-project/pull/101701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/122906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,37 @@
+! RUN: %flang_fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=2
-o- %s | FileCheck %s --check-prefixes=CHECK,UNROLL
+! RUN: %flang_fc1 -emit-llvm -O2 -mllvm -force-vector-width=2 -o- %s |
FileCheck %s --check-prefixes=CHECK,UNROLL
+! RUN: %flang_fc
@@ -0,0 +1,37 @@
+! RUN: %flang_fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=2
-o- %s | FileCheck %s --check-prefixes=CHECK,UNROLL
+! RUN: %flang_fc1 -emit-llvm -O2 -mllvm -force-vector-width=2 -o- %s |
FileCheck %s --check-prefixes=CHECK,UNROLL
+! RUN: %flang_fc
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/122906
>From c9b2e5855fdbbaafb5512e1e2539983201202b25 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 8 Jan 2025 11:19:38 +
Subject: [PATCH 1/5] [flang] Add -f[no-]unroll-loops flag
This patch adds suppor
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/122906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/122906
>From c9b2e5855fdbbaafb5512e1e2539983201202b25 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 8 Jan 2025 11:19:38 +
Subject: [PATCH 1/4] [flang] Add -f[no-]unroll-loops flag
This patch adds suppor
@@ -0,0 +1,43 @@
+// RUN: %flang_fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=1
-o- %s | FileCheck %s --check-prefixes=CHECK,UNROLL
DavidTruby wrote:
Actually, source->HLFIR isn't useful. I'll add a source->llvm integration test.
https://github.
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/122906
>From c9b2e5855fdbbaafb5512e1e2539983201202b25 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 8 Jan 2025 11:19:38 +
Subject: [PATCH 1/3] [flang] Add -f[no-]unroll-loops flag
This patch adds suppor
@@ -0,0 +1,43 @@
+// RUN: %flang_fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=1
-o- %s | FileCheck %s --check-prefixes=CHECK,UNROLL
DavidTruby wrote:
I guess we should possibly have all 3? A source to HLFIR, this test, and
source->llvmir?
http
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/122906
>From c9b2e5855fdbbaafb5512e1e2539983201202b25 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 8 Jan 2025 11:19:38 +
Subject: [PATCH 1/2] [flang] Add -f[no-]unroll-loops flag
This patch adds suppor
@@ -150,12 +150,17 @@ void Flang::addCodegenOptions(const ArgList &Args,
if (shouldLoopVersion(Args))
CmdArgs.push_back("-fversion-loops-for-stride");
+ Args.addAllArgs(CmdArgs, {options::OPT_flang_experimental_hlfir,
+options::OPT_flang_depr
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/122906
This patch adds support for the -funroll-loops and -fno-unroll-loops flags with
similar behaviour to clang. funroll-loops is enabled at -O2 onwards as is the
current default.
>From c9b2e5855fdbbaafb5512e1e2
https://github.com/DavidTruby commented:
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.
In terms of implementation it looks like there'
DavidTruby 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.
In terms of implementation it looks like there's already a clang-ti
@@ -6980,3 +6980,37 @@ void driver::applyOverrideOptions(SmallVectorImpl &Args,
++S;
}
}
+
+/// Vectorize at all optimization levels greater than 1 except for -Oz.
+/// For -Oz the loop vectorizer is disabled, while the slp vectorizer is
+/// enabled.
+bool driver::shou
DavidTruby wrote:
That's interesting, there _is_ an external assembler on Windows; in fact, LLVM
itself builds one (llvm-ml.exe) as well as MSVC providing one (ml.exe). I
wonder why we can't just use llvm-ml here, since we know it must be available?
I can have a look if this works for clang. I
https://github.com/DavidTruby converted_to_draft
https://github.com/llvm/llvm-project/pull/119718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/119718
This patch adds the -fvectorize and -fno-vectorize flags to flang.
Note that this also changes the behaviour of `flang -fc1` to match that of
`clang -cc1`, which is that vectorization is only enabled in the
https://github.com/DavidTruby commented:
This LGTM but I think the other reviewers need to take a look too.
Can you change the title and description of the PR/commit to represent that
what we're doing is different now?
https://github.com/llvm/llvm-project/pull/117573
___
https://github.com/DavidTruby approved this pull request.
LGTM, thanks for being patient with our requests for changes!
https://github.com/llvm/llvm-project/pull/117563
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/DavidTruby commented:
I think you still don't need any of the shared_ptr usage here, there's no
shared ownership semantics. If you change all these to unique_ptr then I think
the patch would look good to me.
https://github.com/llvm/llvm-project/pull/116406
__
@@ -61,11 +61,11 @@ class Compilation {
OrderedOffloadingToolchains;
/// The original (untranslated) input argument list.
- llvm::opt::InputArgList *Args;
+ std::unique_ptr Args;
/// The driver translated arguments. Note that toolchains may perform their
///
@@ -0,0 +1 @@
+-ffast-math -Wl,--as-needed | -lm -Wl,-Bstatic -lhappy -Wl,-Bdynamic
DavidTruby wrote:
I'm indifferent to what symbol we choose, but I believe `@` is already used for
including other config files, so we should avoid that to avoid having a
collisi
@@ -63,41 +56,39 @@ Compilation::getArgsForToolChain(const ToolChain *TC,
StringRef BoundArch,
if (!TC)
TC = &DefaultToolChain;
- DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];
+ std::shared_ptr &Entry =
+ TCArgs[{TC, BoundArch, DeviceOffloa
@@ -777,6 +777,15 @@ void Flang::ConstructJob(Compilation &C, const JobAction
&JA,
addFortranDialectOptions(Args, CmdArgs);
+ // 'flang -E' always produces output that is suitable for use as fixed form
+ // Fortran. However it is only valid free form source if the origin
@@ -63,41 +56,39 @@ Compilation::getArgsForToolChain(const ToolChain *TC,
StringRef BoundArch,
if (!TC)
TC = &DefaultToolChain;
- DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];
+ std::shared_ptr &Entry =
DavidTruby wrote:
You ca
@@ -100,7 +100,7 @@ class Compilation {
return false;
}
};
- std::map TCArgs;
+ std::map> TCArgs;
DavidTruby wrote:
This can be a unique_ptr, as TCArgs owns the underlying DerivedArgList.
https://github.com/llvm/llvm-project/pull/116406
@@ -0,0 +1 @@
+-ffast-math -Wl,--as-needed | -lm -Wl,-Bstatic -lhappy -Wl,-Bdynamic
DavidTruby wrote:
Could we just pick a character to prefix each argument with that indicates that
that argument should come at the end? `$` maybe?
e.g.
```
-ffast-math $-lm
-Wl
@@ -0,0 +1 @@
+-ffast-math -Wl,--as-needed | -lm -Wl,-Bstatic -lhappy -Wl,-Bdynamic
DavidTruby wrote:
Can we check that this works for multiple line config files? E.g. I would
expect:
```
-ffast-math | -lm
-Wl,--as-needed | -Wl,-Bstatic -lhappy
| -Wl,-Bdynamic
`
@@ -63,41 +56,39 @@ Compilation::getArgsForToolChain(const ToolChain *TC,
StringRef BoundArch,
if (!TC)
TC = &DefaultToolChain;
- DerivedArgList *&Entry = TCArgs[{TC, BoundArch, DeviceOffloadKind}];
+ std::shared_ptr &Entry =
+ TCArgs[{TC, BoundArch, DeviceOffloa
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/116406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/118244
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby approved this pull request.
LGTM. Would be good if someone from the clang side of things can approve as
well, as this is a fairly big functionality change for config files.
https://github.com/llvm/llvm-project/pull/117573
___
DavidTruby wrote:
I'm not sure if it's explicitly documented anywhere but there's a lot of tests,
as you can see in the patch that introduced the behaviour here:
https://reviews.llvm.org/D106727
Essentially since that patch the output is _always_ valid 72 width fixed form,
and if the input wa
DavidTruby wrote:
Thanks for the info on -save-temps, I understand it a little better now !
> we could simplify by requiring that flang -E always produces free-form output.
flang -E is already consistent here, it always produces fixed form output. So I
think we can just teach flang -fc1 that '
DavidTruby wrote:
`-save-temps` doesn't appear to work for me at all, I get the following error:
```
"S:\\llvm-project\\build\\bin\\flang.exe" -cc1as -triple
x86_64-pc-windows-msvc19.41.34123 -filetype obj -main-file-name test.f90
-target-cpu x86-64 "-fdebug-compilation-dir=S:\\llvm-project\\b
@@ -61,3 +61,24 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
@@ -61,3 +61,24 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
@@ -61,3 +61,24 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
@@ -1250,6 +1273,7 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
if (!ContainsError)
ContainsError = loadConfigFiles();
bool HasConfigFile = !ContainsError && (CfgOptions.get() != nullptr);
+ bool HasConfigLinkerIn = !ContainsError && (CfgLinkerInputs.ge
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -82,3 +82,24 @@
// CHECK-TWO-CONFIGS: -isysroot
// CHECK-TWO-CONFIGS-SAME: /opt/data
// CHECK-TWO-CONFIGS-SAME: -Wall
+
+//--- The -l flags should be moved to the end of input list and appear only
when linking.
+// RUN: %clang --target=aarch64-unknown-linux-gnu --config
%S
@@ -61,3 +61,24 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
https://github.com/DavidTruby commented:
Change LGTM in general but I'd like Windows to have tests before approving as
we need this to be working there too
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists
@@ -61,3 +61,22 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
https://github.com/DavidTruby requested changes to this pull request.
I think it makes sense to handle linker options differently so I'm in favour of
this change in principle.
Am I right in thinking that if the config file puts things last, the `-l`
options provided by users will come before t
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidTruby wrote:
Thanks for the fix, I'd like to understand what the bug is better though; what
is the difference between the proposed `flang -fc1 -x f95-fixed` and the
existing `flang -fc1 -ffixed-form`?
In the test case in here I already don't see an error with `flang -fc1
-ffixed-form`, i
DavidTruby wrote:
> with -fveclib=ArmPL -lamath put into a config file, it will always be linked
> with libamath, even if the user decides to use -fveclib=none
I think there might be a related issue with the approach in this patch too
though, in that `-fveclib=ArmPL` will silently force linkin
@@ -490,6 +490,16 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
else
A.renderAsInput(Args, CmdArgs);
}
+ if (const Arg *A = Args.getLastArg(options::OPT_fveclib)) {
+if (A->getNumValues() == 1) {
+ StringRef V = A->getVa
@@ -1544,8 +1544,8 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
}
// The compilation takes ownership of Args.
- Compilation *C = new Compilation(*this, TC, UArgs.release(), TranslatedArgs,
- ContainsError);
+ Compilation
DavidTruby wrote:
@pawosm-arm it looks like clang config files are sufficient for this and don't
have the behaviour we thought was problematic? Can we drop this patch if I'm
right in thinking that?
https://github.com/llvm/llvm-project/pull/115163
___
DavidTruby wrote:
@pawosm-arm it doesn't look like we are going to get consensus on this change
so perhaps we should just drop it?
https://github.com/llvm/llvm-project/pull/115286
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/116406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby requested changes to this pull request.
Thanks for the patch!
I don't think there's any actual shared ownership happening here so I think you
could use `unique_ptr` instead, and that has lower overhead so would be
preferable I think.
I've left a comment as to why
@@ -490,6 +490,16 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
else
A.renderAsInput(Args, CmdArgs);
}
+ if (const Arg *A = Args.getLastArg(options::OPT_fveclib)) {
+if (A->getNumValues() == 1) {
+ StringRef V = A->getVa
@@ -490,6 +490,16 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
else
A.renderAsInput(Args, CmdArgs);
}
+ if (const Arg *A = Args.getLastArg(options::OPT_fveclib)) {
+if (A->getNumValues() == 1) {
+ StringRef V = A->getVa
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/116432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -490,6 +490,16 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
else
A.renderAsInput(Args, CmdArgs);
}
+ if (const Arg *A = Args.getLastArg(options::OPT_fveclib)) {
+if (A->getNumValues() == 1) {
+ StringRef V = A->getVa
https://github.com/DavidTruby approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/114735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidTruby wrote:
It's also of course possible to have this as the sensible default (making
clang+openmp work out of the box, making flang work out of the box etc) and
expect people wanting the opposite to use config files to add
`-fno-rtlib-add-rpath`. I guess that it's possible that this wou
DavidTruby wrote:
I'd argue that this provides the least surprising behaviour to the end user:
building a file with `clang -fopenmp` or `clang++ -stdlib=libc++` where
openmp/libc++ were enabled on that LLVM build gives a binary that can just be
run on that system, without setting any environme
DavidTruby wrote:
For what it’s worth, as a user I’m always surprised that this _isn’t_ the
default. It’s quite annoying to eg have to set LD_LIBRARY_PATH when using
openmp with clang when they’re built alongside each other. Is there a specific
reason this isn’t the default or is it just histo
https://github.com/DavidTruby approved this pull request.
LGTM, and seems useful especially for flang.
https://github.com/llvm/llvm-project/pull/115163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -0,0 +1,34 @@
+! REQUIRES: x86-registered-target
DavidTruby wrote:
This test doesn't actually need x86-registered-target. The driver is able to
construct command lines for targets that aren't registered as LLVM backends,
and since we're using -### all we nee
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/115163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidTruby wrote:
@pawosm-arm do you still need this or do the CMake configuration changes I
suggested work? Can we close this if it's not needed anymore?
https://github.com/llvm/llvm-project/pull/110598
___
cfe-commits mailing list
cfe-commits@lists.
DavidTruby wrote:
Sorry I wasn’t very clear in my previous comments; I think we shouldn’t go
ahead with this PR and should continue to reject the flag. So I think we’re in
agreement.
https://github.com/llvm/llvm-project/pull/110598
___
cfe-commits ma
DavidTruby wrote:
> Have you checked the flang driver? Is it not applicable there since errno is
> not used in Flang?
We don't support the gfortran extension for checking errno in flang and I can't
see another way of checking it portably, so I wonder if we should just have
this flag on by def
DavidTruby wrote:
I don’t personally think that the flang driver should ever attempt to link a
C++ library of any kind. FWIW while there’s no stdlib option to consider in
their case, g++ will never auto link the gfortran runtimes and gfortran will
never auto link libstdc++
Mixed C++/Fortran p
1 - 100 of 242 matches
Mail list logo
