[clang] [Driver] Make ELF -nopie specific to OpenBSD (PR #72578)

2023-11-29 Thread Mike Hommey via cfe-commits

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


[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)

2024-02-05 Thread Mike Hommey via cfe-commits

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)

2024-02-05 Thread Mike Hommey via cfe-commits

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)

2024-02-05 Thread Mike Hommey via cfe-commits

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)

2024-02-05 Thread Mike Hommey via cfe-commits

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] [Driver] Check the environment version except wasm case. (PR #80783)

2024-02-06 Thread Mike Hommey via cfe-commits


@@ -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


[clang] [clang][PP] Add extension to predefine target OS macros (PR #74676)

2024-01-16 Thread Mike Hommey via cfe-commits

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)

2024-01-17 Thread Mike Hommey via cfe-commits

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] [llvm] [clang] Reland Add tanf16 builtin and support for tan constrained intrinsic (PR #94559)

2024-06-10 Thread Mike Hommey via cfe-commits

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] [compiler-rt] [compiler-rt] Realtime Sanitizer: Introduce Realtime Sanitizer (RTSan) backend (PR #92460)

2024-07-09 Thread Mike Hommey via cfe-commits

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)

2024-07-12 Thread Mike Hommey via cfe-commits

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)

2024-07-12 Thread Mike Hommey via cfe-commits

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)

2024-07-12 Thread Mike Hommey via cfe-commits

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)

2024-05-08 Thread Mike Hommey via 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_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)

2024-05-08 Thread Mike Hommey via cfe-commits

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-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

2024-06-04 Thread Mike Hommey via 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-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)

2024-06-04 Thread Mike Hommey via cfe-commits

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] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

2024-06-05 Thread Mike Hommey via 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 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)

2024-06-05 Thread Mike Hommey via 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/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)

2024-06-05 Thread Mike Hommey via 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


[clang] [clang-tools-extra] [libcxx] Reland "[clang] Enable sized deallocation by default in C++14 onwards" (PR #90373)

2024-06-05 Thread Mike Hommey via 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


[clang] [CMake]Fully delete the deprecated LLVM_USE_CRT* (PR #66850)

2023-10-05 Thread Mike Hommey via 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 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)

2023-10-05 Thread Mike Hommey via cfe-commits

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] [clang] Emit bad shift warnings (PR #70307)

2024-08-07 Thread Mike Hommey via cfe-commits

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)

2024-08-07 Thread Mike Hommey via cfe-commits

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] Add flag to suppress overflow errors in C++ constant expressions. (PR #102390)

2024-08-08 Thread Mike Hommey via cfe-commits

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