@@ -2958,6 +2958,8 @@ defm clangir : BoolFOption<"clangir",
BothFlags<[], [ClangOption, CC1Option], "">>;
def emit_cir : Flag<["-"], "emit-cir">, Visibility<[ClangOption, CC1Option]>,
Group, HelpText<"Build ASTs and then lower to ClangIR">;
+def emit_cir_mlir : Flag<["-"],
https://github.com/banach-space approved this pull request.
About time :) Thank you, LGTM!
https://github.com/llvm/llvm-project/pull/119624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
banach-space wrote:
I'm not active in this area, so removed myself from the list of reviewers.
https://github.com/llvm/llvm-project/pull/118008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
@@ -5572,7 +5572,8 @@ def : Flag<["-"], "nocudalib">, Alias;
def gpulibc : Flag<["-"], "gpulibc">, Visibility<[ClangOption, CC1Option,
FlangOption, FC1Option]>,
HelpText<"Link the LLVM C Library for GPUs">;
def nogpulibc : Flag<["-"], "nogpulibc">, Visibility<[ClangOption, C
https://github.com/banach-space approved this pull request.
LGTM, thank you for all the detective work!
https://github.com/llvm/llvm-project/pull/117563
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -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
@@ -0,0 +1,34 @@
+! REQUIRES: arm-registered-target
+
+! RUN: %flang --target=arm-linux-gnu --print-supported-extensions 2>&1 \
+! RUN: | FileCheck --strict-whitespace --implicit-check-not=FEAT_ %s
+
+! CHECK: All available -march extensions for ARM
banach-space
@@ -0,0 +1,10 @@
+! Test that --print-supported-extensions errors on unsupported architectures.
+
+! REQUIRES: x86-registered-target
+
+! RUN: not %flang --target=x86_64-linux-gnu --print-supported-extensions \
+! RUN: 2>&1 | FileCheck %s
banach-space wrote:
Th
banach-space wrote:
> flang -E is already consistent here, it always produces fixed form output.
It would be good to document and to test that - perhaps that's already the case?
> So I think we can just teach flang -fc1 that '.i'
Agreed, and this should be trivial to implement. Thanks @DavidT
banach-space wrote:
> However, -save-temps doesn't appear to work for me at all.
You need to add -fno-integrated-as. This is a known limitation:
*
[save-temps.f90](https://github.com/llvm/llvm-project/blob/main/flang/test/Driver/save-temps.f90)
>It feels wrong that -save-temps runs the prepro
@@ -0,0 +1,34 @@
+! REQUIRES: arm-registered-target
+
+! RUN: %flang --target=arm-linux-gnu --print-supported-extensions 2>&1 \
+! RUN: | FileCheck --strict-whitespace --implicit-check-not=FEAT_ %s
+
+! CHECK: All available -march extensions for ARM
banach-space
https://github.com/banach-space commented:
Thanks, just a couple of questions.
https://github.com/llvm/llvm-project/pull/117402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,34 @@
+! REQUIRES: arm-registered-target
+
+! RUN: %flang --target=arm-linux-gnu --print-supported-extensions 2>&1 \
+! RUN: | FileCheck --strict-whitespace --implicit-check-not=FEAT_ %s
+
+! CHECK: All available -march extensions for ARM
banach-space
@@ -0,0 +1,10 @@
+! Test that --print-supported-extensions errors on unsupported architectures.
+
+! REQUIRES: x86-registered-target
+
+! RUN: not %flang --target=x86_64-linux-gnu --print-supported-extensions \
+! RUN: 2>&1 | FileCheck %s
banach-space wrote:
As
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/117402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
Adding new types to
[Types.def](https://github.com/llvm/llvm-project/pull/117563/files#diff-b2abf750cadedc6109158e6f82b66abfaabd7c7c86c650d2a5163dc3e5fc44a7)
is a fairly huge design update. I'm not saying this is approach is incorrect,
but it definitely deserves a bit of d
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/117199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,43 @@
+! Test --print-supported-cpus and associated aliases, -mcpu=help and
+! -mtune=help
+
+! RUN: %if x86-registered-target %{ \
+! RUN: %flang --target=x86_64-unknown-linux-gnu --print-supported-cpus 2>&1 \
+! RUN: | FileCheck %s --check-prefixes=X86,CHECK \
+
https://github.com/banach-space approved this pull request.
LGTM, my final comment is nit - feel free to ignore. Thanks!
https://github.com/llvm/llvm-project/pull/117199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
@@ -5899,8 +5899,10 @@ def print_enabled_extensions : Flag<["-", "--"],
"print-enabled-extensions">,
HelpText<"Print the extensions enabled by the given target and -march/-mcpu
options."
" (AArch64 and RISC-V only)">,
MarshallingInfoFlag>;
-def : Flag<["-"], "m
@@ -4417,7 +4417,8 @@ void Driver::BuildActions(Compilation &C, DerivedArgList
&Args,
// Use the -mcpu=? flag as the dummy input to cc1.
Actions.clear();
- Action *InputAc = C.MakeAction(*A, types::TY_C);
+ Action *InputAc = C.MakeAction(
+ *A,
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/117199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space commented:
Thanks, makes sense. From what I can tell, the behaviour is consistent with
Clang (i.e. `-print-supported-cpus` invalidates any other action flags).
Just a couple of smallish comments/suggestions
https://github.com/llvm/llvm-project/pull/117199
__
banach-space wrote:
> Notes for reviewers: The corresponding test in
> clang/test/Driver/print-supported-cpus.c tests two different architectures in
> the same file. This has been split into two separate tests here to allow the
> test to be run in cases where only one of the targets has been b
https://github.com/banach-space approved this pull request.
LGTM, thanks!
I blame my editor's dictionary 😂
https://github.com/llvm/llvm-project/pull/112899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -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
+(CMake 3.28.0), `cmake` can detect `flang
banach-space wrote:
We should avoid dummy flags like this - they are usually an indication of a
larger issue.
I don't want to block this and, as @Meinersbur points out, there are some
"inherited issues" to consider too. However, I'd like to identify the right
long-term solution here. If poss
https://github.com/banach-space closed
https://github.com/llvm/llvm-project/pull/74377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
Closing in favour of #110023
https://github.com/llvm/llvm-project/pull/74377
___
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), `
https://github.com/banach-space approved this pull request.
LGTM, thanks!
Looks like you've addressed all comments, so feel free to land it.
https://github.com/llvm/llvm-project/pull/109965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
banach-space wrote:
Having multiple active PR's for one change is IMHO rather confusing. It creates
unnecessary duplication - why do we expect people to review the same change
twice? As a case in point:
> Since we are making this change now, should this PR be updated to follow
> clang's schem
@@ -79,7 +79,17 @@ TYPE("c++-module-cpp-output",PP_CXXModule, INVALID,
"iim",phases
TYPE("ada", Ada, INVALID, nullptr,
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
TYPE("assembler",PP_A
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/104664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/104664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space commented:
What's the end goal here? To add an option for every possible bit-width? If
yes, then these options should take bit width as parameters.
Btw, does GFortran implement anything like this? If yes, are you making sure
that the semantics in Flang are consi
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/107087
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -79,7 +79,14 @@ TYPE("c++-module-cpp-output",PP_CXXModule, INVALID,
"iim",phases
TYPE("ada", Ada, INVALID, nullptr,
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
TYPE("assembler",PP_A
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/104664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space commented:
Thanks for the updates, some minor suggestions inline.
https://github.com/llvm/llvm-project/pull/104664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/106141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
Approving with the caveat that we should avoid leveraging LLVM options like
this and that long-term this should be refactored as a dedicated, first-class
driver option. This can be implemented in a seperate PR.
Thank you for the discu
banach-space wrote:
Apologies for the delay, I am OOO 😅
I've had another look and I think that I better understand what the issue is.
It is important to distinguish two input types that we are dealing with here:
* `-x f95-cpp-input` - Fortran input _before_ pre-processing,
* `-x f95` - Fortran
banach-space wrote:
For context, this PR documents the origins of .i in the context of `flang-new`:
*
https://github.com/llvm/llvm-project/commit/a65afce731c2fa91effcfa5d4917d6ad90a28bf0
If these files are already pre-processed, why would we add `phases::Preprocess`
to the list of compilation
banach-space wrote:
Hi Kareem, thanks for the fix! Is there any reference that would document .i
files? Perhaps GFortran docs? This might be sth standard, but we should capture
that in our docs nonetheless (eg in a commit summary).
Btw, I will be OOO for a while, so apologies in advance if th
https://github.com/banach-space approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/104613
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12,4 +13,8 @@ program main
! CHECK: INTEGER :: var = 1
! CHECK: INTEGER, DEVICE :: dvar
-! ERROR: cuda-option.f90:8:19: error: expected end of statement
+! ERROR: cuda-option.f90:{{.*}}:{{.*}}: error: expected end of statement
+
+! The whole pipeline is not in place yet. I
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/104613
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/101682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
Thanks for addressing my feedback, LGTM
https://github.com/llvm/llvm-project/pull/100152
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -492,6 +493,18 @@ void Flang::addOffloadOptions(Compilation &C, const
InputInfoList &Inputs,
if (Args.hasArg(options::OPT_nogpulib))
CmdArgs.push_back("-nogpulib");
}
+
+ // For all the host OpenMP offloading compile jobs we need to pass the
targets
+ // info
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/96742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
> > > > Who could be the right person to ask?
> > >
> > >
> > > I don't know. Open-source LLVM Flang meetings can be good place to ask
> > > this question.
> >
> >
> > Did you ask? What feedback did you get?
>
> @banach-space I asked question on flang-slack, I mentioned
banach-space wrote:
Given the growing number of OpenMP and/or "offloading" flags, I agree with
@AnastasiaStulova that it would be good to clarify the overall goal/design.
That's not clear to me.
Is there are reference implementation that Flang is meant to follow? For
example Clang or GFortra
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/100343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -492,6 +493,18 @@ void Flang::addOffloadOptions(Compilation &C, const
InputInfoList &Inputs,
if (Args.hasArg(options::OPT_nogpulib))
CmdArgs.push_back("-nogpulib");
}
+
+ // For all the host OpenMP offloading compile jobs we need to pass the
targets
+ // info
https://github.com/banach-space approved this pull request.
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/banach-space closed
https://github.com/llvm/llvm-project/pull/98517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/98517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
The driver logic makes sense, thank you! LGTM
https://github.com/llvm/llvm-project/pull/98083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -333,6 +333,9 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
StringRef Val = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-mcode-object-version=" + Val));
}
+
+ const ToolChain &TC = getToolChain();
+ TC.addClangTargetOptions(Args, CmdArgs, Actio
@@ -8024,7 +8024,7 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
// CUDA Options
//===--===//
-let Visibility = [CC1Option] in {
+let Visibility = [CC1Option, FC1Option] in {
-
banach-space wrote:
> Would it be possible for you to investigate that? It really shouldn't be
> required if we can't help it.
+1
https://github.com/llvm/llvm-project/pull/96742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
banach-space wrote:
I have X86 disabled - I just double checked. And yes, this test works for me
just fine without the guard. Alexis, what error do you get when it fails for
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
banach-space wrote:
Hm, ninja `check-mlir` worked for me just fine on Aarch64 🤔 I think that
`mlir-translate` doesn't really care :) Put differently, `REQUIRES` is not
neede
banach-space wrote:
> Clang for AMDGPU supports OpenMP and
> [HIP](https://clang.llvm.org/docs/HIPSupport.html) and it reuses the same
> code. For example `-fcuda-is-device` flag needs to be checked for [legacy HIP
> host
> code](https://github.com/llvm/llvm-project/blob/2033b1cf16f040e1369d8
@@ -333,6 +333,9 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
StringRef Val = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-mcode-object-version=" + Val));
}
+
+ const ToolChain &TC = getToolChain();
+ TC.addClangTargetOptions(Args, CmdArgs, Actio
@@ -333,6 +333,9 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
StringRef Val = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-mcode-object-version=" + Val));
}
+
+ const ToolChain &TC = getToolChain();
+ TC.addClangTargetOptions(Args, CmdArgs, Actio
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/96742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space commented:
> fcuda-is-device flag is not used by Flang currently. In the future it will be
> needed for Flang equivalent functions:
> AMDGPUTargetCodeGenInfo::getGlobalVarAddressSpace
> AMDGPUTargetInfo::getTargetDefines .
I don't follow - why would anything re
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/96678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
> LLVM Buildbot has detected a new failure on builder `flang-aarch64-libcxx`
> running on `linaro-flang-aarch64-libcxx` while building `clang,flang,mlir` at
> step 6 "test-build-unified-tree-check-flang".
>
> Full details are available at:
> https://lab.llvm.org/buildbot/#
https://github.com/banach-space closed
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
> if I do so should I also move the target-features-*.f90 tests?
Yes, but to me that would qualify as an "unrelated change" (i.e. sth for a
separate PR, no need to worry about it here).
In general, this PR is about enabling a flag in Flan
https://github.com/banach-space closed
https://github.com/llvm/llvm-project/pull/95708
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/95708
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space approved this pull request.
LGTM, thanks for implementing this 🙏🏻
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
banach-space wrote:
This is probably a border-line case, but I would consider this a "driver"
rather than a "lowering" test. I'm biased though 😅
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailin
banach-space wrote:
> You also need to remove the use of this pass (for testing purposes) from
> clang-tools-extra.
Done, thanks!
I don't understand why CI still fails:
```bash
Total Discovered Tests: 60135
--
| Skipped :15 (0.02%)
| Unsupported : 1005 (1.67%)
| Passed
https://github.com/banach-space updated
https://github.com/llvm/llvm-project/pull/95708
From d75a05030447e8bcb1dd0b575ff5e7aa5c89f0bb Mon Sep 17 00:00:00 2001
From: Andrzej Warzynski
Date: Sun, 16 Jun 2024 13:58:41 +0100
Subject: [PATCH 1/3] [llvm] Remove the Legacy PM Hello example
The Legacy
@@ -0,0 +1,16 @@
+! RUN: %flang_fc1 -triple aarch64 -emit-llvm -mcmodel=tiny %s -o - | FileCheck
%s -check-prefix=CHECK-TINY
banach-space wrote:
[nit] IMHO, using `CHECK` for prefixes in a test with multiple prefixes is just
noise. Why not drop `CHECK`?
https:
https://github.com/banach-space approved this pull request.
The high-level stuff makes sense to me, thanks! I'm not familiar with
`-mcmodel`, so can't tell for sure whether the tests are correct 😅 Ideally one
more person would take a look - @tblah or @pawosm-arm ?
https://github.com/llvm/llvm
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/95411
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2823,3 +2823,84 @@ void tools::addOffloadCompressArgs(const
llvm::opt::ArgList &TCArgs,
CmdArgs.push_back(
TCArgs.MakeArgString(Twine("-compression-level=") + Arg->getValue()));
}
+
+void tools::addMCModel(const Driver &D, const llvm::opt::ArgList &Args,
--
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/94763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -32,6 +32,9 @@ class TargetOptions {
/// If given, the name of the target CPU to generate code for.
std::string cpu;
+ /// If given, the name of the target CPU to tune code for.
+ std::string tuneCPU;
banach-space wrote:
I'm fine with longer self-doc
https://github.com/banach-space commented:
Thanks for working on this @AlexisPerry ! Could you add some tests?
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1146,6 +1150,54 @@ void CodeGenAction::embedOffloadObjects() {
}
}
+void CodeGenAction::linkBuiltinBCLibs() {
banach-space wrote:
+1
https://github.com/llvm/llvm-project/pull/94763
___
cfe-commits mailing lis
@@ -0,0 +1,18 @@
+
+!--
+! RUN lines
+!--
+! Embed something that can be easily checked
+! RUN: %flang_fc1 -emit-llvm -triple x86_64-unknown-linux-gnu -o -
-mlink-builtin-bitcode %S/Inputs/bclib.bc %s 2>&1 | FileCheck %s
+
+! CHECK: define internal void @libfun_
+
@@ -0,0 +1,18 @@
+
+!--
+! RUN lines
+!--
+! Embed something that can be easily checked
+! RUN: %flang_fc1 -emit-llvm -triple x86_64-unknown-linux-gnu -o -
-mlink-builtin-bitcode %S/Inputs/bclib.bc %s 2>&1 | FileCheck %s
banach-space wrote:
1. Wh
@@ -0,0 +1,18 @@
+
+!--
+! RUN lines
+!--
banach-space wrote:
In the past, folks asked not to add such comments in tests. Let's stick with
that.
https://github.com/llvm/llvm-project/pull/94763
___
cfe-
@@ -0,0 +1,18 @@
+
+!--
+! RUN lines
+!--
+! Embed something that can be easily checked
+! RUN: %flang_fc1 -emit-llvm -triple x86_64-unknown-linux-gnu -o -
-mlink-builtin-bitcode %S/Inputs/bclib.bc %s 2>&1 | FileCheck %s
+
+! CHECK: define internal void @libfun_
+
https://github.com/banach-space approved this pull request.
https://github.com/llvm/llvm-project/pull/94359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
Should be fixed by https://github.com/llvm/llvm-project/pull/93794
https://github.com/llvm/llvm-project/pull/92338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
Hi, thanks for this contribution. Sadly, it messes up my local checkout on
MacOS (which is insensitive when it comes to files names). These files are
problematic:
* "asm-constraint-jR.ll" and "asm-constraint-jr.ll"
Please, could you rename them so that they are not identica
banach-space 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 👍
That's matches how I read that suggestion re
`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`, thanks!
https://github.com/banach-space approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/91660
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
Thank you for this contribution Paul!
> Many autotools-utilizing projects (mpich among them) fail to complete the
> configure step since it tries to invoke the (unknown to them) Fortran
> compiler always with the -fallow-argument-mismatch flag.
It sounds like an issue with
banach-space wrote:
[nit] Once you have more than one prefix, `CHECK` becomes noise. At least IMHO
😅 (we all know that these are "check" lines). You could use more descriptive
prefixes instead, e.g. `CHECK-PORT` -> `PORTABILITY` (it wasn't obvious to me
that
1 - 100 of 358 matches
Mail list logo
