[libcxx] r296704 - Fix Apple-specific XFAIL directive in libc++ test

Author: mehdi_amini Date: Wed Mar 1 17:14:34 2017 New Revision: 296704 URL: http://llvm.org/viewvc/llvm-project?rev=296704&view=rev Log: Fix Apple-specific XFAIL directive in libc++ test These tests are failing in XCode 8.0, 8.1, and 8.2, but not in Xcode 8.3. Annoyingly the version numbering fo

Re: r296554 - [PS4] Set our default dialect to C++11. NFC for other targets.

> On Mar 1, 2017, at 3:24 PM, Sean Silva wrote: > > > > On Wed, Mar 1, 2017 at 10:35 AM, Mehdi Amini > wrote: > I’m not sure I find this nice to see this upstream. > > I not fond in general of this kind of difference in behavior. I don’t think > it is good for

[libcxx] r296712 - Fix Apple-specific XFAIL directive in libc++ test

Author: mehdi_amini Date: Wed Mar 1 17:45:03 2017 New Revision: 296712 URL: http://llvm.org/viewvc/llvm-project?rev=296712&view=rev Log: Fix Apple-specific XFAIL directive in libc++ test This tests is failing in XCode 7.0. But Xcode 7.3 that shipped an updated clang has this test passing. This i

[libcxx] r296724 - Revert "Fix Apple-specific XFAIL directive in libc++ test"

Author: mehdi_amini Date: Wed Mar 1 19:57:40 2017 New Revision: 296724 URL: http://llvm.org/viewvc/llvm-project?rev=296724&view=rev Log: Revert "Fix Apple-specific XFAIL directive in libc++ test" This reverts commit r296712. It broke our bot. It turns out that the test is passing with c++11 and

[libcxx] r296725 - Recommit r296712: "Fix Apple-specific XFAIL directive in libc++ test"

Author: mehdi_amini Date: Wed Mar 1 20:01:11 2017 New Revision: 296725 URL: http://llvm.org/viewvc/llvm-project?rev=296725&view=rev Log: Recommit r296712: "Fix Apple-specific XFAIL directive in libc++ test" The test is passing with c++11 and c++14 but not c++1z on this particular version of the

[libcxx] r296830 - Fix libc++ test experimental/algorithms/alg.random.sample/sample.pass.cpp when ran in c++11 mode 32 bits

Author: mehdi_amini Date: Thu Mar 2 16:08:42 2017 New Revision: 296830 URL: http://llvm.org/viewvc/llvm-project?rev=296830&view=rev Log: Fix libc++ test experimental/algorithms/alg.random.sample/sample.pass.cpp when ran in c++11 mode 32 bits Modified: libcxx/trunk/test/std/experimental/alg

[libcxx] r296889 - Fix libc++ test to pass in C++03 mode

Author: mehdi_amini Date: Fri Mar 3 11:24:29 2017 New Revision: 296889 URL: http://llvm.org/viewvc/llvm-project?rev=296889&view=rev Log: Fix libc++ test to pass in C++03 mode Was hitting: "error: scalar initializer cannot be empty" Modified: libcxx/trunk/test/std/depr/depr.c.headers/stdio_h

r297351 - Add a cmake cache file for a stage-2 build with ThinLTO

