glandium wrote:
Weirdly, this leads to `warning: argument unused during compilation: '-nopie'`
rather than `error: unknown argument: '-nopie'`
https://github.com/llvm/llvm-project/pull/72578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
glandium wrote:
This broke the wasi-threads target:
`clang: error: version 'threads' in target triple 'wasm32-unknown-wasi-threads'
is invalid`
https://github.com/llvm/llvm-project/pull/78655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
glandium wrote:
We stumbled upon this downstream because we have jobs building wasi-sdk with
clang-trunk, and wasi-sdk builds some things with that target. It apparently
comes from https://github.com/WebAssembly/wasi-libc/pull/381
https://github.com/llvm/llvm-project/pull/78655
___
glandium wrote:
There's apparently also wasm32-wasi-preview2 and wasm32-wasi-pthread, which I
suppose are equally broken by this change.
https://github.com/llvm/llvm-project/pull/78655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
glandium wrote:
> Yes, I think so. I think adding these environment types in wasi-libc repo
> could help fix those errors.
WDYM?
https://github.com/llvm/llvm-project/pull/78655
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
@@ -1443,16 +1443,18 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
const ToolChain &TC = getToolChain(
*UArgs, computeTargetTriple(*this, TargetTriple, *UArgs));
- // Check if the environment version is valid.
- llvm::Triple Triple = TC.getTriple();
-
glandium wrote:
> It looks like this breaks building at least `MultiSource` from
> https://github.com/llvm/llvm-test-suite/. The first failure I see is when
> building `llvm-test-suite/MultiSource/Applications/ClamAV/zlib_zutil.c`
>
> ```
> In file included from
> /llvm-test-suite/MultiSource
glandium wrote:
> We have provided a fix for zlib
> ([madler/zlib#895](https://github.com/madler/zlib/pull/895)) which was
> accepted by @madler.
But nowhere released, not even in the repository :(
https://github.com/llvm/llvm-project/pull/74676
___
glandium wrote:
This broke building wasi-libc, with a crash:
```
Stack dump:
0. Program arguments: /builds/worker/fetches/clang/bin/clang-19 -cc1
-triple wasm32-unknown-wasi -emit-obj -disable-free -clear-ast-before-backend
-disable-llvm-verifier -discard-value-names -main-file-name ctanh.
glandium wrote:
This also breaks building the compiler-rt for older android versions, because
pthread_spinlock_t is only defined when __ANDROID_API__ >= 24.
https://github.com/llvm/llvm-project/pull/92460
___
cfe-commits mailing list
cfe-commits@lists
glandium wrote:
This broke building abseil-cpp (cd75cb4ae32c46c84cef9a9c78b42174f22ed0ac as of
writing).
STR:
- Clone https://github.com/abseil/abseil-cpp
- `cmake -B build -S abseil-cpp -DCMAKE_CXX_COMPILER=clang++ -GNinja`
- `ninja -C build`
https://github.com/llvm/llvm-project/pull/98547
__
glandium wrote:
Well, I guess this is working as intended, as adding `template` before
`StorageT` fixes it.
https://github.com/llvm/llvm-project/pull/98547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
glandium wrote:
The sad part is that MSVC and some old versions of GCC don't like `template`
being added here :(
https://github.com/llvm/llvm-project/pull/98547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
glandium wrote:
This caused some breakage in something completely unrelated to operator= O_o
This is from webrtc code in Firefox:
```
/tmp/gecko/third_party/libwebrtc/rtc_base/containers/flat_map.h:331:49: error:
out-of-line definition of 'try_emplace' does not match any declaration in
'flat_m
glandium wrote:
Reverting just the SemaTemplate.cpp change fixes it.
https://github.com/llvm/llvm-project/pull/91498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
This broke building clang on Windows with PGO:
```
FAILED: bin/clang-repl.exe lib/clang-repl.lib
cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E
__create_def
D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-r
glandium wrote:
What kind of detail are you looking for?
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
> Mainly about the commands of cmake building.
However you build clang on windows using clang, with the addition of
-DLLVM_BUILD_INSTRUMENTED=IR -DLLVM_BUILD_RUNTIME=No
> Does this failure bind to a buildbot?
I have no idea, but probably not, otherwise you'd have heard from it
glandium wrote:
There is something wrong going on with cmake:
STR:
- Download
[testcase.zip](https://github.com/user-attachments/files/15597940/testcase.zip)
- Unzip it (it contains ClangRepl.cpp.obj and exports.def.objs)
- Run `cmake -E __create_def exports.def exports.def.objs --nm=/path/to/ll
glandium wrote:
Filed https://gitlab.kitware.com/cmake/cmake/-/issues/26031
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
Yes
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
This unveiled an interesting problem in our builds: `llvm-config --cxxflags`
doesn't include the `/MT`/`/MD` flag, so when building something that links
with one of the .lib from LLVM, you can end up with a failure because you're
not building with the same flag as LLVM was buil
glandium wrote:
> Which used to be MT and with this change is now MD.
(because our script was still using LLVM_USE_CRT_RELEASE)
https://github.com/llvm/llvm-project/pull/66850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
glandium wrote:
> We (Chrome) no longer need a revert - we patched the NDK locally.
Patching the NDK is not a solution that is nice everywhere, though. And the new
warning is an error that can't be disabled.
https://github.com/llvm/llvm-project/pull/70307
__
glandium wrote:
> > > We (Chrome) no longer need a revert - we patched the NDK locally.
> >
> >
> > Patching the NDK is not a solution that is nice everywhere, though. And the
> > new warning is an error that can't be disabled.
>
> FWIW, we addressed this issue and backported the fix in #1004
glandium wrote:
> and the fix is already applied from looking at
> https://android.googlesource.com/platform/frameworks/native/+/master/libs/nativewindow/include/android/hardware_buffer.h#329
it's not part of any released NDK, and it's common to be stuck with older NDKs.
Most people are probab
26 matches
Mail list logo
