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
DavidTruby wrote:
An example for my previous point. If I have a CMakeLists.txt:
```
project(test LANGUAGES CXX Fortran)
cmake_minimum_required(VERSION 3.28)
add_executable(hello test.cpp test.f90)
```
and the relevant files (doesn't really matter what they contain), then if I
build with:
```
en
DavidTruby wrote:
I missed replying on this review somehow, sorry to come back 2 weeks later...
> Why are CXXFLAGS used when invoking a Fortran compiler? That's not correct,
> is it?
I don't think CXXFLAGS will be being added to the flang invocation in this
case. What I believe is happening i
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/112202
___
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/112202
>From 1f039de4e91c052033bed2ecab1ac0fe101ffeea Mon Sep 17 00:00:00 2001
From: David Truby
Date: Mon, 14 Oct 2024 14:39:44 +0100
Subject: [PATCH 1/2] [flang] Link to libatomic with openmp and rtlib=libgcc
Cur
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/112202
>From 1f039de4e91c052033bed2ecab1ac0fe101ffeea Mon Sep 17 00:00:00 2001
From: David Truby
Date: Mon, 14 Oct 2024 14:39:44 +0100
Subject: [PATCH 1/2] [flang] Link to libatomic with openmp and rtlib=libgcc
Cur
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/112202
Currently when using OpenMP atomics we depend on some symbols from
libatomic. These symbols are provided in a separate library for the
libgcc runtime, so we should link to that when rtlib=libgcc.
For the comp
@@ -339,11 +335,11 @@ just added using your new frontend option.
## CMake Support
As of [#7246](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7246)
-(and soon to be released CMake 3.24.0), `cmake` can detect `flang-new` as a
+(and soon to be released CMake 3.24.0), `
DavidTruby wrote:
For what it's worth, MSVC and icc/icx also build @jeanPerier's example without
complaint, so I think it should probably be accepted by clang as well even if
it is ambiguous per the standard.
https://github.com/llvm/llvm-project/pull/100692
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/99058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidTruby wrote:
Linux builds appear to have stopped, but all the previous linux builds worked
so I think this is fine to merge. I will revert if it breaks post-commit.
https://github.com/llvm/llvm-project/pull/99058
___
cfe-commits mailing list
cfe-
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/99058
>From 66e13f92a0680742b552fabde25df7752f8510c9 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Tue, 16 Jul 2024 15:39:28 +
Subject: [PATCH 1/3] [flang] Add -rtlib flag
This patch allows the -rtlib flag w
DavidTruby wrote:
It looks like clang_rt.crtbegin and clang_rt.crtend aren't always used on every
platform so I've just removed the check for those. The check for
`libclang_rt.builtins` and NOT `libgcc` and `libgcc_s` should be enough to
check we are linking the right thing.
https://github.co
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/99058
>From 66e13f92a0680742b552fabde25df7752f8510c9 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Tue, 16 Jul 2024 15:39:28 +
Subject: [PATCH 1/2] [flang] Add -rtlib flag
This patch allows the -rtlib flag w
DavidTruby wrote:
I don't know why the pre-commit build failed on Windows. The build itself looks
fine but seems to be complaining about slow tests?
https://github.com/llvm/llvm-project/pull/99058
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/99058
This patch allows the -rtlib flag with flang-new to select between the
libgcc_s and compiler-rt runtimes. The behaviour is identical to the
same flag with clang.
>From 66e13f92a0680742b552fabde25df7752f8510c9
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/96557
___
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/96557
Reverts llvm/llvm-project#90886
These changes broke linking to compiler-rt on Windows
>From 0f6f6ddbc0d84d2df23df8c8a771ace3c0dca988 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Mon, 24 Jun 2024 21:53:39
DavidTruby wrote:
Hi @mjklemm, this appears to be breaking linking entirely on Windows, I'm not
sure how it's taken us so long to notice...
With the patch I get errors trying to find compiler-rt but without it I can
build fine. I wonder why this patch _changed_ the resource directory, as well
DavidTruby wrote:
It looks like `-mcmodel=medium` implies another flag on x86-64 that I haven't
implemented. I will post another patch implementing `-mlarge-data-threshold`
and endeavour to merge that before this patch so that this works on x86-64.
https://github.com/llvm/llvm-project/pull/954
@@ -39,6 +39,7 @@ ENUM_CODEGENOPT(RelocationModel, llvm::Reloc::Model, 3,
llvm::Reloc::PIC_) ///<
ENUM_CODEGENOPT(DebugInfo, llvm::codegenoptions::DebugInfoKind, 4,
llvm::codegenoptions::NoDebugInfo) ///< Level of debug info to generate
ENUM_CODEGENOPT(VecLib, llvm::driver::
@@ -39,6 +39,7 @@ ENUM_CODEGENOPT(RelocationModel, llvm::Reloc::Model, 3,
llvm::Reloc::PIC_) ///<
ENUM_CODEGENOPT(DebugInfo, llvm::codegenoptions::DebugInfoKind, 4,
llvm::codegenoptions::NoDebugInfo) ///< Level of debug info to generate
ENUM_CODEGENOPT(VecLib, llvm::driver::
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/95411
This patch implements the -mcmodel flag from clang, allowing the Code Model to
be changed for the LLVM module. The same set of mcmodel flags are accepted as
in clang and the same Code Model attributes are added
https://github.com/DavidTruby approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/91965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/90758
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidTruby wrote:
I've left the flang test as the flang directory doesn't change with
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` and removed the other test. I hope this is
what you meant @MaskRay 👍
https://github.com/llvm/llvm-project/pull/90758
___
cfe-c
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/90758
>From 9763281019c1fb27714243450d7a6879e91dcb28 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 1 May 2024 19:41:47 +0100
Subject: [PATCH 1/3] [clang][flang][windows] Prefer user-provided library
paths (
DavidTruby wrote:
> The code checks whether the directory is present `auto CRTPath =
> TC.getCompilerRTPath();` and only adds the libpath when it is present. This
> is related to the `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=off` file hierarchy we
> are migrating way from.
>
> With `LLVM_ENABLE_PER
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/90758
>From 0afdbb7dac3a3a051661d5747c8c6470a13f1e0c Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 1 May 2024 19:41:47 +0100
Subject: [PATCH 1/2] [clang][flang][windows] Prefer user-provided library
paths (
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/90758
Currently the paths to compiler-rt and the Flang runtimes from the LLVM
build/install directory are preferred over any user-provided library paths.
This means a user can't override compiler-rt or the Flang ru
1 - 100 of 213 matches
Mail list logo