Author: mehdi_amini Date: Wed Mar 8 19:18:31 2017 New Revision: 297351 URL: http://llvm.org/viewvc/llvm-project?rev=297351&view=rev Log: Add a cmake cache file for a stage-2 build with ThinLTO This is intended to be targetted by a Green Dragon stage-2 bot I'm bringing up currently. WIP. Added:

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. Make sense to me, but I don't think it is enough: LLVM_ENABLE_LLD should be passed to stage-2, and it also should be set to the absolute path of the stage-1 lld build. Repository: rL LLVM https://reviews.llvm.org/D26649 ___

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added inline comments. Comment at: CMakeLists.txt:516 if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED) add_dependencies(clang-bootstrap-deps LTO) if(APPLE) This dep does not make sense when using either ll

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595296, @phosek wrote: > It's sufficient, I just tested it. I'm not actually sure if `LLVM_ENABLE_LLD` > here is correct, `LLVM_ENABLE_LLD` forces the use of lld, but lld might not > be available during first stage. We need `LLVM_E

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595301, @Eugene.Zelenko wrote: > I think this should be handled in higher level script > (utils/release/test-release.sh or similar), not in CMake. CMake compiler > tests just need to fail when LLVM_ENABLE_LLD is used without actual

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595334, @Eugene.Zelenko wrote: > I meant that multi-stage build is processed by higher level script. So it > should take care about consistency of source code srt versus later stages > build options. We have a 2-stage build direc

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595296, @phosek wrote: > It's sufficient, I just tested it. How did you check it? I don't understand how LLVM_ENABLE_LLD is propagated to stage-2? Comment at: CMakeLists.txt:534 +add_dependencies(LLVMgo

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595361, @phosek wrote: > In https://reviews.llvm.org/D26649#595356, @mehdi_amini wrote: > > > In https://reviews.llvm.org/D26649#595296, @phosek wrote: > > > > > It's sufficient, I just tested it. > > > > > > How did you check it? I

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini accepted this revision. mehdi_amini added a reviewer: mehdi_amini. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM. Repository: rL LLVM https://reviews.llvm.org/D26649 ___ cfe-commits mailing list cf

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini requested changes to this revision. mehdi_amini added inline comments. This revision now requires changes to proceed. Comment at: CMakeLists.txt:516 if(BOOTSTRAP_LLVM_ENABLE_LTO OR LLVM_ENABLE_LTO AND NOT LLVM_BUILD_INSTRUMENTED) -add_dependencies(clang-bootst

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. What about the following logic? if(BOOTSTRAP_LLVM_ENABLE_LLD) add_dependencies(clang-bootstrap-deps lld) endif() if(APPLE) # on Darwin we need to set DARWIN_LTO_LIBRARY so that -flto will work # using the just-built compiler, and we need t

[PATCH] D21737: [PATCH] [CodeGen] Insert TargetLibraryInfoWrapperPass before anything else.

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM. Thanks! Comment at: lib/CodeGen/BackendUtil.cpp:422 // Set up the per-function pass manager. + FPM.add(new TargetLibraryInfoWrapperPass(*TLII)); if (Co

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#595429, @phosek wrote: > AFAIK lld on Darwin doesn't support LTO (last I heard it cannot even > self-host at the moment) so I'm not sure if it makes sense to enable it > `if(APPLE)`. OK, we could error instead of ignoring then. B

[PATCH] D26664: [ObjC] Prevent infinite loops when iterating over redeclaration of a method that was declared in an invalid interface

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM, thks. (See one inline comment to fix though) Comment at: lib/AST/DeclObjC.cpp:841 +return nullptr; + if (const auto *Ctx = cast(Redecl->getDeclContext())

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. In https://reviews.llvm.org/D26649#596024, @beanz wrote: > On Darwin you don't want to set `DARWIN_LTO_LIBRARY` on the next stage if > you're intending the next stage to use lld because that sets flags that > aren't supported by lld. Right, but that's a separate i

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. Patch LGTM right now, let's just wait for @beanz in case he objects. Repository: rL LLVM https://reviews.llvm.org/D26649 ___ cfe-com

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. @beanz : don't you think that it should be handled at the top level and not in the bootstrap logic? Right now we don't error when invoking cmake with `-DLLVM_ENABLE_LLD=ON` and `-DLLVM_ENABLE_LTO=ON` on Darwin. Repository: rL LLVM https://reviews.llvm.org/D2664

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

mehdi_amini 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. Why aren't these tests returning tr

r287039 - Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Author: mehdi_amini Date: Tue Nov 15 15:47:11 2016 New Revision: 287039 URL: http://llvm.org/viewvc/llvm-project?rev=287039&view=rev Log: Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks Instead of always displaying the mangled name, try to do better and ge

[PATCH] D26522: Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

This revision was automatically updated to reflect the committed changes. Closed by commit rL287039: Improve handling of __FUNCTION__ and other predefined expression for Objective… (authored by mehdi_amini). Changed prior to commit: https://reviews.llvm.org/D26522?vs=77682&id=78073#toc Reposit

r287043 - Revert "Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks"

Author: mehdi_amini Date: Tue Nov 15 16:19:50 2016 New Revision: 287043 URL: http://llvm.org/viewvc/llvm-project?rev=287043&view=rev Log: Revert "Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks" This reverts commit r287039, tests are broken. Removed:

[PATCH] D26522: Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

mehdi_amini added a comment. Already reverted Repository: rL LLVM https://reviews.llvm.org/D26522 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

mehdi_amini 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. steven_wu wrote: > mehdi_amini wrot

[PATCH] D26649: [CMake] Support lld with LTO bootstrap

mehdi_amini added a comment. Patch still LGTM! Thanks. Repository: rL LLVM https://reviews.llvm.org/D26649 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM! I feel the code is cleaner like that at uses of these API :) https://reviews.llvm.org/D26690 ___ cfe-commits mailing list cfe-co

[PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++

mehdi_amini added a comment. Ping @rsmith ! https://reviews.llvm.org/D26376 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r287085 - Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Author: mehdi_amini Date: Wed Nov 16 01:07:28 2016 New Revision: 287085 URL: http://llvm.org/viewvc/llvm-project?rev=287085&view=rev Log: Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks Instead of always displaying the mangled name, try to do better and ge

[PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

mehdi_amini added a comment. What is the correct solution for MSVC in C? (If any) Repository: rL LLVM https://reviews.llvm.org/D24289 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi

[PATCH] D26833: LTO support for -fsave-optimization-record on Darwin

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D26833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/lis

[PATCH] D26833: LTO support for -fsave-optimization-record on Darwin

mehdi_amini requested changes to this revision. mehdi_amini added a comment. This revision now requires changes to proceed. Well, maybe not entirely, what do you expect for output with ThinLTO? https://reviews.llvm.org/D26833 ___ cfe-commits mailing

[PATCH] D26833: LTO support for -fsave-optimization-record on Darwin

mehdi_amini added a comment. I'm not incline to agree with this, unless you have very strong arguments. https://reviews.llvm.org/D26833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

r287449 - Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)

Author: mehdi_amini Date: Sat Nov 19 12:19:41 2016 New Revision: 287449 URL: http://llvm.org/viewvc/llvm-project?rev=287449&view=rev Log: Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC) Summary: This makes it explicit that ownership is taken. Also replace all `new` w

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini added a comment. We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you don't package libLTO yourself, it is already accessible from the linker: it will use the one in the toolchain when needed. I don't have an immediate idea to prevent this and have the linker iss

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini added a comment. In https://reviews.llvm.org/D25932#601842, @rnk wrote: > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote: > > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you > > don't package libLTO yourself, it is already accessible from the

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

> On Nov 21, 2016, at 2:27 PM, Nico Weber wrote: > > On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > mehdi_amini added a comment. > > In https://reviews.llvm.org/D25932#601842 > <https://reviews.ll

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

> On Nov 21, 2016, at 2:44 PM, Nico Weber wrote: > > On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini <mailto:mehdi.am...@apple.com>> wrote: > >> On Nov 21, 2016, at 2:27 PM, Nico Weber > <mailto:tha...@chromium.org>> wrote: >> >> On Mon, N

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

>>> On Nov 21, 2016, at 2:27 PM, Nico Weber >> <mailto:tha...@chromium.org>> wrote: >>> >>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits >>> mailto:cfe-commits@lists.llvm.org>> wrote: >>> mehdi_amini added a commen

Re: [PATCH] D26944: Suppress -Wliblto warning when -flto is not present

FYI, doesn’t look good to me, cf what I described on the other thread. > On Nov 21, 2016, at 9:51 PM, Nico Weber wrote: > > Lgtm, works for me. Seems like a good compromise. > > > On Nov 21, 2016 6:29 PM, "Reid Kleckner" > wrote: > rnk created this revision. > rnk adde

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

Mehdi Amini > <mailto:mehdi.am...@apple.com>> wrote: >> >>> On Nov 21, 2016, at 2:27 PM, Nico Weber >> <mailto:tha...@chromium.org>> wrote: >>> >>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits >>> mailto:cfe-com

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

Double-checked on the latest binary release on llvm.org, it ships with clang+llvm-3.9.0-x86_64-apple-darwin/lib/libLTO.dylib I also can’t find any CMake option that disable LTO support at build time for clang. > On Nov 21, 2016, at 9:53 PM, Mehdi Amini via cfe-commits > wrote: >

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

Amini wrote: >> Double-checked on the latest binary release on llvm.org, it ships with >> clang+llvm-3.9.0-x86_64-apple-darwin/lib/libLTO.dylib >> >> I also can’t find any CMake option that disable LTO support at build time >> for clang. >> >> >

[PATCH] D26984: Unconditionally pass -lto_library, remove -Wliblto warning.

mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM, thanks! https://reviews.llvm.org/D26984 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mai

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

What would be the status of these buildbots? Is it for your private usage? Otherwise having “project' bots” using a non-official mirror may sound like a strange situation to me. — Mehdi > On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev > wrote: > > Adding cfe-dev list... > > On Wed

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

> On Apr 20, 2017, at 12:39 AM, Eric Fiselier wrote: > > > > On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini > wrote: > What would be the status of these buildbots? Is it for your private usage? > > I intend for them to be public Windows buildbots for libc++. I

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

> On Apr 20, 2017, at 12:30 PM, Eric Fiselier wrote: > > > > On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini > wrote: > >> On Apr 20, 2017, at 12:39 AM, Eric Fiselier > > wrote: >> >> >> >> On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini >

Re: [llvm-dev] Permissions for llvm-mirror - Setting up Libc++ Appveyor builders

> On Apr 20, 2017, at 7:03 PM, Eric Fiselier wrote: > > > > On Thu, Apr 20, 2017 at 4:55 PM, Mehdi Amini > wrote: > >> On Apr 20, 2017, at 12:30 PM, Eric Fiselier > > wrote: >> >> >> >> On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini >

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini created this revision. mehdi_amini added a reviewer: bkramer. mehdi_amini added a subscriber: cfe-commits. Herald added subscribers: modocache, mgorny, beanz. These new builtins support a mechanism for logging OS events, using a printf-like format string to specify the layout of data i

[PATCH] D25206: [Parser] Correct typo after lambda capture initializer is parsed

mehdi_amini added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:951 Init = ParseInitializer(); + Init = Actions.CorrectDelayedTyposInExpr(Init.get()); What happens when there is no typo correction to apply? https://reviews.llvm.o

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini updated this revision to Diff 75524. mehdi_amini added a comment. Address David's feedback. Thanks David! https://reviews.llvm.org/D25888 Files: clang/include/clang/Analysis/Analyses/FormatString.h clang/include/clang/Analysis/Analyses/OSLog.h clang/include/clang/Basic/Builtin

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini updated this revision to Diff 75534. mehdi_amini added a comment. std::any_of -> llvm::any_of and more magic number replaced with enum https://reviews.llvm.org/D25888 Files: clang/include/clang/Analysis/Analyses/FormatString.h clang/include/clang/Analysis/Analyses/OSLog.h clan

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini updated this revision to Diff 75536. mehdi_amini added a comment. typo + clang-format https://reviews.llvm.org/D25888 Files: clang/include/clang/Analysis/Analyses/FormatString.h clang/include/clang/Analysis/Analyses/OSLog.h clang/include/clang/Basic/Builtins.def clang/includ

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini updated this revision to Diff 75552. mehdi_amini added a comment. Use a separate enum to described OSLogBufferLayout header flags https://reviews.llvm.org/D25888 Files: clang/include/clang/Analysis/Analyses/FormatString.h clang/include/clang/Analysis/Analyses/OSLog.h clang/inc

[PATCH] D21737: [PATCH] [CodeGen] Insert TargetLibraryInfoWrapperPass before anything else.

mehdi_amini added inline comments. Comment at: lib/CodeGen/BackendUtil.cpp:422 // Set up the per-function pass manager. + FPM.add(new TargetLibraryInfoWrapperPass(*TLII)); if (CodeGenOpts.VerifyModule) This seems unnecessary? Repository: rL LLVM https

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini added a comment. Thanks! For the API part, this is already in production ( https://github.com/apple/swift-clang/blob/stable/lib/CodeGen/CGBuiltin.cpp#L2071 ), so it should be OK! https://reviews.llvm.org/D25888 ___ cfe-commits mailing

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

This revision was automatically updated to reflect the committed changes. Closed by commit rL284990: Add support for __builtin_os_log_format[_buffer_size] (authored by mehdi_amini). Changed prior to commit: https://reviews.llvm.org/D25888?vs=75552&id=75608#toc Repository: rL LLVM https://re

r284990 - Add support for __builtin_os_log_format[_buffer_size]

Author: mehdi_amini Date: Mon Oct 24 11:56:23 2016 New Revision: 284990 URL: http://llvm.org/viewvc/llvm-project?rev=284990&view=rev Log: Add support for __builtin_os_log_format[_buffer_size] These new builtins support a mechanism for logging OS events, using a printf-like format string to specif

r285007 - Revert "Add support for __builtin_os_log_format[_buffer_size]"

Author: mehdi_amini Date: Mon Oct 24 14:41:36 2016 New Revision: 285007 URL: http://llvm.org/viewvc/llvm-project?rev=285007&view=rev Log: Revert "Add support for __builtin_os_log_format[_buffer_size]" This reverts commit r284990, two opencl test are broken Removed: cfe/trunk/include/clang/An

r285019 - Add support for __builtin_os_log_format[_buffer_size]

Author: mehdi_amini Date: Mon Oct 24 15:39:34 2016 New Revision: 285019 URL: http://llvm.org/viewvc/llvm-project?rev=285019&view=rev Log: Add support for __builtin_os_log_format[_buffer_size] This reverts commit r285007 and reapply r284990, with a fix for the opencl test that I broke. Original co

r285027 - Fix test on non-X86 platforms

Author: mehdi_amini Date: Mon Oct 24 16:22:01 2016 New Revision: 285027 URL: http://llvm.org/viewvc/llvm-project?rev=285027&view=rev Log: Fix test on non-X86 platforms This is a fixup for r285019, adding an `#ifdef __x86_64__` since the os_log builtin is platform specific. Modified: cfe/trun

