vgvassilev wrote:
Oh, understood. Perhaps would be better if you move it. I am currently on
vacation for a while…
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
steakhal wrote:
> Do you mean the documentation? If so, yes, that’s probably not the right
> place. I am on my phone but can you suggest a place where we should move this
> or just move it? I think that was an oversight.
Thanks. There is nothing urgent. I was just preparing a PR for syncing th
vgvassilev wrote:
Do you mean the documentation? If so, yes, that’s probably not the right place.
I am on my phone but can you suggest a place where we should move this or just
move it? I think that was an oversight.
https://github.com/llvm/llvm-project/pull/79261
steakhal wrote:
@vgvassilev It appears that this PR added an entry to the Static Analyzer
section, and I'm not sure if that's the right one.
Could you please suggest an alternative section where I should move it?
https://github.com/llvm/llvm-project/pull/79261
__
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
https://github.com/ChuanqiXu9 commented:
This is what I had in mind
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nathanchance wrote:
> But due to I can't reproduce the failure, @nathanchance would you like to
> make this? I don't want to make something that I can't test.
I don't mind submitting something if I have some guidance around how this
should be handled (I am a little lost in this thread at the m
vgvassilev wrote:
> > > > IncrementalExtensions
> > >
> > >
> > > But the change itself is to make `IncrementalExtensions` a compatible
> > > lang options. So that we don't need to specify it when generating the
> > > modules.
> >
> >
> > I mean conditionally if `IncrementalExtensions` is s
ChuanqiXu9 wrote:
> > > IncrementalExtensions
> >
> >
> > But the change itself is to make `IncrementalExtensions` a compatible lang
> > options. So that we don't need to specify it when generating the modules.
>
> I mean conditionally if `IncrementalExtensions` is set we change the target
>
vgvassilev wrote:
> > IncrementalExtensions
>
> But the change itself is to make `IncrementalExtensions` a compatible lang
> options. So that we don't need to specify it when generating the modules.
I mean conditionally if `IncrementalExtensions` is set we change the target
triple in the clan
ChuanqiXu9 wrote:
I am wondering if it helps if we specify the target triple in the test, then it
won't be so troublesome.
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
ChuanqiXu9 wrote:
> IncrementalExtensions
But the change itself is to make `IncrementalExtensions` a compatible lang
options. So that we don't need to specify it when generating the modules.
https://github.com/llvm/llvm-project/pull/79261
___
cfe-com
vgvassilev wrote:
We have a `LangOption` called `IncrementalExtensions`. We might be able to use
it there.
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
nikic wrote:
> Until this change we sailed fairly well. It seems that the pcm rigorously
> records the clang notion of the triple which is probably what we want.
> However, if we are building a pcm in the context of `clang-repl` would it
> make sense to use the `getProcessTriple` notion for th
vgvassilev wrote:
@nikic, thanks for the details!
Until this change we sailed fairly well with that change. It seems that the pcm
rigorously records the clang notion of the triple which is probably what we
want. However, if we are building a pcm in the context of `clang-repl` would it
make s
nikic wrote:
Normal clang creates a driver using the default target triple here:
https://github.com/llvm/llvm-project/blob/754a8add57098ef71e4a51a9caa0cc175e94377d/clang/tools/driver/driver.cpp#L485
clang-repl appears to use IncrementalCompilerBuilder, which uses
`getProcessTriple()` here:
ht
nathanchance wrote:
@vgvassilev Yes, it appears so, I tried one of the examples from [the
documentation](https://clang.llvm.org/docs/ClangRepl.html) since I have no
prior experience with `clang-repl`.
```
$ clang-repl --version
LLVM (http://llvm.org/):
LLVM version 19.0.0git
Optimized buil
vgvassilev wrote:
We pass the CompilerInstance's notion of the target triple this commit explains
it:
https://github.com/llvm/llvm-project/commit/49f9532165f0cc0485a7da84662ebf63d155652c
@nathanchance, can `clang-repl` be run on your setup? If the Jit is happy about
the target triple and we c
nathanchance wrote:
This is out of my wheelhouse to debug to be honest but it seems to me that
`clang-repl` does not respect `LLVM_DEFAULT_TARGET_TRIPLE` somehow? This test
does the same thing as other tests to build modules but this appears to be the
only one that uses `clang-repl` to consume
ChuanqiXu9 wrote:
It looks true but the test does the same thing as other tests to build modules
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
vgvassilev wrote:
Perhaps we are not propagating the correct triple down to the module build
action?
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
ChuanqiXu9 wrote:
> For what it's worth, this test appears to fail when
> `LLVM_DEFAULT_TARGET_TRIPLE` is changed (my script sets it to the output of
> my Linux distribution's `clang -print-target-triple`)
>
> ```
> error: PCH file was compiled for the target 'x86_64-pc-linux-gnu' but the
> c
nathanchance wrote:
For what it's worth, this test appears to fail when
`LLVM_DEFAULT_TARGET_TRIPLE` is changed (my script sets it to the output of my
Linux distribution's `clang -print-target-triple`)
```
error: PCH file was compiled for the target 'x86_64-pc-linux-gnu' but the
current trans
ChuanqiXu9 wrote:
> Hi @ChuanqiXu9, the test you added is failing on the PS4 bot because for the
> PS4 target, it requires an external linker which is not present/available.
> Can the test be rewritten to not require linking?
>
> https://lab.llvm.org/buildbot/#/builders/139/builds/57928
>
> `
dyung wrote:
Hi @ChuanqiXu9, the test you added is failing on the PS4 bot because for the
PS4 target, it requires an external linker which is not present/available. Can
the test be rewritten to not require linking?
https://lab.llvm.org/buildbot/#/builders/139/builds/57928
```
clang: error: una
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/vgvassilev approved this pull request.
Lgtm! Thank you @ChuanqiXu9!
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang-modules
Author: Chuanqi Xu (ChuanqiXu9)
Changes
This comes from when I playing around clang-repl with moduels : )
I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling
`std::printf` after this patch.
I want to put the d
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/79261
This comes from when I playing around clang-repl with moduels : )
I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling
`std::printf` after this patch.
I want to put the documentati
34 matches
Mail list logo