https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/67676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -170,6 +169,38 @@ void Flang::addPicOptions(const ArgList &Args,
ArgStringList &CmdArgs) const {
}
}
+void Flang::AddAArch64TargetArgs(const ArgList &Args,
+ ArgStringList &CmdArgs) const {
+ // Handle -msve_vector_bits=
+ if (Arg *A = A
DavidTruby wrote:
Sorry I haven’t had a chance to look at this yet but I can help you resolve the
Windows issues here.
Windows does support static libraries and that’s the default for the runtime at
the moment, I’ve not actually tried linking the flang runtime dynamically on
Windows so that
https://github.com/DavidTruby approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/68595
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: David Truby
Date: 2023-06-22T16:21:09+01:00
New Revision: b81c5070d5451af127b2c9c2ae362ba1b0a96c01
URL:
https://github.com/llvm/llvm-project/commit/b81c5070d5451af127b2c9c2ae362ba1b0a96c01
DIFF:
https://github.com/llvm/llvm-project/commit/b81c5070d5451af127b2c9c2ae362ba1b0a96c01.diff
L
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
@@ -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::
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
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
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 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:
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/3] [flang] Add -rtlib flag
This patch allows the -rtlib flag w
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 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
https://github.com/DavidTruby created
https://github.com/llvm/llvm-project/pull/89938
This patch changes the behaviour for flang to only create and link to a
`main` entry point when the Fortran code has a program statement in it.
This means that flang-new can be used to link even when the progr
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/89938
___
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/89938
>From 88db34e906f6eb104f8d84fa9ad4f0aa49607c68 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 24 Apr 2024 14:35:23 +
Subject: [PATCH 1/2] [flang] Generate main only when a Fortran program
statement
DavidTruby wrote:
> Great work David, thanks! Could you add some documentation explaining _where_
> `main` would be coming from in the case of mixed-source compilation? In fact,
> is that tested anywhere?
>
> Also, IMHO it would be good to advertise this on Discourse (thinking
> specifically
DavidTruby wrote:
As regards the backwards compatibility break here, I guess my take is that this
change needs to happen some time and sooner is always going to be better than
later. While we are still called flang-new and marked experimental I'm inclined
to think we should just rip the band a
https://github.com/DavidTruby updated
https://github.com/llvm/llvm-project/pull/89938
>From 2b7ee836b985ee6fa8f7d57ccdee733f261a1de1 Mon Sep 17 00:00:00 2001
From: David Truby
Date: Wed, 24 Apr 2024 14:35:23 +
Subject: [PATCH 1/3] [flang] Generate main only when a Fortran program
statement
https://github.com/DavidTruby closed
https://github.com/llvm/llvm-project/pull/89938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 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
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 (
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 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:
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 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
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
Author: David Truby
Date: 2021-01-12T19:44:01Z
New Revision: e5f51fdd650c6d20c81fedb8e856e9858aa10991
URL:
https://github.com/llvm/llvm-project/commit/e5f51fdd650c6d20c81fedb8e856e9858aa10991
DIFF:
https://github.com/llvm/llvm-project/commit/e5f51fdd650c6d20c81fedb8e856e9858aa10991.diff
LOG: [
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
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
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 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 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
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
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
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
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.
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
@@ -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, 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
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:
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:
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
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
@@ -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 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
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 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
@@ -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
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
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
___
@@ -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 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
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
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.
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
___
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
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
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:
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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
`
@@ -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 =
+ TCArgs[{TC, BoundArch, DeviceOffloa
@@ -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
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
@@ -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
@@ -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
@@ -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
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,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,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
///
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
__
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
___
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:
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:
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
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:
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
101 - 200 of 246 matches
Mail list logo