Re: r285027 - Fix test on non-X86 platforms

per wrote: > > Doesn't this exclude 32-bit x86? > > ~Craig > > On Mon, Oct 24, 2016 at 2:22 PM, Mehdi Amini via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > Author: mehdi_amini > Date: Mon Oct 24 16:22:01 2016 > New Revision: 285027 >

[PATCH] D25888: Add support for __builtin_os_log_format[_buffer_size]

mehdi_amini added a comment. @bkramer : is it an OK dependency to add from a clang point of view? Or should I refactor the patch to avoid introducing it? Repository: rL LLVM https://reviews.llvm.org/D25888 ___ cfe-commits mailing list cfe-commit

r285042 - Add dependency from clangCodeGen to clangAnalysis

Author: mehdi_amini Date: Mon Oct 24 18:38:32 2016 New Revision: 285042 URL: http://llvm.org/viewvc/llvm-project?rev=285042&view=rev Log: Add dependency from clangCodeGen to clangAnalysis This is unbreaking the build with shared library after r285019. Modified: cfe/trunk/lib/CodeGen/CMakeLis

r285041 - test/CodeGen/builtins.c: reinstate #ifdef __x86_64__ around __builtin_longjmp

Author: mehdi_amini Date: Mon Oct 24 18:38:24 2016 New Revision: 285041 URL: http://llvm.org/viewvc/llvm-project?rev=285041&view=rev Log: test/CodeGen/builtins.c: reinstate #ifdef __x86_64__ around __builtin_longjmp Unadvertently removed in r285019 Modified: cfe/trunk/test/CodeGen/builtins.c

