[clang] [llvm] [Darwin][IR] Don't error on target_variant mismatch when linking IR (PR #92297)

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

[clang] [lld] [llvm] Run ObjCContractPass in Distributed Thin-LTO Pipeline (PR #92331)

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

[clang] [lld] [llvm] Run ObjCContractPass in Distributed Thin-LTO Pipeline (PR #92331)

cachemeifyoucan wrote: > I couldn't find this check you're alluding to, so I added my own. If the > check does exist, could you point me to it? If not, does mine look > reasonable? Thanks. I was answering from my memory, now I have to check. We have this function `ModuleHasARC` which is used

[clang] [llvm] [Darwin][IR] Don't error on target_variant mismatch when linking IR (PR #92297)

https://github.com/cachemeifyoucan updated https://github.com/llvm/llvm-project/pull/92297 >From dcdad613db40ce325c1ffbe98df02c454daa3771 Mon Sep 17 00:00:00 2001 From: Steven Wu Date: Wed, 15 May 2024 10:35:55 -0700 Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=

[clang] [lld] [llvm] Run ObjCContractPass in Distributed Thin-LTO Pipeline (PR #92331)

cachemeifyoucan wrote: > it seems like this should just be in the default codegen pipeline? you'd need > to change the pass to bail out early if there are no relevant intrinsics (by > checking if the module contains the intrinsic declaration) to not affect > compile times > it seems like

[clang] [llvm] [Darwin][IR] Don't error on target_variant mismatch when linking IR (PR #92297)

https://github.com/cachemeifyoucan updated https://github.com/llvm/llvm-project/pull/92297 >From dcdad613db40ce325c1ffbe98df02c454daa3771 Mon Sep 17 00:00:00 2001 From: Steven Wu Date: Wed, 15 May 2024 10:35:55 -0700 Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=

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

@@ -0,0 +1,25 @@ +// Check that a clang invocation can spawn and handshake with a module build daemon + +// RUN: %kill-process "-cc1modbuildd mbd-handshake" +// RUN: rm -rf mbd-handshake %t +// RUN: split-file %s %t + +//--- main.c +int main() {return 0;} + +// RUN: %clang

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

@@ -0,0 +1,25 @@ +// Check that a clang invocation can spawn and handshake with a module build daemon + +// RUN: %kill-process "-cc1modbuildd mbd-handshake" +// RUN: rm -rf mbd-handshake %t +// RUN: split-file %s %t + +//--- main.c +int main() {return 0;} + +// RUN: %clang

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

@@ -0,0 +1,25 @@ +// Check that a clang invocation can spawn and handshake with a module build daemon + +// RUN: %kill-process "-cc1modbuildd mbd-handshake" +// RUN: rm -rf mbd-handshake %t +// RUN: split-file %s %t + +//--- main.c +int main() {return 0;} + +// RUN: %clang

[clang] [clang][docs] fix whitespace in AttrDocs.td (PR #88631)

https://github.com/cachemeifyoucan approved this pull request. LGTM. Thanks for fixing. https://github.com/llvm/llvm-project/pull/88631 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][docs] Modernize attribute docs for darwin specifics (PR #88448)

@@ -1604,23 +1604,31 @@ specifies availability for the current target platform, the availability attributes are ignored. Supported platforms are: ``ios`` - Apple's iOS operating system. The minimum deployment target is specified by - the ``-mios-version-min=*version*`` or

[clang] [clang][docs] Modernize attribute docs for darwin specifics (PR #88448)

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

[clang] [clang][docs] Modernize attribute docs for darwin specifics (PR #88448)

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

[clang] [clang][Darwin] Handle reexported library arguments in driver (PR #86980)

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

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

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

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction Preprocessor::HandleHeaderIncludeOrImport( // The drive letter is optional for absolute paths on Windows, but // clang currently cannot process absolute paths in #include lines that // don't have a

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction Preprocessor::HandleHeaderIncludeOrImport( // The drive letter is optional for absolute paths on Windows, but // clang currently cannot process absolute paths in #include lines that // don't have a

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction Preprocessor::HandleHeaderIncludeOrImport( // The drive letter is optional for absolute paths on Windows, but // clang currently cannot process absolute paths in #include lines that // don't have a

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

https://github.com/cachemeifyoucan approved this pull request. LGTM with small comments. https://github.com/llvm/llvm-project/pull/74782 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

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

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

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

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

https://github.com/cachemeifyoucan updated https://github.com/llvm/llvm-project/pull/72572 >From 89938936f2e021360e3889548608e76022c3d73b Mon Sep 17 00:00:00 2001 From: Steven Wu Date: Thu, 16 Nov 2023 13:21:27 -0800 Subject: [PATCH 1/2] [ClangModule] Fix decl-params-determinisim test after

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

https://github.com/cachemeifyoucan created https://github.com/llvm/llvm-project/pull/72572 Fix decl-params-determinisim test after 48be81e1 packed some information in the clang module. The test is to make sure the decls are appearing in a strict ordering and it relies on check the correct

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

[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

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

@@ -0,0 +1,302 @@ +//===--- cc1modbuildd_main.cpp - Clang CC1 Module Build Daemon ===// +// +// 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:

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

https://github.com/cachemeifyoucan commented: I haven't read the PR in details but one thing we found difficult to do is how to write a test for daemon spawning logic, because if anything went wrong, you left an unbounded daemon process on CI node. The strategy in this PR (try to kill it

[clang] 42c9354 - Revert "Reland "[LoongArch] Support -march=native and -mtune=""

Author: Steven Wu Date: 2023-07-31T16:57:06-07:00 New Revision: 42c9354a928d4d9459504527085fccc91b46aed3 URL: https://github.com/llvm/llvm-project/commit/42c9354a928d4d9459504527085fccc91b46aed3 DIFF: https://github.com/llvm/llvm-project/commit/42c9354a928d4d9459504527085fccc91b46aed3.diff

[clang] 4098e13 - Revert "[clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body"

Author: Steven Wu Date: 2023-07-28T11:39:46-07:00 New Revision: 4098e13a71464cc4747528edd8a41e5a4eaa1b23 URL: https://github.com/llvm/llvm-project/commit/4098e13a71464cc4747528edd8a41e5a4eaa1b23 DIFF: https://github.com/llvm/llvm-project/commit/4098e13a71464cc4747528edd8a41e5a4eaa1b23.diff

[clang] 0480748 - [DeclContext] Sort the Decls before adding into DeclContext

Author: Steven Wu Date: 2023-02-02T15:16:20-08:00 New Revision: 0480748ea6728392886931b8470969ae17aaa91f URL: https://github.com/llvm/llvm-project/commit/0480748ea6728392886931b8470969ae17aaa91f DIFF: https://github.com/llvm/llvm-project/commit/0480748ea6728392886931b8470969ae17aaa91f.diff

[clang] 5cff68f - [Module] Respect `-fno-pch-timestamps` when building modules

Author: Steven Wu Date: 2023-02-01T10:34:35-08:00 New Revision: 5cff68fca0bc21ccad20cc7c8fb9845e32b4c925 URL: https://github.com/llvm/llvm-project/commit/5cff68fca0bc21ccad20cc7c8fb9845e32b4c925 DIFF: https://github.com/llvm/llvm-project/commit/5cff68fca0bc21ccad20cc7c8fb9845e32b4c925.diff

[clang] 516e301 - [NFC][Profile] Access profile through VirtualFileSystem

Author: Steven Wu Date: 2023-02-01T09:25:02-08:00 New Revision: 516e301752560311d2cd8c2b549493eb0f98d01b URL: https://github.com/llvm/llvm-project/commit/516e301752560311d2cd8c2b549493eb0f98d01b DIFF: https://github.com/llvm/llvm-project/commit/516e301752560311d2cd8c2b549493eb0f98d01b.diff

[clang] 9cd6fbe - Fix module build after TargetParser

Author: Steven Wu Date: 2022-12-20T10:31:19-08:00 New Revision: 9cd6fbee7ed881f8e80b735e95567040e56f189e URL: https://github.com/llvm/llvm-project/commit/9cd6fbee7ed881f8e80b735e95567040e56f189e DIFF: https://github.com/llvm/llvm-project/commit/9cd6fbee7ed881f8e80b735e95567040e56f189e.diff

[clang] 493766e - Frontend: Respect -working-directory when checking if output files can be written

Author: Steven Wu Date: 2022-09-09T08:57:12-07:00 New Revision: 493766e068474a80a790ac41c667061229d2262d URL: https://github.com/llvm/llvm-project/commit/493766e068474a80a790ac41c667061229d2262d DIFF: https://github.com/llvm/llvm-project/commit/493766e068474a80a790ac41c667061229d2262d.diff

[clang] d072826 - [Darwin toolchain] Tune the logic for finding arclite.

Author: Steven Wu Date: 2022-07-20T16:45:52-07:00 New Revision: d0728260577d66b4b4d922adf0a40de86f09ccf5 URL: https://github.com/llvm/llvm-project/commit/d0728260577d66b4b4d922adf0a40de86f09ccf5 DIFF: https://github.com/llvm/llvm-project/commit/d0728260577d66b4b4d922adf0a40de86f09ccf5.diff

[libunwind] 4cd0937 - [libunwind] Remove compatibility support for macOS 10.6

Author: Steven Wu Date: 2020-08-17T14:09:03-07:00 New Revision: 4cd09374cdb163573007ccb402f5ba8970eb6134 URL: https://github.com/llvm/llvm-project/commit/4cd09374cdb163573007ccb402f5ba8970eb6134 DIFF: https://github.com/llvm/llvm-project/commit/4cd09374cdb163573007ccb402f5ba8970eb6134.diff

[clang] 2b42080 - [clang] Teach -fembed-bitcode option not to embed W_value Group

Author: Steven Wu Date: 2020-07-14T14:40:43-07:00 New Revision: 2b42080b51c9a0c5ed733b30da165774dcd0d595 URL: https://github.com/llvm/llvm-project/commit/2b42080b51c9a0c5ed733b30da165774dcd0d595 DIFF: https://github.com/llvm/llvm-project/commit/2b42080b51c9a0c5ed733b30da165774dcd0d595.diff

[libunwind] 9366397 - [libunwind] Fix evaluating DWARF operation DW_OP_pick

Author: Steven Wu Date: 2019-12-18T12:22:21-08:00 New Revision: 9366397f057d18401e680b2cb28a0ee17c59d4a6 URL: https://github.com/llvm/llvm-project/commit/9366397f057d18401e680b2cb28a0ee17c59d4a6 DIFF: https://github.com/llvm/llvm-project/commit/9366397f057d18401e680b2cb28a0ee17c59d4a6.diff

r375027 - Fix darwin-ld-lto test for some speical path

Author: steven_wu Date: Wed Oct 16 11:12:41 2019 New Revision: 375027 URL: http://llvm.org/viewvc/llvm-project?rev=375027=rev Log: Fix darwin-ld-lto test for some speical path Fix the test by not assuming the prefix path of the temp directory can be matched by a regex. rdar://problem/56259195

Re: r328173 - Improve -Winfinite-recursion

Hi Robert I ping'ed this commit on Phabricator with an example of false positive introduced by this patch. Can you take a look? Thanks Steven > On Mar 21, 2018, at 8:16 PM, Robert Widmann via cfe-commits > wrote: > > Author: codafi > Date: Wed Mar 21 20:16:23 2018 > New Revision: 328173 >

Re: r350970 - [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

r352537 should fix it. Steven > On Jan 29, 2019, at 11:36 AM, Matt Arsenault wrote: > > > >> On Jan 11, 2019, at 4:16 PM, Steven Wu via cfe-commits >> mailto:cfe-commits@lists.llvm.org>> wrote: >> >> Author: steven_wu >> Date: Fri Jan 11

r352537 - Fix the tests from r350970

Author: steven_wu Date: Tue Jan 29 12:13:02 2019 New Revision: 352537 URL: http://llvm.org/viewvc/llvm-project?rev=352537=rev Log: Fix the tests from r350970 Relax the tests from r350970 to allow non-standard path for ld. Modified: cfe/trunk/test/Driver/darwin-ld-lto.c Modified:

r350970 - [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

Author: steven_wu Date: Fri Jan 11 13:16:04 2019 New Revision: 350970 URL: http://llvm.org/viewvc/llvm-project?rev=350970=rev Log: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO Summary: After r327851, Driver::GetTemporaryPath will create the file rather than just create a

r348943 - [Driver] Add support for -fembed-bitcode for assembly file

Author: steven_wu Date: Wed Dec 12 09:30:16 2018 New Revision: 348943 URL: http://llvm.org/viewvc/llvm-project?rev=348943=rev Log: [Driver] Add support for -fembed-bitcode for assembly file Summary: Handle -fembed-bitcode for assembly inputs. When the input file is assembly, write a marker as

r336168 - [Driver][Darwin] Use Host Triple to infer target os version

Author: steven_wu Date: Mon Jul 2 21:15:49 2018 New Revision: 336168 URL: http://llvm.org/viewvc/llvm-project?rev=336168=rev Log: [Driver][Darwin] Use Host Triple to infer target os version Summary: When clang required to infer target os version from --target option and the os version is not

r335366 - Add const qualifier on FieldChainInfoComparator::operator()

Author: steven_wu Date: Fri Jun 22 09:51:17 2018 New Revision: 335366 URL: http://llvm.org/viewvc/llvm-project?rev=335366=rev Log: Add const qualifier on FieldChainInfoComparator::operator() libcxx has user defined warning to check for non const call operator. Silence the warning by adding the

r333148 - [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr

Author: steven_wu Date: Wed May 23 18:01:43 2018 New Revision: 333148 URL: http://llvm.org/viewvc/llvm-project?rev=333148=rev Log: [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr Summary: Remove the call to DiagnoseUseOfDecl in LookupMemberExpr because: 1. LookupMemberExpr eagerly

r330338 - [CXX] Templates specialization visibility can be wrong

Author: steven_wu Date: Thu Apr 19 08:46:43 2018 New Revision: 330338 URL: http://llvm.org/viewvc/llvm-project?rev=330338=rev Log: [CXX] Templates specialization visibility can be wrong Summary: Under some conditions, LinkageComputer can get the visibility for ClassTemplateSpecializationDecl

r330166 - [Availability] Improve availability to consider functions run at load time

Author: steven_wu Date: Mon Apr 16 16:34:18 2018 New Revision: 330166 URL: http://llvm.org/viewvc/llvm-project?rev=330166=rev Log: [Availability] Improve availability to consider functions run at load time Summary: There are some functions/methods that run when the application launches or the

r321909 - Preserve unknown STDC pragma through preprocessor

Author: steven_wu Date: Fri Jan 5 14:45:03 2018 New Revision: 321909 URL: http://llvm.org/viewvc/llvm-project?rev=321909=rev Log: Preserve unknown STDC pragma through preprocessor Summary: #pragma STDC FP_CONTRACT handler is only registered in parser so we should keep the unknown STDC pragma

r317860 - [Driver] Make clang/cc conforms to UNIX standard

Author: steven_wu Date: Thu Nov 9 17:32:47 2017 New Revision: 317860 URL: http://llvm.org/viewvc/llvm-project?rev=317860=rev Log: [Driver] Make clang/cc conforms to UNIX standard Summary: This is basically reverting r261774 with a tweak for clang-cl. UNIX standard states: When c99 encounters a

Re: r304661 - CodeGen: fix section names for different file formats

Hi Saleem I just realize there can be an issue with this commit. This breaks the bitcode compatibility when LTO linking bitcode file produced by llvm-5.0 vs the older versions. Because the objc related module flag has the behavior Module::Error, simple whitespace changes will cause libLTO to

Re: r261774 - Bail on compilation as soon as a job fails.

> On May 15, 2017, at 3:03 PM, Nico Weber wrote: > > test/Driver/cl-pch-errorhandling.cpp tests the clang-cl pch bits. I don't think reverting r261774 will break any cl-pch tests (didn't try windows). That is why I wondering if there is any test case for CUDA so I don't

Re: r261774 - Bail on compilation as soon as a job fails.

The other option is to make this behavior configurable so that clang on UNIX behaves differently than clang-cl or CUDA. I am not sure what problem CUDA is hitting. Is there a test case for that? Steven > On May 15, 2017, at 12:42 PM, Nico Weber wrote: > > r262420 landed

Re: r261774 - Bail on compilation as soon as a job fails.

Hi Nico Now that r262420 is landed. Is there any plan to move CUDA to the new approach so we can fix the UNIX conformance test? Thanks Steven > On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits > wrote: > > On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N.

Re: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

For those watch the bots, Eric upgrade the bots with the new compiler and I remove the XFAIL in r296385. Thanks Steven > On Feb 23, 2017, at 11:48 AM, Steven Wu via cfe-commits > <cfe-commits@lists.llvm.org> wrote: > > Hi Eric > > Looks like the issue is fixed in r

[libcxx] r296385 - Remove XFAIL in implicit_deduction_guides tests

Author: steven_wu Date: Mon Feb 27 15:10:41 2017 New Revision: 296385 URL: http://llvm.org/viewvc/llvm-project?rev=296385=rev Log: Remove XFAIL in implicit_deduction_guides tests The clang assertion causing these tests failing with sanitizer is fixed in r295794. All the bots running libcxx tests

Re: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

Hi Eric This has been failing for one week on green dragon. I think all the bots running sanitizer should pick up the clang with the fix already if they are building from trunk. Should I try remove the XFAIL? Steven > On Feb 23, 2017, at 11:48 AM, Steven Wu wrote: > > Hi

Re: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

Hi Eric Looks like the issue is fixed in r295794? Now green dragon is failing due to XPASS. http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/3018/testReport/ Can we remove that XFAILs in these two files? std/strings/basic_string/string_cons.implicit_deduction_guides.pass.cpp

Re: Embedded Bitcode in Object Files

er > need them? > >> On Mon, Feb 29, 2016 at 2:08 PM, Steven Wu via cfe-commits >> <cfe-commits@lists.llvm.org> wrote: >> Ping. I don't know who is the best review for the patches. Thanks for Rafael >> looking at the LLVM change. Richard, do you have a

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

This revision was automatically updated to reflect the committed changes. Closed by commit rL287084: [Driver] Infer the correct option to ld64 for -fembed-bitcode (authored by steven_wu). Changed prior to commit: https://reviews.llvm.org/D26690?vs=78111=78140#toc Repository: rL LLVM

r287084 - [Driver] Infer the correct option to ld64 for -fembed-bitcode

Author: steven_wu Date: Wed Nov 16 00:06:44 2016 New Revision: 287084 URL: http://llvm.org/viewvc/llvm-project?rev=287084=rev Log: [Driver] Infer the correct option to ld64 for -fembed-bitcode Summary: -fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly passed when using LTO.

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

steven_wu updated this revision to Diff 78111. steven_wu added a comment. Rename the functions to clarify the intention. embedBitcodeEnabled means if any flag in -fembed-bitcode family is used so the corresponding linker flag should be inferred. embedBitcodeInObject means if the bitcode should be

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

steven_wu added inline comments. Comment at: lib/Driver/Tools.cpp:8326 - if (C.getDriver().embedBitcodeEnabled() || - C.getDriver().embedBitcodeMarkerOnly()) { -// Check if the toolchain supports bitcode build flow. mehdi_amini wrote: > Why aren't

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

steven_wu created this revision. steven_wu added a reviewer: mehdi_amini. steven_wu added a subscriber: cfe-commits. -fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly passed when using LTO. LTO is a special case of -fembed-bitcode which it doesn't require embed the bitcode in

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

> On Jul 25, 2016, at 3:24 AM, Jonas Devlieghere wrote: > > Hi, > > I hope I'm not breaking any mailing list etiquette by replying to this > mail, but if I am then please accept my apologies. > > On Fri, Jun 3, 2016 at 8:36 PM, Steven Wu via llvm-dev >

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

> On Jun 14, 2016, at 3:27 PM, Eric Christopher wrote: > > > > On Mon, Jun 13, 2016 at 9:37 AM Steven Wu > wrote: > Thanks for the feedback! Replies inline. > >> On Jun 12, 2016, at 11:44 PM, Eric Christopher

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

Thanks for the feedback! Replies inline. > On Jun 12, 2016, at 11:44 PM, Eric Christopher wrote: > > Hi Steven, > > Great to see the commentary and updates here. I've got a few questions about > some of this work. It might be nice to see some separate RFCs for a couple of

[PATCH] D21230: Do not embed all the cc1 options in bitcode commandline

steven_wu created this revision. steven_wu added reviewers: rsmith, dexonsmith. steven_wu added subscribers: cfe-commits, jfb, dschuff. Previously, all the cc1 options are passed to both compile stage and codegen stage and almost all of them are embedded in the commandline section in the object

[RFC] Embedded bitcode and related upstream (Part II)

Hi everyone I am still in the process of upstreaming some improvements to the embed bitcode option. If you want more background, you can read the previous RFC (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html

Re: r270047 - [Clang][AVX512][intrinsics] continue completing missing set intrinsics

Hi Michael This commit seems break darwin LTO bootstrap bot. http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/7916/ Also breaks the Asan Ubsan bot: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1742/ Can you talk a look? I don't why the failure doesn't

Re: [PATCH] D20374: [Driver] Fix the case when use -fembed-bitcode and -flto= together

This revision was automatically updated to reflect the committed changes. Closed by commit rL269961: [Driver] Fix the case when use -fembed-bitcode and -flto= together (authored by steven_wu). Changed prior to commit: http://reviews.llvm.org/D20374?vs=57645=57646#toc Repository: rL LLVM

r269961 - [Driver] Fix the case when use -fembed-bitcode and -flto= together

Author: steven_wu Date: Wed May 18 12:04:52 2016 New Revision: 269961 URL: http://llvm.org/viewvc/llvm-project?rev=269961=rev Log: [Driver] Fix the case when use -fembed-bitcode and -flto= together Summary: -fembed-bitcode was only checking for old style LTO flag (-flto) but not considering the

[PATCH] D20374: [Driver] Fix the case when use -fembed-bitcode and -flto= together

steven_wu created this revision. steven_wu added a reviewer: joker.eph. steven_wu added a subscriber: cfe-commits. Herald added a subscriber: joker.eph. -fembed-bitcode was only checking for old style LTO flag (-flto) but not considering the new -flto= style option. That makes clang output

Re: [patch] Don't use appending linkage for embeded bitcode

Thanks! Committed in r269679 Steven > On May 16, 2016, at 11:54 AM, Rafael Espíndola > wrote: > > LGTM > > On 16 May 2016 at 14:03, Steven Wu wrote: >> >>> On May 16, 2016, at 6:52 AM, Rafael Espíndola >>> wrote:

Re: [patch] Don't use appending linkage for embeded bitcode

> On May 16, 2016, at 6:52 AM, Rafael Espíndola > wrote: > > + auto Used = collectUsedGlobalVariables(*M, UsedGlobals, true); > > Please use an explicit type instead of auto. Sure. > > You deleted the assert Are you referring to the assertion that

Re: [patch] Don't use appending linkage for embeded bitcode

> On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith > wrote: > > Is this something that you need the linker to treat as "used", or just > something you don't want the compiler to drop? If the latter, > @llvm.compiler.used seems more appropriate. Bitcode is actually

Re: [patch] Don't use appending linkage for embeded bitcode

Attach a patch using private linkage type and adding to llvm.used. I have to recreate llvm.used when embedding bitcode. I don't really like it but I don't have better solutions. Few other options: 1. Not allowing re-embedded bitcode will simplify the code a bit but not a lot. 2. Create a new

Re: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

It is part of -Wall group and it should be on by default when you building clang. That warning is added into clang some time in 2014. Make sure you are not using a compiler that is too old. Steven > On May 13, 2016, at 10:58 AM, Liu, Yaxun (Sam) wrote: > > BTW is there a

Re: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

Hi Yaxun You seems missing some override keyword that triggers -Winconsistent-missing-override. See: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/24442/warnings8Result/new/ Here is a patch to fix them: diff --git a/lib/Basic/Targets.cpp b/lib/Basic/Targets.cpp

Re: [patch] Don't use appending linkage for embeded bitcode

Hi Rafael Thanks for notice this! That would definitely cause duplicated symbol error and I should definitely change that. Here is some background: ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not the ones in earlier Xcode. The old ld64 will simply concatenate the

r269202 - Embed bitcode in object file (clang cc1 part)

Author: steven_wu Date: Wed May 11 11:26:03 2016 New Revision: 269202 URL: http://llvm.org/viewvc/llvm-project?rev=269202=rev Log: Embed bitcode in object file (clang cc1 part) Summary: Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1 option is used, clang will embed both

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

This revision was automatically updated to reflect the committed changes. Closed by commit rL269202: Embed bitcode in object file (clang cc1 part) (authored by steven_wu). Changed prior to commit: http://reviews.llvm.org/D17392?vs=56371=56930#toc Repository: rL LLVM

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu added a comment. Attach a new patch with the comments Comment at: lib/CodeGen/BackendUtil.cpp:799-831 @@ +798,35 @@ + // Embed the bitcode for the llvm module. + std::string Data; + ArrayRef ModuleData; + Triple T(M->getTargetTriple()); + if

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu updated this revision to Diff 56371. steven_wu marked 2 inline comments as done. steven_wu added a comment. Add comments to address the feedback fromt the review. http://reviews.llvm.org/D17392 Files: include/clang/CodeGen/BackendUtil.h include/clang/Driver/Options.td

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu updated this revision to Diff 56367. steven_wu added a comment. Format update according to review. http://reviews.llvm.org/D17392 Files: include/clang/CodeGen/BackendUtil.h include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.def

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu added inline comments. Comment at: lib/CodeGen/BackendUtil.cpp:769-770 @@ +768,4 @@ +void clang::EmbedBitcode(llvm::Module *M, const CodeGenOptions , + llvm::MemoryBufferRef Buf) +{ + if (CGOpts.getEmbedBitcode() == CodeGenOptions::Embed_Off)

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu added a comment. Ping. http://reviews.llvm.org/D17392 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu updated this revision to Diff 54597. steven_wu added a comment. Thanks Vedant! Address all of your review in this update. http://reviews.llvm.org/D17392 Files: include/clang/CodeGen/BackendUtil.h include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.def

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu updated this revision to Diff 54559. steven_wu added a comment. Ping. Rebase the patch over trunk and tweak the testcase. http://reviews.llvm.org/D17392 Files: include/clang/CodeGen/BackendUtil.h include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.def

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu added a comment. ping. The currently -fembed-bitcode option is only half working. I don't want to leave it like that too long. http://reviews.llvm.org/D17392 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu updated this revision to Diff 52435. steven_wu added a comment. Address the feedback from Richard: Break -fembed-bitcode option into multiple -fembed-bitcode= options. -fembed-bitcode=all will embed both bitcode and commandline and -fembed-bitcode=bitcode will embed only the bitcode in

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

steven_wu added a comment. Hi Richard Thanks for looking at the patch! Replies are inlined with the feedback. Steven Comment at: include/clang/Frontend/CodeGenOptions.def:57 @@ -56,1 +56,3 @@ +CODEGENOPT(EmbedBitcode , 1, 0) ///< Embed LLVM IR bitcode as data.

r263087 - Fix false positives for for-loop-analysis warning

Author: steven_wu Date: Wed Mar 9 20:02:48 2016 New Revision: 263087 URL: http://llvm.org/viewvc/llvm-project?rev=263087=rev Log: Fix false positives for for-loop-analysis warning Summary: For PseudoObjectExpr, the DeclMatcher need to search only all the semantics but also need to search pass

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

This revision was automatically updated to reflect the committed changes. steven_wu marked 2 inline comments as done. Closed by commit rL263087: Fix false positives for for-loop-analysis warning (authored by steven_wu). Changed prior to commit: http://reviews.llvm.org/D17627?vs=50212=50221#toc

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

steven_wu updated this revision to Diff 50212. steven_wu updated the summary for this revision. steven_wu added a comment. Update according to feedback. I agree that OVE should never be null as semantics of PseudoObjectExpr. http://reviews.llvm.org/D17627 Files: lib/Sema/SemaStmt.cpp

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

steven_wu updated this revision to Diff 50186. steven_wu added a comment. Update the patch to address John's feedback. We shouldn't even checking ObjCSubscript but looking at the Semantics for PseudoObjectExpr only. http://reviews.llvm.org/D17627 Files: lib/Sema/SemaStmt.cpp

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

steven_wu added a comment. ping http://reviews.llvm.org/D17627 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

steven_wu updated this revision to Diff 49549. steven_wu added a comment. I did some more digging of the issue. It seems ObjCSubscriptRefExpr always rebuilds and hinds both base and key behind OpaqueValueExpr. See ObjCSubscriptOpBuilder::rebuildAndCaptureObject so it looks the AST generated is

Re: r262282 - Introduce -fembed-bitcode driver option

assembler by default yet so it was failing to find the > -emit-obj option. I've fixed this by adding -fintegrated-as. > > > From: cfe-commits [cfe-commits-boun...@lists.llvm.org] on behalf of Steven Wu > via cfe-commits [cfe-commits@lists.llvm.org] >

  1   2   >