[clang] b7abab2 - Annotate enum r brace

Author: Björn Schäpers Date: 2023-10-09T19:53:03+02:00 New Revision: b7abab2f284cca5a712a22b87c1998fbed9f4bc9 URL: https://github.com/llvm/llvm-project/commit/b7abab2f284cca5a712a22b87c1998fbed9f4bc9 DIFF: https://github.com/llvm/llvm-project/commit/b7abab2f284cca5a712a22b87c1998fbed9f4bc9.diff

[clang] Annotate enum r brace (PR #68535)

https://github.com/HazardyKnusperkeks closed https://github.com/llvm/llvm-project/pull/68535 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

https://github.com/zmodem edited https://github.com/llvm/llvm-project/pull/68460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

@@ -3152,7 +3152,8 @@ defm diagnostics_show_line_numbers : BoolFOption<"diagnostics-show-line-numbers" def fno_stack_protector : Flag<["-"], "fno-stack-protector">, Group, HelpText<"Disable the use of stack protectors">; def fno_strict_aliasing : Flag<["-"], "fno-strict-alia

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

https://github.com/zmodem requested changes to this pull request. Thanks for the PR! https://github.com/llvm/llvm-project/pull/68460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

@@ -4722,3 +4724,17 @@ The Visual C++ Toolset has a slightly more elaborate mechanism for detection. The registry information is used to help locate the installation as a final fallback. This is only possible for pre-VS2017 installations and is considered deprecat

[PATCH] D159045: [clang-tidy] Improved documentation for readability-function-size

PiotrZSL closed this revision. PiotrZSL added a comment. Obsolete. No longer needed after D159436 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159045/new/ https://reviews.llvm.org/D159045 ___

[PATCH] D157547: Arm64EC entry/exit thunks, consolidated.

efriedma added a comment. For assembly, I'm not really comfortable with the fix you're proposing; it relies on the order in which functions are defined in assembly. I think LLVM usually ends up emitting module-level inline assembly before generated code, but it seems fragile to depend on that

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

https://github.com/david-xl edited https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

https://github.com/david-xl commented: Is there a need to have a separate vtable name section? Merging the vtable names with function name table can make the implementation simpler. https://github.com/llvm/llvm-project/pull/66825 ___ cfe-commits mail

[PATCH] D157547: Arm64EC entry/exit thunks, consolidated.

efriedma updated this revision to Diff 557651. efriedma added a comment. Fix the calling convention for functions returning C++ classes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157547/new/ https://reviews.llvm.org/D157547 Files: clang/lib/

[PATCH] D157547: Arm64EC entry/exit thunks, consolidated.

efriedma added a comment. > For assembly, I'm not really comfortable with the fix you're proposing; it > relies on the order in which functions are defined in assembly. I think LLVM > usually ends up emitting module-level inline assembly before generated code, > but it seems fragile to depend o

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString;

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [clang] Fixes compile error that double colon operator cannot resolve macro with parentheses. (PR #68618)

https://github.com/lygstate created https://github.com/llvm/llvm-project/pull/68618 Error message: ``` In file included from ../src/amd/addrlib/src/core/addrobject.h:21: ../src/amd/addrlib/src/core/addrcommon.h:343:13: error: expected unqualified-id out = ::_tzcnt_u32(mask); ^ /

[clang] [clang] Fixes compile error that double colon operator cannot resolve macro with parentheses. (PR #68618)

lygstate wrote: it's already accepted in https://reviews.llvm.org/D157297 https://github.com/llvm/llvm-project/pull/68618 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Adding Separate OpenMP Offloading Backend to `libcxx/include/__algorithm/pstl_backends` (PR #66968)

EricWF wrote: @philnik777 Last we spoke, the design work around the customization points was still ongoing. Have we locked it in now? https://github.com/llvm/llvm-project/pull/66968 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang-tools-extra] Adding Separate OpenMP Offloading Backend to `libcxx/include/__algorithm/pstl_backends` (PR #66968)

EricWF wrote: @philnik777 Last we spoke, the design work around the customization points was still ongoing. Have we locked it in now? https://github.com/llvm/llvm-project/pull/66968 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang] 67b675e - Revert "[Clang] Implement the 'counted_by' attribute" (#68603)

Author: alexfh Date: 2023-10-09T20:53:48+02:00 New Revision: 67b675ee55cce183b93874a38ab94eee00aedbcc URL: https://github.com/llvm/llvm-project/commit/67b675ee55cce183b93874a38ab94eee00aedbcc DIFF: https://github.com/llvm/llvm-project/commit/67b675ee55cce183b93874a38ab94eee00aedbcc.diff LOG: R

[clang] Revert "[Clang] Implement the 'counted_by' attribute" (PR #68603)

https://github.com/alexfh closed https://github.com/llvm/llvm-project/pull/68603 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

https://github.com/ThePhD edited https://github.com/llvm/llvm-project/pull/68620 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

llvmbot wrote: @llvm/pr-subscribers-llvm-support Changes This pull request implements the entirety of the now-accepted [N3017 - Preprocessor Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and its sister C++ paper [p1967](https://wg21.link/p1967). It implements everyth

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 67b675ee55cce183b93874a38ab94eee00aedbcc adc973776a526f97b6da2435edf143a10e7e0ad5 --

[PATCH] D157547: Arm64EC entry/exit thunks, consolidated.

jacek added a comment. In D157547#4653477 , @efriedma wrote: > How important is that particular pattern? I think most patterns involving > assembly should be covered by some combination of naked functions, and > functions defined in separate assembly f

[clang] [NVPTX] Improve lowering of v4i8 (PR #67866)

Artem-B wrote: clang-format failure on GitHub is weird -- it just silently exits with an error. I ran the same command locally and fixed one place it was not happy about. The buildkite failure somewhere in RISC-V appears to be unrelated. https://github.com/llvm/llvm-project/pull/67866 ___

[clang-tools-extra] [NVPTX] Improve lowering of v4i8 (PR #67866)

Artem-B wrote: clang-format failure on GitHub is weird -- it just silently exits with an error. I ran the same command locally and fixed one place it was not happy about. The buildkite failure somewhere in RISC-V appears to be unrelated. https://github.com/llvm/llvm-project/pull/67866 ___

[clang] [clang-format][NFC] Annotate control statement r_braces (PR #68621)

https://github.com/HazardyKnusperkeks created https://github.com/llvm/llvm-project/pull/68621 Annotating switch braces for the first time. Also in preparation of #67906. From 358cbf4fd25d2d323e21774a3d4f5a605c4f1479 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?= Date: M

[clang] [clang-format][NFC] Annotate control statement r_braces (PR #68621)

llvmbot wrote: @llvm/pr-subscribers-clang-format Changes Annotating switch braces for the first time. Also in preparation of #67906. --- Full diff: https://github.com/llvm/llvm-project/pull/68621.diff 3 Files Affected: - (modified) clang/lib/Format/FormatToken.h (+2) - (modified) clan

[clang] [NVPTX] Improve lowering of v4i8 (PR #67866)

https://github.com/Artem-B closed https://github.com/llvm/llvm-project/pull/67866 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [NVPTX] Improve lowering of v4i8 (PR #67866)

https://github.com/Artem-B closed https://github.com/llvm/llvm-project/pull/67866 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

@@ -1464,6 +1467,21 @@ class AnnotatingParser { } } + void parseEmbedDirective() { +if (CurrentToken && CurrentToken->is(tok::less)) { + next(); + while (CurrentToken) { +// Mark tokens up to the trailing line comments as implicit string +/

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

@@ -1500,6 +1518,14 @@ class AnnotatingParser { next(); // ')' } + void parseHasEmbed() { +if (!CurrentToken || CurrentToken->isNot(tok::l_paren)) + return; +next(); // '(' +parseEmbedDirective(); +next(); // ')' HazardyKnusperkeks

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

@@ -1464,6 +1467,21 @@ class AnnotatingParser { } } + void parseEmbedDirective() { +if (CurrentToken && CurrentToken->is(tok::less)) { + next(); + while (CurrentToken) { +// Mark tokens up to the trailing line comments as implicit string +/

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

@@ -1464,6 +1467,21 @@ class AnnotatingParser { } } + void parseEmbedDirective() { +if (CurrentToken && CurrentToken->is(tok::less)) { + next(); + while (CurrentToken) { +// Mark tokens up to the trailing line comments as implicit string +/

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

@@ -0,0 +1,41 @@ +//===-- Client.h --===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apa

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

@@ -0,0 +1,134 @@ +//===- SocketMsgSupport.h -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

@@ -3738,6 +3737,19 @@ static bool RenderModulesOptions(Compilation &C, const Driver &D, Std->containsValue("c++latest") || Std->containsValue("gnu++latest")); bool HaveModules = HaveStdCXXModules; + // -fmodule-build-daemon enables module build daemon functionality

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

https://github.com/iains edited https://github.com/llvm/llvm-project/pull/67562 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

AaronBallman wrote: FWIW, I spoke offline with the original author of the PR and he said that he's fine with me picking up the changes and carrying the review forward. Because I don't know of any better way to commandeer a patch in GitHub, I'll probably grab the changes, get them into my own

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

cachemeifyoucan wrote: > Implementing a timeout as part of this patch as a safety measure seems worth > while too but I'm not sure I understand your final solution. You all spawned > a clang job that had to communicate with the daemon to make sure one did not > exist? It is something like thi

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

https://github.com/iains commented: I had a couple of questions. I guess my main concern here is that the TODO for portability might turn out to be quite heavy lifting. Perhaps we should be looking to abstract the socket-like interface at a lower level. https://github.com/llvm/llvm-project

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

https://github.com/huihzhang updated https://github.com/llvm/llvm-project/pull/68460 >From 866ebc3da4208f2be206cc9839fc06d689d9bf34 Mon Sep 17 00:00:00 2001 From: Huihui Zhang Date: Fri, 6 Oct 2023 17:37:03 -0700 Subject: [PATCH 1/2] [clang-cl] Document behavior difference of strict aliasing i

[clang-tools-extra] 7a73da4 - [clang-tidy] Add support for optional parameters in config.

Author: Felix Date: 2023-10-09T19:58:44Z New Revision: 7a73da4c85a12341752a4573c55ebff46ba20db0 URL: https://github.com/llvm/llvm-project/commit/7a73da4c85a12341752a4573c55ebff46ba20db0 DIFF: https://github.com/llvm/llvm-project/commit/7a73da4c85a12341752a4573c55ebff46ba20db0.diff LOG: [clang-

[PATCH] D159436: [clang-tidy] Add support for optional parameters in config.

This revision was automatically updated to reflect the committed changes. Closed by commit rG7a73da4c85a1: [clang-tidy] Add support for optional parameters in config. (authored by felix642, committed by PiotrZSL). Changed prior to commit: https://reviews.llvm.org/D159436?vs=557546&id=557652#toc

[clang] [Support] Add VirtualOutputBackends to virtualize the output from tools (PR #68447)

@@ -0,0 +1,158 @@ +//===- raw_ostream_proxy.h - Proxies for raw output streams -*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [clang] Fixes compile error that double colon operator cannot resolve macro with parentheses. (PR #68618)

https://github.com/lygstate updated https://github.com/llvm/llvm-project/pull/68618 >From aab85e0a145dba36e5edce4bcda0ef733f6ed5a1 Mon Sep 17 00:00:00 2001 From: Yonggang Luo Date: Tue, 10 Oct 2023 02:23:34 +0800 Subject: [PATCH] [clang] Fixes compile error that double colon operator cannot re

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

huihzhang wrote: Fixed up documentation based on review comments. https://github.com/llvm/llvm-project/pull/68460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

https://github.com/zmodem approved this pull request. Looks good to me. Thanks! https://github.com/llvm/llvm-project/pull/68460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

mstorsjo wrote: > We could go with a clang fix, but also make the backend report_fatal_error if > you try to use llvm.ctors with UseInitArray on mingw. That keeps everything > consistent while also making sure non-clang frontends don't miscompile. Hmm, interesting proposition... But wouldn't t

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

efriedma-quic wrote: Hmm... Maybe the backend should have some notion of a default ctors section. So if the frontend doesn't explicitly specify anything, the backend tries to pick the right default. https://github.com/llvm/llvm-project/pull/68571 _

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. I re-read the code review, and I think most folks are in favor of this change, but I may have missed some. Many concerns were raised, so please wait for approval from @efriedma as well before landin

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

mstorsjo wrote: > Hmm... > > Maybe the backend should have some notion of a default ctors section. So if > the frontend doesn't explicitly specify anything, the backend tries to pick > the right default. Yep, this is kinda the same issue for lots of target specific options that are set as bo

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,202 @@ +//===--- APINotesReader.h - API Notes Reader *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] [APINotes] Upstream APINotesReader (PR #66769)

@@ -0,0 +1,2001 @@ +//===--- APINotesReader.cpp - API Notes Reader --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: A

[clang] 540a1a6 - [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (#68460)

Author: Huihui Zhang Date: 2023-10-09T13:35:55-07:00 New Revision: 540a1a6621b860b5d0be7e413e815be7de90722e URL: https://github.com/llvm/llvm-project/commit/540a1a6621b860b5d0be7e413e815be7de90722e DIFF: https://github.com/llvm/llvm-project/commit/540a1a6621b860b5d0be7e413e815be7de90722e.diff

[clang] [clang-cl] Document behavior difference of strict aliasing in clang-cl vs clang. (PR #68460)

https://github.com/huihzhang closed https://github.com/llvm/llvm-project/pull/68460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

efriedma-quic wrote: Doesn't UseInitArray default to false in LLVM? Anyway, we already have ways to make booleans optional; it's just a matter of implementing a "default" state, which we already do for certain options like code models. I don't think there's any fundamental architectural work i

[PATCH] D153131: [clang analysis][thread-safety] Handle return-by-reference...

aeubanks added a comment. If people are passing `-Wthread-safety-reference`, there was clearly some value in the previous checks and it would be unfortunate to turn them off while fixing the codebase. I'm not super familiar with flag families and if what I'm proposing is easily doable, but I th

[PATCH] D155688: [PATCH] [llvm] [InstCombine] Canonicalise ADD+GEP

fiigii added a comment. > The reverse transform is only done if A + B simplifies. Looks like`simplifyAddInst` may give add expressions, so I guess this patch may make IC run into infinite loops. Additionally, this change could make longer GEP chains that could hurt other optimizations by excee

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

mstorsjo wrote: > Doesn't UseInitArray default to false in LLVM? The class `TargetOptions` itself initializes it to false indeed. But `codegen::InitTargetOptionsFromCodeGenFlags` (which seems to be what e.g. `llc` uses) explicitly sets it to `!getUseCtors()`, which only checks the state of th

[clang] [IRPGO][ValueProfile] Instrument virtual table address that could be used to do virtual table address comparision for indirect-call-promotion. (PR #66825)

modiking wrote: > > > Yes there are tradeoffs to doing this purely with whole program class > > > hierarchy analysis vs with profiled type info, and in fact they can be > > > complementary. For example, the profile info can indicate what order to > > > do the vtable comparisons (i.e. descendin

[clang] [Sanitizer][Docs] Improve docs on building Asan (PR #68636)

https://github.com/boomanaiden154 created https://github.com/llvm/llvm-project/pull/68636 Currently the documentation for building Asan doesn't specify that compiler-rt needs to be built as well. In addition, there's no minimal example for the LLVM CMake configuration. This patch addresses bot

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -0,0 +1,129 @@ +//===--- HashKeyMap.h - Wrapper for maps using hash value key ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [Sanitizer][Docs] Improve docs on building Asan (PR #68636)

llvmbot wrote: @llvm/pr-subscribers-clang Changes Currently the documentation for building Asan doesn't specify that compiler-rt needs to be built as well. In addition, there's no minimal example for the LLVM CMake configuration. This patch addresses both of these issues. The lack of spe

[PATCH] D158266: [OpenMP] Patch for Support to loop bind clause : Checking Parent Region

ABataev added inline comments. Comment at: clang/lib/Sema/SemaOpenMP.cpp:6181-6190 + checkNestingOfRegions(*this, DSAStack, Kind, DirName, CancelRegion, +BindKind, StartLoc); Kind = OMPD_for; DSAStack->setCurrentDirective(OMPD_for);

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

efriedma-quic wrote: It's only breaking for downstreams that were messing with the option in the first place. Searching GitHub, the only downstream I can find that actually touches it is rustc. I understand it's simpler to just override the behavior for MinGW, but I think it's really confusi

[clang-tools-extra] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (PR #66164)

@@ -902,12 +890,16 @@ std::error_code SampleProfileReaderExtBinaryBase::readFuncProfiles() { for (const auto &NameOffset : FuncOffsetList) { const auto &FContext = NameOffset.first; auto FName = FContext.getName(); +StringRef FNameString; +

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

https://github.com/efriedma-quic approved this pull request. Whatever we decide to do on the LLVM side, this seems fine for the clang side. It looks like clang uses the value of UseInitArray for some ObjC stuff, in addition to passing it to the backend, so we need the right value in clang in

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

mstorsjo wrote: > Right, so adding an `enum DefaultableBool { Default, False, True }` and > changing the field to that value? With such a definition, I wonder how to interpret it for MSVC targets; `UseInitArray` would be false, as MSVC uses the `.CRT` sections, neither `.ctors` not `.init_ar

[clang] [Support] Add VirtualOutputBackends to virtualize the output from tools (PR #68447)

@@ -0,0 +1,158 @@ +//===- raw_ostream_proxy.h - Proxies for raw output streams -*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [clang] [MinGW] Explicitly always pass the -fno-use-init-array (PR #68571)

efriedma-quic wrote: On targets that don't use the Unix .ctors/.init_array convention, the option doesn't make any sense, so we should just ignore it. For example, the AIX target overrides emitXXStructorList. https://github.com/llvm/llvm-project/pull/68571

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86 datalayouts

efriedma added a comment. Given the complexity here, I agree this is probably the best we can reasonably do. Code and test changes LGTM. That said, this is missing a release note. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86310/new/ https://

[clang] [clang][dataflow]Use dyn_cast_or_null instead cast to prevent crash (PR #68510)

https://github.com/Xazax-hun commented: The fix looks great to me! On the other hand, we usually try to add a regression test for each of the fixes. Any chance you could get a minimal reproducer from the codebase you are looking at? https://github.com/llvm/llvm-project/pull/68510

[clang] [llvm-objcopy] Add --gap-fill and --pad-to options (PR #65815)

https://github.com/quic-akaryaki updated https://github.com/llvm/llvm-project/pull/65815 >From 21ba98fbed6ef3b9bbbef96feb6dfeb0679f7ce8 Mon Sep 17 00:00:00 2001 From: Alexey Karyakin Date: Tue, 5 Sep 2023 15:46:34 -0700 Subject: [PATCH 1/3] [llvm-objcopy] Add --gap-fill and --pad-to options `-

[clang] [Sanitizer][Docs] Improve docs on building Asan (PR #68636)

https://github.com/vitalybuka approved this pull request. https://github.com/llvm/llvm-project/pull/68636 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Compute length of string literal initializers (#66990) (PR #68368)

@@ -97,6 +97,17 @@ void strlen_constant2(char x) { clang_analyzer_eval(strlen(a) == 3); // expected-warning{{UNKNOWN}} } +const char *const global_str_ptr = "abcd"; Xazax-hun wrote: What about a non-const global pointer? Could you add a test making sure we

[clang] 115b6a3 - [Sanitizer][Docs] Improve docs on building Asan (#68636)

Author: Aiden Grossman Date: 2023-10-09T15:13:56-07:00 New Revision: 115b6a3b17a2068a45075f6c4f3256e84305bc6c URL: https://github.com/llvm/llvm-project/commit/115b6a3b17a2068a45075f6c4f3256e84305bc6c DIFF: https://github.com/llvm/llvm-project/commit/115b6a3b17a2068a45075f6c4f3256e84305bc6c.diff

[clang] [Sanitizer][Docs] Improve docs on building Asan (PR #68636)

https://github.com/boomanaiden154 closed https://github.com/llvm/llvm-project/pull/68636 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sanitizer][Docs] Improve docs on building Asan (PR #68636)

vitalybuka wrote: I am to late with comment, can you make it in the same style as https://llvm.org/docs/CMake.html One line, and with $: ``` .. code-block:: console $ cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="compiler-rt" path/to/llvm/source `

[clang] [clang] Ignore GCC 11 `[[malloc(x)]]` attribute (PR #68059)

https://github.com/shafik edited https://github.com/llvm/llvm-project/pull/68059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Add support for lambda captures (PR #68558)

https://github.com/Xazax-hun approved this pull request. LG! https://github.com/llvm/llvm-project/pull/68558 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

<    1   2   3   4   5   >