r285047 - Fix handling of %% format specifier in os_log builtins.

Author: mehdi_amini Date: Mon Oct 24 19:48:48 2016 New Revision: 285047 URL: http://llvm.org/viewvc/llvm-project?rev=285047&view=rev Log: Fix handling of %% format specifier in os_log builtins. Returning `false` was stopping the parsing of further arguments, which wasn't intended. Modified:

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini created this revision. mehdi_amini added a reviewer: dexonsmith. mehdi_amini added a subscriber: cfe-commits. We're only doing it with -flto currently, however it never "hurt" to pass it, and users that are linking without -flto can get in trouble if one of the dependency (a static lib

[PATCH] D25936: Fix format string for err_os_log_argument_to_big (currently unused)

mehdi_amini added a comment. Good catch! How did you find this? We need a test though. (I can take over if you want, as I introduced the issue in the first place) https://reviews.llvm.org/D25936 ___ cfe-commits mailing list cfe-commits@lists.llvm.or

Re: r285065 - Fix diagnostic format string for err_os_log_argument_to_big

Thanks! > On Oct 25, 2016, at 5:39 AM, Benjamin Kramer via cfe-commits > wrote: > > Author: d0k > Date: Tue Oct 25 07:39:28 2016 > New Revision: 285065 > > URL: http://llvm.org/viewvc/llvm-project?rev=285065&view=rev > Log: > Fix diagnostic format string for err_os_log_argument_to_big > > Pat

