glandium wrote:
For the record, my reduced test case is:
```
namespace camera {
template void GetChildAndCall(MEM_FUN);
struct CamerasChild {
template
void ConnectDeviceListChangeListener(void (This::*)());
};
} // namespace camera
struct MediaEngineWebRTC {
MediaEngineWebRTC();
};
using
glandium wrote:
This causes crashes:
```
1.
/builds/worker/checkouts/gecko/dom/media/webrtc/MediaEngineWebRTC.cpp:48:44:
current parser token ')'
2.
/builds/worker/checkouts/gecko/dom/media/webrtc/MediaEngineWebRTC.cpp:31:1:
parsing namespace 'mozilla'
3.
/builds/worker/checko
glandium wrote:
This had the side effect of adding implicit-int-conversion warnings on e.g. the
following code:
```
unsigned char foo(unsigned char x)
{
return ~x;
}
```
This seems correct, but this should probably be highlighted in the release
notes.
Another example is:
```
unsigned int f
glandium wrote:
Ironically, this and later changes related to LLVM_BUILD_LLVM_DYLIB for Windows
broke LLVM_EXPORT_SYMBOLS_FOR_PLUGINS, which is a currently working way to use
clang plugins on Windows, while LLVM_BUILD_LLVM_DYLIB doesn't work yet.
https://github.com/llvm/llvm-project/pull/1126
glandium wrote:
Should this be uplifted to release/20.x?
Cc: @tstellar
https://github.com/llvm/llvm-project/pull/126952
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -256,6 +256,24 @@ Linux::Linux(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
ExtraOpts.push_back("-z");
ExtraOpts.push_back("max-page-size=16384");
}
+if (Triple.isAndroidVersionLT(29)) {
+ // https://github.com/android/ndk/issue
glandium wrote:
cvise has reduced my testcase to
```
union StyleColorFunctionStyleColorFunction *mRaw {
delete mRaw
```
... which is nowhere close to the real thing and nowhere close to legal C++ at
all.
Well, that definitely shouldn't trigger a crash, though.
https://github.com/llvm/llvm-p
glandium wrote:
I was creducing it (well, cvise-ing). Here's a reproducer:
```
template struct MozPromise {
class Private;
private:
void *mMagic4;
};
template
struct MozPromise::Private
: MozPromise {
void SetTaskPriority() { mMagic4 }
}
```
https://github.com/llvm/llvm-project/pull
glandium wrote:
We're getting a similar crash bisected to this change as well, also with a huge
original file. Funnily enough, a debug build hits an assertion that happens
even without this change, so I'm going to dig into that before even trying to
reduce the crasher.
https://github.com/llvm
glandium wrote:
I found what's going on. It kind of worked by chance before in our setup, but
that somehow shows an existing flaw in the run-clang-tidy script.
So, our compilation database contains absolute paths with forward slashes. And
the paths we pass to the command line are also with forw
glandium wrote:
The change in 315561c86778 causes problems on Windows, and I thought that's
what it was, but it turns out it's not. Sorry for the noise. I'm still digging
as to what exactly is going wrong on our setup.
https://github.com/llvm/llvm-project/pull/118718
__
https://github.com/glandium closed
https://github.com/llvm/llvm-project/pull/118718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
Cc @PiotrZSL @carlosgalvezp @nicovank
https://github.com/llvm/llvm-project/pull/118718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/glandium created
https://github.com/llvm/llvm-project/pull/118718
None
>From fd48f30df81e533401b9eedc313547374c6e5b13 Mon Sep 17 00:00:00 2001
From: Mike Hommey
Date: Thu, 5 Dec 2024 08:52:57 +0900
Subject: [PATCH] Re-add path normalization that was removed in 315561c86778
glandium wrote:
I bisected a bustage building clang with PGO on Windows to this change. While
building clang with a profile-generate-enabled build of clang to gather a
profile, the compiler crashes with:
```
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include
glandium wrote:
Before this change the following (reduced) code didn't emit a warning, but now
does:
```
class __attribute__((capability("mutex"))) StaticMutex {
public:
void Lock() __attribute__((exclusive_lock_function())) { /* unimplemented */
}
void Unlock() __attribute__((unlock_fun
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
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:
> 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:
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:
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:
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:
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 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:
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:
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:
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:
> 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:
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:
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:
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 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
@@ -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:
> 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
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:
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:
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 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:
> 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:
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:
> 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:
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
42 matches
Mail list logo
