[clang] [Driver] Make ELF -nopie specific to OpenBSD (PR #72578)
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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Check the environment version except wasm case. (PR #80783)
@@ -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();
- StringRef TripleVersionName = Triple.getEnvironmentVersionString();
- StringRef TripleObjectFormat =
- Triple.getObjectFormatTypeName(Triple.getObjectFormat());
- if (Triple.getEnvironmentVersion().empty() && TripleVersionName != "" &&
- TripleVersionName != TripleObjectFormat) {
-Diags.Report(diag::err_drv_triple_version_invalid)
-<< TripleVersionName << TC.getTripleString();
-ContainsError = true;
+ // Check if the environment version is valid except wasm case.
+ if (!TC.getTriple().isWasm()) {
+llvm::Triple Triple = TC.getTriple();
glandium wrote:
You could do
```
llvm::Triple Triple = TC.getTriple();
if (!Triple.isWasm()) {
```
https://github.com/llvm/llvm-project/pull/80783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[compiler-rt] [flang] [llvm] [openmp] [libc] [lldb] [mlir] [libcxx] [clang-tools-extra] [clang] [lld] [Driver] Report invalid target triple versions for all environment types. (PR #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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [openmp] [compiler-rt] [llvm] [libcxx] [lldb] [lld] [clang] [flang] [libc] [mlir] [Driver] Report invalid target triple versions for all environment types. (PR #78655)
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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[compiler-rt] [openmp] [clang] [lldb] [mlir] [llvm] [libcxx] [flang] [libc] [lld] [clang-tools-extra] [Driver] Report invalid target triple versions for all environment types. (PR #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://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[compiler-rt] [mlir] [clang] [libc] [flang] [clang-tools-extra] [lld] [openmp] [lldb] [llvm] [libcxx] [Driver] Report invalid target triple versions for all environment types. (PR #78655)
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.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][PP] Add extension to predefine target OS macros (PR #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/Applications/ClamAV/zlib_zutil.c:10:
> In file included from
> test-suites/llvm-test-suite/MultiSource/Applications/ClamAV/zlib/gzguts.h:21:
> ../usr/include/stdio.h:220:7: error: expected identifier or '('
> 220 | FILE*fdopen(int, const char *)
> __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_2_0, __DARWIN_ALIAS(fdopen));
> | ^
> llvm-test-suite/MultiSource/Applications/ClamAV/zlib/zutil.h:140:33: note:
> expanded from macro 'fdopen'
> 140 | #define fdopen(fd,mode) NULL /* No fdopen() */
> | ^
> llvm-project/builds/release-with-assertions/ccache-stage1/lib/clang/18/include/__stddef_null.h:26:16:
> note: expanded from macro 'NULL'
>26 | #define NULL ((void*)0)
> |^
> ```
These are actually part of zlib, so apart from llvm test suite having been
broken by this (but was fixed), plain zlib has been broken too (although
arguably, zlib is where the real issue is).
https://github.com/llvm/llvm-project/pull/74676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)
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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake]Fully delete the deprecated LLVM_USE_CRT* (PR #66850)
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 built with. Which used to be MT and with this change is now MD. https://github.com/llvm/llvm-project/pull/66850 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake]Fully delete the deprecated LLVM_USE_CRT* (PR #66850)
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.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Add flag to suppress overflow errors in C++ constant expressions. (PR #102390)
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 probably using the compiler that comes with the NDK, but Mozilla doesn't. Well, I guess we can just patch our clang to make this a non-error on Android targets or something. https://github.com/llvm/llvm-project/pull/102390 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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 already. 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
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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/llvm-nm` When running this with cmake on Windows, taking one of the symbols the lld-link was saying were missing: ``` __profc_??$_Emplace_reallocate DATA __profd_??$_Emplace_reallocate DATA __profvp_??$_Emplace_reallocate DATA ??$_Emplace_reallocate@AEBI@?$vector@IV?$allocator@I@std@@@std@@AEAAPEAIQEAIAEBI@Z ??$_Emplace_reallocate@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@AEAAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@QEAV21@AEBV21@@Z ??$_Emplace_reallocate@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@?$vector@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@V?$allocator@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@std@@@std@@AEAAPEAU?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@QEAU234@$$QEAU234@@Z ??$_Emplace_reallocate@UCompletion@LineEditor@llvm@@@?$vector@UCompletion@LineEditor@llvm@@V?$allocator@UCompletion@LineEditor@llvm@@@std@@@std@@AEAAPEAUCompletion@LineEditor@llvm@@QEAU234@$$QEAU234@@Z ??$_Emplace_reallocate@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@@?$vector@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@V?$allocator@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@@2@@std@@AEAAPEAV?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@1@QEAV21@$$QEAV21@@Z ``` Doing the same on Linux: ``` __profc_??$_Emplace_reallocate@AEBI@?$vector@IV?$allocator@I@std@@@std@@AEAAPEAIQEAIAEBI@Z.140565309351188016 DATA __profc_??$_Emplace_reallocate@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@AEAAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@QEAV21@AEBV21@@Z.166520529307557042 DATA __profc_??$_Emplace_reallocate@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@?$vector@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@V?$allocator@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@std@@@std@@AEAAPEAU?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@QEAU234@$$QEAU234@@Z.940266886021390796 DATA __profc_??$_Emplace_reallocate@UCompletion@LineEditor@llvm@@@?$vector@UCompletion@LineEditor@llvm@@V?$allocator@UCompletion@LineEditor@llvm@@@std@@@std@@AEAAPEAUCompletion@LineEditor@llvm@@QEAU234@$$QEAU234@@Z.928018419188693000 DATA __profc_??$_Emplace_reallocate@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@@?$vector@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@V?$allocator@V?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@std@@@2@@std@@AEAAPEAV?$unique_ptr@VErrorInfoBase@llvm@@U?$default_delete@VErrorInfoBase@llvm@@@std@@@1@QEAV21@$$QEAV21@@Z.1073799611620789089 DATA __profd_??$_Emplace_reallocate@AEBI@?$vector@IV?$allocator@I@std@@@std@@AEAAPEAIQEAIAEBI@Z.140565309351188016 DATA __profd_??$_Emplace_reallocate@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@AEAAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@QEAV21@AEBV21@@Z.166520529307557042 DATA __profd_??$_Emplace_reallocate@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@?$vector@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@V?$allocator@U?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@@std@@@std@@AEAAPEAU?$OptionValue@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@cl@llvm@@QEAU234@$$QEAU234@@Z.940266886021390796 DATA __profd_??$_Emplace_reallocate@UCompletion@LineEditor@llvm@@@?$vector@UCompletion@LineEditor@llvm@@V?$allocator@UCompletion@LineEditor@llvm@@@std@@@std@@AEAAPEAUCompletion@LineEditor@llvm@@QEAU
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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
[clang] [llvm] [clang] Reland Add tanf16 builtin and support for tan constrained intrinsic (PR #94559)
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.c -mrelocation-model static -mthread-model single -mframe-pointer=none -ffp-contract=on -fno-rounding-math -ffp-exception-behavior=ignore -mconstructor-aliases -target-cpu generic -fvisibility=hidden -debugger-tuning=gdb -fdebug-compilation-dir=/builds/worker/fetches/wasi-sdk/src/wasi-libc -fcoverage-compilation-dir=/builds/worker/fetches/wasi-sdk/src/wasi-libc -sys-header-deps -D NDEBUG -O2 -Wall -Wextra -Wno-null-pointer-arithmetic -Wno-unused-parameter -Wno-sign-compare -Wno-unused-variable -Wno-unused-function -Wno-ignored-attributes -Wno-missing-braces -Wno-ignored-pragmas -Wno-unused-but-set-variable -Wno-unknown-warning-option -Wno-parentheses -Wno-shift-op-parentheses -Wno-bitwise-op-parentheses -Wno-logical-op-parentheses -Wno-string-plus-int -Wno-dangling-else -Wno-unknown-pragmas -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -vectorize-loops -vectorize-slp -x c ctanh-46a6c8.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'ctanh-46a6c8.c'. 4. Running pass 'WebAssembly Assembly Printer' on function '@ctanh' #0 0x7f2205ba35cd llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /tmp/llvm/llvm/lib/Support/Unix/Signals.inc:723:11 #1 0x7f2205ba3abb PrintStackTraceSignalHandler(void*) /tmp/llvm/llvm/lib/Support/Unix/Signals.inc:798:1 #2 0x7f2205ba1b26 llvm::sys::RunSignalHandlers() /tmp/llvm/llvm/lib/Support/Signals.cpp:105:5 #3 0x7f2205ba4275 SignalHandler(int) /tmp/llvm/llvm/lib/Support/Unix/Signals.inc:413:1 #4 0x7f2203ff4f90 (/lib/x86_64-linux-gnu/libc.so.6+0x3bf90) #5 0x7f2204043ccc (/lib/x86_64-linux-gnu/libc.so.6+0x8accc) #6 0x7f2203ff4ef2 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bef2) #7 0x7f2203fdf472 abort (/lib/x86_64-linux-gnu/libc.so.6+0x26472) #8 0x7f2205a7f300 llvm::install_out_of_memory_new_handler() /tmp/llvm/llvm/lib/Support/ErrorHandling.cpp:194:0 #9 0x7f220ba5052d llvm::WebAssembly::getLibcallSignature(llvm::WebAssemblySubtarget const&, llvm::StringRef, llvm::SmallVectorImpl&, llvm::SmallVectorImpl&) /tmp/llvm/llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp:907:30 #10 0x7f220b9c4e0f llvm::WebAssemblyAsmPrinter::getOrCreateWasmSymbol(llvm::StringRef) /tmp/llvm/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:0:5 #11 0x7f220b9c4f46 llvm::WebAssemblyAsmPrinter::emitDecls(llvm::Module const&) /tmp/llvm/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:310:40 #12 0x7f220b9c7179 llvm::WebAssemblyAsmPrinter::emitConstantPool() /tmp/llvm/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:604:3 #13 0x7f2206ee9526 llvm::AsmPrinter::emitFunctionHeader() /tmp/llvm/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:966:3 ``` This file contains the script and preprocessed source that reproduce the problem: [ctanh.zip](https://github.com/user-attachments/files/15783347/ctanh.zip) https://github.com/llvm/llvm-project/pull/94559 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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-repl\CMakeFiles\clang-repl.dir\.\exports.def D:\task_171745452431588\fetches\llvm-project\build\stage2\build\tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def.objs --nm=D:\task_171745452431588\fetches\clang\bin\llvm-nm.exe && cd D:\task_171745452431588\fetches\llvm-project\build\stage2\build" && D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E vs_link_exe --intdir=tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir --rc="D:\task_171745452431588\fetches\vs\Windows Kits\10\bin\10.0.22621.0\x64\rc.exe" --mt="D:\task_171745452431588\fetches\vs\Windows Kits\10\bin\10.0.22621.0\x64\mt.exe" --manifests -- D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo @CMakeFiles\clang-repl.rsp /out:bin\clang-repl.exe /implib:lib\clang-repl.lib /pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 /STACK:1000 /libpath:"D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows" /INCREMENTAL:NO /subsystem:console /EXPORT:??_7type_info@@6B@ /EXPORT:?__type_info_root_node@@3U__type_info_node@@A /EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort /EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer /EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z /EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z /EXPORT:??3@YAXPEAX_K@Z /DEF:"D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def" -Wl,--long-plt /DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def && cd ." LINK: command "D:\task_171745452431588\fetches\clang\bin\lld-link.exe /nologo @CMakeFiles\clang-repl.rsp /out:bin\clang-repl.exe /implib:lib\clang-repl.lib /pdb:bin\clang-repl.pdb /version:0.0 /machine:x64 /STACK:1000 /libpath:D:/task_171745452431588/fetches/clang/lib/clang/19/lib/windows /INCREMENTAL:NO /subsystem:console /EXPORT:??_7type_info@@6B@ /EXPORT:?__type_info_root_node@@3U__type_info_node@@A /EXPORT:?nothrow@std@@3Unothrow_t@1@B /EXPORT:_Init_thread_abort /EXPORT:_Init_thread_epoch /EXPORT:_Init_thread_footer /EXPORT:_Init_thread_header /EXPORT:_tls_index /EXPORT:??2@YAPEAX_K@Z /EXPORT:??3@YAXPEAX@Z /EXPORT:??_U@YAPEAX_K@Z /EXPORT:??_V@YAXPEAX@Z /EXPORT:??3@YAXPEAX_K@Z /DEF:D:/task_171745452431588/fetches/llvm-project/build/stage2/build/tools/clang/tools/clang-repl/clang-repl.def -Wl,--long-plt /DEF:tools\clang\tools\clang-repl\CMakeFiles\clang-repl.dir\.\exports.def /MANIFEST /MANIFESTFILE:bin\clang-repl.exe.manifest" failed (exit code 1) with the following output: lld-link: error: : undefined symbol: __profc_??$?0$$BY03DUdesc lld-link: error: : undefined symbol: __profc_??$?0$$BY04DW4OptionHidden lld-link: error: : undefined symbol: __profc_??$?0$$BY09DW4OptionHidden lld-link: error: : undefined symbol: __profc_??$?0$$BY0BC lld-link: error: : undefined symbol: __profc_??$?0$$BY0N lld-link: error: : undefined symbol: __profc_??$?0W4FormattingFlags lld-link: error: : undefined symbol: __profc_??$?4$$BY05D lld-link: error: : undefined symbol: __profc_??$?6PEBD lld-link: error: : undefined symbol: __profc_??$_Emplace_reallocate lld-link: error: : undefined symbol: __profc_??$_Reallocate_for lld-link: error: : undefined symbol: __profc_??$_Reallocate_grow_by lld-link: error: : undefined symbol: __profc_??$_Traits_find lld-link: error: : undefined symbol: __profc_??$_Traits_rfind lld-link: error: : undefined symbol: __profc_??$_Uninitialized_move lld-link: error: : undefined symbol: __profc_??$addValue lld-link: error: : undefined symbol: __profc_??$handleErrors lld-link: error: : undefined symbol: __profc_??$setValue lld-link: error: : undefined symbol: __profc_??0?$OptionValueCopy lld-link: error: : undefined symbol: __profc_??0Completion lld-link: error: : undefined symbol: __profc_??0ErrorList lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to see all errors) ``` 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
[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)
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
[clang] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)
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.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)
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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #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/listinfo/cfe-commits
[clang] [libcxx] [llvm] Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (PR #98547)
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/mailman/listinfo/cfe-commits
[clang] [Clang][Sema] Fix lookup of dependent operator= outside of complete-class contexts (PR #91498)
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_map' 331 | auto flat_map::try_emplace(K&& key, | ^~~ /tmp/gecko/third_party/libwebrtc/rtc_base/containers/flat_map.h:343:49: error: out-of-line definition of 'try_emplace' does not match any declaration in 'flat_map' 343 | auto flat_map::try_emplace(const_iterator hint, | ^~~ 2 errors generated. ``` The lines with error are: https://searchfox.org/mozilla-central/rev/c34cf367c29601ed56ae4ea51e20b28cd8331f9c/third_party/libwebrtc/rtc_base/containers/flat_map.h#331,343 The corresponding declarations are: https://searchfox.org/mozilla-central/rev/c34cf367c29601ed56ae4ea51e20b28cd8331f9c/third_party/libwebrtc/rtc_base/containers/flat_map.h#243,248 I don't see how they differ. 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
[clang] [Clang][Sema] Fix lookup of dependent operator= outside of complete-class contexts (PR #91498)
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
[clang] [clang] Emit bad shift warnings (PR #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. https://github.com/llvm/llvm-project/pull/70307 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Emit bad shift warnings (PR #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 #100452 -- are you > seeing issues with the latest release candidate? I don't know about the latest release candidate, but trunk still has the problem. https://github.com/llvm/llvm-project/pull/70307 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Thread Safety Analysis: Differentiate between lock sets at real join points and expected/actual sets at function end (PR #105526)
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_function())) { /* unimplemented */ }
void AssertCurrentThreadOwns() __attribute__((assert_capability(this))) {
}
};
class __attribute__((scoped_lockable)) StaticMutexAutoLock {
public:
explicit StaticMutexAutoLock(StaticMutex& aLock)
__attribute__((exclusive_lock_function(aLock))) { /* unimplemented */ }
~StaticMutexAutoLock(void) __attribute__((unlock_function())) { /*
unimplemented */ }
};
class __attribute__((scoped_lockable)) StaticMutexAutoUnlock {
public:
explicit StaticMutexAutoUnlock(StaticMutex& aLock)
__attribute__((release_capability(aLock))) { /* unimplemented */ }
~StaticMutexAutoUnlock() __attribute__((release_capability())) { /*
unimplemented */ }
};
StaticMutex sMutex;
bool InitPreferredSampleRate() {
sMutex.AssertCurrentThreadOwns();
{
StaticMutexAutoUnlock unlock(sMutex);
}
return true;
}
```
Now it says `warning: mutex 'sMutex' is still held at the end of function
[-Wthread-safety-analysis]` because apparently it's not "propagating" from the
attribute on AssertCurrentThreadOwns?
https://github.com/llvm/llvm-project/pull/105526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [lld] [llvm] [Coverage][WebAssembly] Add initial support for WebAssembly/WASI (PR #111332)
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 the crash backtrace, preprocessed source, and associated run script. Exception Code: 0xC005 #0 0x7ff6786ac4b7 llvm::object::COFFObjectFile::getFeatures(void) const (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x43ac4b7) #1 0x7ff6786ac2c4 llvm::object::COFFObjectFile::getFeatures(void) const (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x43ac2c4) #2 0x7ff675f61b78 llvm::object::isNotObjectErrorInvalidFileType(class llvm::Error) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x1c61b78) #3 0x7ff675f619cf llvm::object::isNotObjectErrorInvalidFileType(class llvm::Error) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x1c619cf) #4 0x7ff67b9451d5 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x76451d5) #5 0x7ff67b9452c1 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x76452c1) #6 0x7ff67b944f79 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x7644f79) #7 0x7ff67b942979 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x7642979) #8 0x7ff67b9429f1 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x76429f1) #9 0x7ff67b9428e3 clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x76428e3) #10 0x7ff67b93227b clang::tooling::parseIWYUPragma(char const *) (D:\task_172897772250463\fetches\clang\bin\clang-cl.EXE+0x763227b) #11 0x7ffc74784cb0 (C:\Windows\System32\KERNEL32.DLL+0x14cb0) #12 0x7ffc7517ecdb (C:\Windows\SYSTEM32\ntdll.dll+0x7ecdb) ``` In the rare case where it doesn't crash, after the successful build, `llvm-profdata merge` fails with ``` D:\task_172895232291267\fetches\llvm-project/build/profiles\15750880694198762592_0.profraw: ??$_Emplace_reallocate@V?$unique_ptr@VSymbolicFile@object@llvm@@U?$default_delete@VSymbolicFile@object@llvm@@@std@@@std@@@?$vector@V?$unique_ptr@VSymbolicFile@object@llvm@@U?$default_delete@VSymbolicFile@object@llvm@@@std@@@std@@V?$allocator@V?$unique_ptr@VSymbolicFile@object@llvm@@U?$default_delete@VSymbolicFile@object@llvm@@@std@@@std@@@2@@std@@AEAAPEAV?$unique_ptr@VSymbolicFile@object@llvm@@U?$default_delete@VSymbolicFile@object@llvm@@@std@@@1@QEAV21@$$QEAV21@@Z: function value site count change detected (counter mismatch) Make sure that all profile data to be merged is generated from the same binary. warning: D:\task_172895232291267\fetches\llvm-project/build/profiles\10821587162318259349_0.profraw: malformed instrumentation profile data: total size is not multiples of quardword error: no profile can be merged ``` https://github.com/llvm/llvm-project/pull/111332 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Re-add path normalization that was removed in 315561c86778 (PR #118718)
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 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Re-add path normalization that was removed in 315561c86778 (PR #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
[clang-tools-extra] Re-add path normalization that was removed in 315561c86778 (PR #118718)
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
[clang-tools-extra] Re-add path normalization that was removed in 315561c86778 (PR #118718)
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
---
clang-tools-extra/clang-tidy/tool/run-clang-tidy.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
index f1b934f7139e94..d4cbcd2f564cbb 100755
--- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -522,7 +522,10 @@ async def main() -> None:
# Load the database and extract all files.
with open(os.path.join(build_path, db_path)) as f:
database = json.load(f)
-files = {os.path.abspath(os.path.join(e["directory"], e["file"])) for e in
database}
+files = {
+os.path.normpath(os.path.abspath(os.path.join(e["directory"],
e["file"])))
+for e in database
+}
number_files_in_database = len(files)
# Filter source files from compilation database.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Reapply "[clang] Fix name lookup for dependent bases" (PR #118003)
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/118003
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Deleting an incomplete enum type is not an error (PR #118455)
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-project/pull/118455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] Re-add path normalization that was removed in 315561c86778 (PR #118718)
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 forward slashes. This worked fine because `make_absolute` had a shortcut that didn't alter the path if it was already absolute. Then `file_name_re` would match properly. Now that `abspath` is always used, the paths in `files` are all with backslashes (because it's Windows, and path normalization turns the forward slashes into backslashes). But with `args.files` containing paths with forward slashes, `file_name_re` doesn't match anymore. But passing paths with backslashes in paths also doesn't work (and that's not new to https://github.com/llvm/llvm-project/commit/315561c867784ebd9ca387e94ea6597918e7cc1c), because of how these paths are used verbatim in `file_name_re` without escaping. But that's because what's passed in is regexps, so this makes sense. 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
[clang] [Clang] Deleting an incomplete enum type is not an error (PR #118455)
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/llvm-project/pull/118455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Pack relocations for Android API >= 28 (PR #117624)
@@ -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/issues/1196
+ // The unwinder used by the crash handler on versions of Android prior to
+ // API 29 did not correctly handle binaries built with rosegment, which
is
+ // enabled by default for LLD. Android only supports LLD, so it's not an
glandium wrote:
The NDK only provides LLD, but one can still use another linker via -fuse-ld,
and this breaks that use case. And yes, there are people doing that.
https://github.com/llvm/llvm-project/pull/117624
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland: [clang] NFC: Clear some uses of MemberPointerType::getClass (PR #132317)
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/checkouts/gecko/dom/media/webrtc/MediaEngineWebRTC.cpp:42:40:
parsing function body 'mozilla::MediaEngineWebRTC::MediaEngineWebRTC'
4.
/builds/worker/checkouts/gecko/dom/media/webrtc/MediaEngineWebRTC.cpp:42:40: in
compound statement ('{}')
#0 0x7f1beb652d08 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/tmp/llvm/obj-broken/bin/../lib/libLLVM.so.21.0git+0xe96d08)
#1 0x7f1beb65075e llvm::sys::RunSignalHandlers()
(/tmp/llvm/obj-broken/bin/../lib/libLLVM.so.21.0git+0xe9475e)
#2 0x7f1beb6533b1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7f1bea25b050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050)
#4 0x7f1bf5e57e31 addAssociatedClassesAndNamespaces((anonymous
namespace)::AssociatedLookup&, clang::CXXRecordDecl*) SemaLookup.cpp:0:0
#5 0x7f1bf5e45f6a addAssociatedClassesAndNamespaces((anonymous
namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0
#6 0x7f1bf5e45c81
clang::Sema::FindAssociatedClassesAndNamespaces(clang::SourceLocation,
llvm::ArrayRef, llvm::SmallSetVector&,
llvm::SmallSetVector&)
(/tmp/llvm/obj-broken/bin/../lib/libclang-cpp.so.21.0git+0x1ad3c81)
```
I'm running cvise to reduce the source code that leads to this.
https://github.com/llvm/llvm-project/pull/132317
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Reland: [clang] NFC: Clear some uses of MemberPointerType::getClass (PR #132317)
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 camera::CamerasChild;
using camera::GetChildAndCall;
MediaEngineWebRTC::MediaEngineWebRTC() {
GetChildAndCall(
&CamerasChild::ConnectDeviceListChangeListener);
}
```
and is fixed by #132977.
https://github.com/llvm/llvm-project/pull/132317
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Force expressions with UO_Not to not be non-negative (PR #126846)
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 foo(unsigned char x)
{
return ~(1
[clang] [clang-tools-extra] [flang] [llvm] Reland 'Update llvm::Registry to work for LLVM shared library builds on windows' (#109024) (PR #112640)
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/112640 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Remove xbegin and _xend (PR #126952)
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