[PATCH] D25206: [Parser] Correct typo after lambda capture initializer is parsed

mehdi_amini added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:951 Init = ParseInitializer(); + Init = Actions.CorrectDelayedTyposInExpr(Init.get()); rsmith wrote: > ahatanak wrote: > > mehdi_amini wrote: > > > What happens when t

r285254 - Unconditionally pass `-lto_library` to the linker on Darwin

Author: mehdi_amini Date: Wed Oct 26 18:23:08 2016 New Revision: 285254 URL: http://llvm.org/viewvc/llvm-project?rev=285254&view=rev Log: Unconditionally pass `-lto_library` to the linker on Darwin We're only doing it with -flto currently, however it never "hurt" to pass it, and users that are li

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

This revision was automatically updated to reflect the committed changes. Closed by commit rL285254: Unconditionally pass `-lto_library` to the linker on Darwin (authored by mehdi_amini). Changed prior to commit: https://reviews.llvm.org/D25932?vs=75668&id=75963#toc Repository: rL LLVM http

[PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

mehdi_amini reopened this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. Reopen: this hasn't been committed yet apparently. @sashab : are you still interested in moving this forward? https://reviews.llvm.org/D24289

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini added a comment. Since you re-open this revision, can you clarify how this is triggering the bug you mention? It seems like the issue already existed? Repository: rL LLVM https://reviews.llvm.org/D25932 ___ cfe-commits mailing list c

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini added a comment. I just verified that I reproduce with -flto and an previous clang version. Repository: rL LLVM https://reviews.llvm.org/D25932 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mail

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

mehdi_amini added a comment. I reproduced with clang that ships with XCode by doing: ln -s `xcrun -find clang` /tmp/clang /tmp/clang /tmp/main.cpp -flto clang: warning: libLTO.dylib relative to clang installed dir not found; using 'ld' default search path instead ` Repos

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. I don't understand: 1. The motivation for this change 2. Why is this correct? Can we restart the discussion here (I'm reverting to fix the LTO build failure here: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/10737/console ) https://review

[libcxx] r285485 - Revert "Added 'inline' attribute to basic_string's destructor"

Author: mehdi_amini Date: Fri Oct 28 19:50:02 2016 New Revision: 285485 URL: http://llvm.org/viewvc/llvm-project?rev=285485&view=rev Log: Revert "Added 'inline' attribute to basic_string's destructor" This reverts commit r285456, which broke LTO bootstrap on Darwin. Modified: libcxx/trunk/in

Re: [libcxx] r285456 - Added 'inline' attribute to basic_string's destructor

Hi Adtiya, I had to revert in r285485 to unbreak this build bot: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/10737/ (LTO bootstrap of clang). Let’s iterate on the revision on Phabricator to fi

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. Trying to figure out: it seems you are trying to address what I reported here: https://llvm.org/bugs/show_bug.cgi?id=26498 ; right? > Except for inline functions, declarations with types deduced > from their initializer or return value (7.1.6.4), const > variables

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. In https://reviews.llvm.org/D25624#582752, @mehdi_amini wrote: > (The commit message is confusing, it mentions "Currently basic_string's > destructor is not getting inlined. So adding 'inline' attribute to > ~basic_string()", please add the quote of the standard and

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. FYI reproduced locally, and investigating now. https://reviews.llvm.org/D25624 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. I see a decl: declare hidden void @_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev(%"class.std::__1::basic_string"*) unnamed_addr #9 align 2 (Note the hidden which prevent from finding it in the dyib) And a use (after inlining): %1024 = ca

Re: [libcxx] r281681 - [libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility

Hi Eric, I’m trying to make sense of _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY here. If I understand correctly, such a symbol will be present and visible in the dyliib, but emitted as available_externally and visibility hidden in the client code. I don’t understand the hidden visibility part,

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. I believe the issue is _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY itself. I asked here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20161024/175454.html https://reviews.llvm.org/D25624 ___ cfe-commits maili

r285525 - Fix clang installed path to handle case where clang is invoked through a symlink

Author: mehdi_amini Date: Sun Oct 30 18:26:13 2016 New Revision: 285525 URL: http://llvm.org/viewvc/llvm-project?rev=285525&view=rev Log: Fix clang installed path to handle case where clang is invoked through a symlink This code path is used when generating the path to libLTO.dylib, which is pass

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. Before this gets re-committed, I'd like to understand why only the destructor? https://reviews.llvm.org/D25624 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. I talked with Eric on IRC, he mentioned some benchmarks were ran. I'd like to understand what was the baseline? Here we add *both* the inline keyword and the always_inline attribute. I'd like to know if there is a benchmarks that shows that always_inline is beneficia

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. In https://reviews.llvm.org/D25624#584095, @hiraditya wrote: > In https://reviews.llvm.org/D25624#583167, @mehdi_amini wrote: > > > I talked with Eric on IRC, he mentioned some benchmarks were ran. I'd like > > to understand what was the baseline? > > Here we add *b

[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

mehdi_amini added a comment. In https://reviews.llvm.org/D25624#583883, @sebpop wrote: > In https://reviews.llvm.org/D25624#583163, @mehdi_amini wrote: > > > I'd like to understand why only the destructor? > > > We have committed a patch to inline the constructor of std::string. > Do you think w

[PATCH] D23418: [analyzer] Added a reusable constraint system to the CloneDetector

mehdi_amini added a comment. (Quick stylistic comments) Comment at: include/clang/Analysis/CloneDetection.h:224 - /// \brief Searches the provided statements for clones. + /// \brief Represents a way to filter clones from a list of clone groups. /// Use

[libcxxabi] r286123 - Add some facilities to work with a git monorepo (experimental setup)

Author: mehdi_amini Date: Mon Nov 7 11:40:28 2016 New Revision: 286123 URL: http://llvm.org/viewvc/llvm-project?rev=286123&view=rev Log: Add some facilities to work with a git monorepo (experimental setup) Summary: Some changes are made to cmake, especially the addition of a new LLVM_ENABLE_PROJ

[libcxxabi] r286124 - Revert "Add some facilities to work with a git monorepo (experimental setup)"

Author: mehdi_amini Date: Mon Nov 7 11:43:08 2016 New Revision: 286124 URL: http://llvm.org/viewvc/llvm-project?rev=286124&view=rev Log: Revert "Add some facilities to work with a git monorepo (experimental setup)" This reverts commit r286123, accidentally commited while testing itself... Modif

[libcxxabi] r286161 - Fix libcxxabi CMake detection of libcxx path to handle LLVM_EXTERNAL_LIBCXX_SOURCE_DIR flag

Author: mehdi_amini Date: Mon Nov 7 16:07:43 2016 New Revision: 286161 URL: http://llvm.org/viewvc/llvm-project?rev=286161&view=rev Log: Fix libcxxabi CMake detection of libcxx path to handle LLVM_EXTERNAL_LIBCXX_SOURCE_DIR flag Differential Revision: https://reviews.llvm.org/D26364 Modified:

[libcxxabi] r286164 - Fix typo in CMakeLists.txt: provide the path to libcxx checkout and not the include subdir

Author: mehdi_amini Date: Mon Nov 7 16:16:27 2016 New Revision: 286164 URL: http://llvm.org/viewvc/llvm-project?rev=286164&view=rev Log: Fix typo in CMakeLists.txt: provide the path to libcxx checkout and not the include subdir Modified: libcxxabi/trunk/CMakeLists.txt Modified: libcxxabi/t

<    1   2   3   4   5   >