[flang] [clang] [flang][driver] Rename `flang-new` as `flang` (PR #74377)

rengolin wrote: The CI errors are Flang specific on Windows... Do we care about those? https://github.com/llvm/llvm-project/pull/74377 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

rengolin wrote: > @tru I'd ask @AaronBallman. My vote would be to reformat. Not as a requirement for this patch, I imagine? https://github.com/llvm/llvm-project/pull/65744 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

rengolin wrote: > Is this suggestion correct? Doesn't look right to me. I seems it's suggesting 4 spaces tabs, which isn't what we normally use. Something wrong with the clang-format job, maybe? @tru @tstellar https://github.com/llvm/llvm-project/pull/65744

[clang-tools-extra] [MLIR] Enabling Intel GPU Integration. (PR #65539)

rengolin wrote: CI failure looks like Buildkite issue? ``` $ /etc/buildkite-agent/hooks/pre-checkout --   | BUILDKITE_REPO: https://github.com/llvm/llvm-project.git   | fatal: not a git repository (or any parent up to mount point /var/lib)   | Stopping at filesystem boundary

[clang] [MLIR] Enabling Intel GPU Integration. (PR #65539)

rengolin wrote: CI failure looks like Buildkite issue? ``` $ /etc/buildkite-agent/hooks/pre-checkout --   | BUILDKITE_REPO: https://github.com/llvm/llvm-project.git   | fatal: not a git repository (or any parent up to mount point /var/lib)   | Stopping at filesystem boundary

[clang-tools-extra] [MLIR] Enabling Intel GPU Integration. (PR #65539)

rengolin wrote: > At some point it would be nice to have some design document or documentation > somewhere explaining how all these MLIR runners works, including this one. The idea is to eventually consolidate all runners into one. This PR is just another piece of the puzzle. Once we're all

[clang] [MLIR] Enabling Intel GPU Integration. (PR #65539)

rengolin wrote: > At some point it would be nice to have some design document or documentation > somewhere explaining how all these MLIR runners works, including this one. The idea is to eventually consolidate all runners into one. This PR is just another piece of the puzzle. Once we're all

Re: [llvm-dev] Phabricator Creator Pulling the Plug

On Tue, 24 Aug 2021 at 17:30, James Y Knight wrote: > Yes, the Gerrit hosting which Go uses ("googlesource.com") only permits a > google-account login as a matter of policy. But that's not a restriction of > Gerrit itself -- it can perfectly well be configured to use a github login. > Ah,

Re: [llvm-dev] Phabricator Creator Pulling the Plug

On Tue, 24 Aug 2021 at 12:49, Aaron Ballman wrote: > > A minor issue is that the messages Gerrit sends to Github are a bit > pointless "Message from PersonA: (1 comment)". It would be better if the > integration either works (like adding comments to a specific line or > updating the commits) or

Re: [llvm-dev] Phabricator Creator Pulling the Plug

On Mon, 23 Aug 2021 at 18:56, James Y Knight wrote: > If phabricator/phorge do turn out to be non-viable in the future, I think > we may want to reopen the option of moving to Gerrit for the primary > code-review platform. > > I'll note that the Golang folks are using Gerrit as their review

Re: [llvm-dev] Phabricator Creator Pulling the Plug

On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev < llvm-...@lists.llvm.org> wrote: > But unless I missed this, was there any discussion regarding the recent > "Winding Down" announcement of Phabricator? and what it might mean for us > in LLVM > I think we have our own self-hosted

r348364 - Revert: Honor -fdebug-prefix-map when creating function names for the debug info.

Author: rengolin Date: Wed Dec 5 05:56:26 2018 New Revision: 348364 URL: http://llvm.org/viewvc/llvm-project?rev=348364=rev Log: Revert: Honor -fdebug-prefix-map when creating function names for the debug info. This commit reverts r348060 and r348062 due to it breaking the AArch64 Full

[libunwind] r316991 - Merge r311574: ARM: explicitly specify the 8-byte alignment

Author: rengolin Date: Tue Oct 31 05:21:32 2017 New Revision: 316991 URL: http://llvm.org/viewvc/llvm-project?rev=316991=rev Log: Merge r311574: ARM: explicitly specify the 8-byte alignment Fixing the last libunwind failure on ARM. Modified: libunwind/branches/release_50/include/unwind.h

[libunwind] r316664 - Merging r316657: fixing libunwind tests

Author: rengolin Date: Thu Oct 26 06:53:36 2017 New Revision: 316664 URL: http://llvm.org/viewvc/llvm-project?rev=316664=rev Log: Merging r316657: fixing libunwind tests Modified: libunwind/branches/release_50/test/libunwind/test/config.py Modified:

r304697 - Revert "[sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)"

Author: rengolin Date: Mon Jun 5 02:35:45 2017 New Revision: 304697 URL: http://llvm.org/viewvc/llvm-project?rev=304697=rev Log: Revert "[sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)" This

r303996 - Revert "[OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element"

Author: rengolin Date: Fri May 26 10:32:45 2017 New Revision: 303996 URL: http://llvm.org/viewvc/llvm-project?rev=303996=rev Log: Revert "[OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element" This reverts commit r303986 as it broke all ARM and

Re: Potential self-hosting failure

On 17 May 2017 at 18:07, John Brawn wrote: > I've now tracked this down to a problem with LEApcrel rematerialization > where the rematerialized LEApcrel can address a different literal pool > to the original. I've raised https://bugs.llvm.org/show_bug.cgi?id=33074 Sounds

Re: Potential self-hosting failure

On 16 May 2017 at 18:26, John Brawn wrote: > I've managed to reproduce this, but no luck so far in figuring out > what exactly is going wrong. I'll continue looking into it tomorrow. Thanks John, I have reverted it for now on r303193, to get the bots green. cheers, --renato

Potential self-hosting failure

Hi John, It seems the LEApcrel patches have broken our self-hosting: http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1550 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1349

Re: r302750 - PR22877: When constructing an array via a constructor with a default argument

On 12 May 2017 at 20:46, Diana Picus wrote: > On 11 May 2017 at 21:14, Richard Smith wrote: >> Thanks for the revert, fixed up and recommitted in r302817. >> >> Any idea why not a single buildbot sent me any email about this? :( (A >> couple of them

r298185 - Revert "Modules: Cache PCMs in memory and avoid a use-after-free"

Author: rengolin Date: Sat Mar 18 07:31:32 2017 New Revision: 298185 URL: http://llvm.org/viewvc/llvm-project?rev=298185=rev Log: Revert "Modules: Cache PCMs in memory and avoid a use-after-free" This reverts commit r298165, as it broke the ARM builds. Removed:

Re: r296166 - clang-format: Don't leave behind temp files in -i mode on Windows, PR26125

On 24 February 2017 at 20:49, Nico Weber via cfe-commits wrote: > Author: nico > Date: Fri Feb 24 14:49:00 2017 > New Revision: 296166 > > URL: http://llvm.org/viewvc/llvm-project?rev=296166=rev > Log: > clang-format: Don't leave behind temp files in -i mode on

Re: r294862 - Hopefully fixes a compile error introduced by r294861.

On 12 February 2017 at 19:24, Aaron Ballman wrote: > Did, just that the test also needs a triple. I guess I'll do the dance > to add it and re-commit. Makes sense. Thanks! ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: r294862 - Hopefully fixes a compile error introduced by r294861.

On 11 February 2017 at 18:00, Aaron Ballman via cfe-commits wrote: > Author: aaronballman > Date: Sat Feb 11 12:00:32 2017 > New Revision: 294862 > > URL: http://llvm.org/viewvc/llvm-project?rev=294862=rev > Log: > Hopefully fixes a compile error introduced by r294861.

r294910 - Revert "Attributes on K C functions should not cause incompatible..."

Author: rengolin Date: Sun Feb 12 13:08:02 2017 New Revision: 294910 URL: http://llvm.org/viewvc/llvm-project?rev=294910=rev Log: Revert "Attributes on K C functions should not cause incompatible..." ...function type with a redeclaration having the same attribute. Fixing this introduced a

Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

Right, the other one was 292607 and has already been merged. Sorry for the confusion. We just need to merge this one and we're done. --renato On 1 February 2017 at 21:14, Renato Golin wrote: > On 1 February 2017 at 19:33, Hans Wennborg wrote: >> Also

Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

On 1 February 2017 at 19:33, Hans Wennborg wrote: > Also I'm confused, since I haven't seen anything besides r292638 > mentioned. Are there other changes besides that up for merging? I think the other commits were back-ported by other means (other PRs). Regardless, this is an

Re: [libcxx] r292607 - Don't default older GCC's to C++17, but C++14 or C++11 instead

On 26 January 2017 at 18:22, Hans Wennborg wrote: > What's the status here? Waiting for Marshall? Possibly. I can confirm this made all the problem on ARM go away with GCC 5.3 and 6.3. ___ cfe-commits mailing list

Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

On 20 January 2017 at 19:46, Eric Fiselier wrote: > This patch fixes a libc++abi test failure when compiled with GCC 5, 6, or 7. > We should merge this into 4.0 to help get `check-all` clean. Hi Eric, All good on my side, pass with GCC 5.4 and 6.3. Can you attach all commits that

r292355 - Revert "[xray] try to fix thumb buildbot"

Author: rengolin Date: Wed Jan 18 03:05:32 2017 New Revision: 292355 URL: http://llvm.org/viewvc/llvm-project?rev=292355=rev Log: Revert "[xray] try to fix thumb buildbot" This reverts commit r292268, as it didn't fix the buildbots. Modified: cfe/trunk/lib/Driver/Tools.cpp Modified:

r292268 - [xray] try to fix thumb buildbot

Author: rengolin Date: Tue Jan 17 15:37:24 2017 New Revision: 292268 URL: http://llvm.org/viewvc/llvm-project?rev=292268=rev Log: [xray] try to fix thumb buildbot Modified: cfe/trunk/lib/Driver/Tools.cpp Modified: cfe/trunk/lib/Driver/Tools.cpp URL:

Re: LLVM buildmaster will be unavailable on 1/13/17

Should we slow down, or block commits for the time being? It could be a total chaos when they get back... On 13 January 2017 at 19:16, Galina Kistanova via cfe-commits wrote: > Just a remainder. > > LLVM buildmaster will be offline today hopefully for short time due

Re: r290808 - DR1391: Check for implicit conversion sequences for non-dependent function

On 2 January 2017 at 02:42, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Sun Jan 1 20:42:17 2017 > New Revision: 290808 > > URL: http://llvm.org/viewvc/llvm-project?rev=290808=rev > Log: > DR1391: Check for implicit conversion sequences for

r290811 - Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on

Author: rengolin Date: Mon Jan 2 05:15:42 2017 New Revision: 290811 URL: http://llvm.org/viewvc/llvm-project?rev=290811=rev Log: Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as

Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

On 19 December 2016 at 12:39, Daniel Jasper wrote: > Oh, I completely understand, I am doing the same here :) Btw, this also happened: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/582 It seems Clang lost the ability to find the libstdc++: CMake

Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

On 19 December 2016 at 12:27, Daniel Jasper wrote: > I don't understand. This *is* a revert of the whole patch. My bad, your revert hadn't gone through: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/1361 Now it's green. Sorry, we're dealing with 4 different

Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

On 19 December 2016 at 11:28, Daniel Jasper via cfe-commits wrote: > I have reverted this in r290092 as it was leading to Clang crashes on the > bots and elsewhere, e.g.: > http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 Hi Daniel, Richard,

Re: [libcxxabi] r288457 - Update implementation of ABI support for throwing noexcept function pointers

It's been a while, and new patches are coming. Should we just revert this for now? --renato On 2 December 2016 at 10:13, Renato Golin wrote: > On 2 December 2016 at 02:06, Richard Smith via cfe-commits > wrote: >> Author: rsmith >> Date: Thu

Re: [libcxxabi] r288457 - Update implementation of ABI support for throwing noexcept function pointers

On 2 December 2016 at 02:06, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Thu Dec 1 20:06:53 2016 > New Revision: 288457 > > URL: http://llvm.org/viewvc/llvm-project?rev=288457=rev > Log: > Update implementation of ABI support for throwing noexcept

[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

rengolin added a comment. How does GCC behave with those arguments? Thinking back now, we may be required to follow, as the principle of least surprise has to hold. https://reviews.llvm.org/D26968 ___ cfe-commits mailing list

[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

rengolin added inline comments. Comment at: lib/Basic/Targets.cpp:5407 + Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM", + Opts.ShortEnums || Opts.ABIEnums ? "1" : "4"); labrinea wrote: > rengolin wrote: > > Isn't ABIEnums 4?

[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

rengolin added a comment. Hi Alexandros, My interpretation of `Tag_ABI_enum_size` is that value 3 is that **all** enums are 32-bit and value 4 is that only those ABI-visible (ie. public interfaces) have to be 32-bits. This is similar to the other PCS tags. So, the table is: - 0: no enums -

Re: [clang-tools-extra] r287540 - readability-redundant-declaration: Fix crash

On 21 November 2016 at 14:29, Daniel Marjamaki via cfe-commits wrote: > Author: danielmarjamaki > Date: Mon Nov 21 08:29:53 2016 > New Revision: 287540 > > URL: http://llvm.org/viewvc/llvm-project?rev=287540=rev > Log: > readability-redundant-declaration: Fix crash

[PATCH] D26464: [ARM] Fix sema check of ARM special register names

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

[PATCH] D26464: [ARM] Fix sema check of ARM special register names

rengolin added a comment. Looks like an oversight. Aren't there any tests for this? Maybe there should be one. Repository: rL LLVM https://reviews.llvm.org/D26464 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: r286815 - Improve handling of floating point literals in OpenCL to only use double precision if the target supports fp64.

On 14 November 2016 at 11:15, Neil Hickey via cfe-commits wrote: > Author: neil.hickey > Date: Mon Nov 14 05:15:51 2016 > New Revision: 286815 > > URL: http://llvm.org/viewvc/llvm-project?rev=286815=rev > Log: > Improve handling of floating point literals in OpenCL to

[PATCH] D24998: Add a new optimization option -Og

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. I agree with Keith. This is a starting point, not a final destination. As we evolve this, we can start looking at better ways to improve the debug illusion, but right now, `O1` is

Re: r285604 - [x86][inline-asm][AVX512][clang][PART-1] Introducing "k" and "Yk" constraints for extended inline assembly, enabling use of AVX512 masked vectorized instructions.

On 31 October 2016 at 17:23, Michael Zuckerman via cfe-commits wrote: > Author: mzuckerm > Date: Mon Oct 31 12:23:52 2016 > New Revision: 285604 > > URL: http://llvm.org/viewvc/llvm-project?rev=285604=rev > Log: > [x86][inline-asm][AVX512][clang][PART-1] Introducing

Re: r285027 - Fix test on non-X86 platforms

Hi Mehdi, it's also failing on aarch64: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/47 And current build was still red. Not to mention all arm bots. Maybe reverting and trying offline next time. I can help you with arm environments, if you need. Cheers, Renato On 24 Oct

Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

On 24 October 2016 at 14:09, Artem Dergachev wrote: > Strange, i'm not receiving any buildbot emails again. Will look through bots > manually next time, that doesn't sound too hard. Pushed a hotfix in r284969. The buildmaster was restarted this weekend and got all old builds

Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

On 24 October 2016 at 10:41, Artem Dergachev via cfe-commits wrote: > Author: dergachev > Date: Mon Oct 24 04:41:38 2016 > New Revision: 284960 > > URL: http://llvm.org/viewvc/llvm-project?rev=284960=rev > Log: > [analyzer] Add StdLibraryFunctions checker. Hi Artem,

[PATCH] D25842: [clang] Limit clang test to ARM and AArch64 only

rengolin accepted this revision. rengolin added a reviewer: rengolin. rengolin added a comment. This revision is now accepted and ready to land. I haven't tested with ARM and not AArch64 or vice-versa. I'm assuming you have. If so, LGTM. Thanks. https://reviews.llvm.org/D25842

Re: r284800 - DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.

On 21 October 2016 at 03:36, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Thu Oct 20 21:36:37 2016 > New Revision: 284800 > > URL: http://llvm.org/viewvc/llvm-project?rev=284800=rev > Log: > DR583, DR1512: Implement a rewrite to C++'s 'composite

r284811 - Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules."

Author: rengolin Date: Fri Oct 21 03:03:49 2016 New Revision: 284811 URL: http://llvm.org/viewvc/llvm-project?rev=284811=rev Log: Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules." This reverts commit r284800, as it failed all ARM/AArch64 bots. Removed:

[PATCH] D25842: [clang] Limit clang test to ARM only

rengolin added inline comments. Comment at: test/Frontend/gnu-mcount.c:1 +// REQUIRES: arm-registered-target + If you have ARM but not AArch64, this test will also fail. Can you use AND on REQUIRES? https://reviews.llvm.org/D25842

r284749 - [clang-cl] Fix test that shouldn't be running on non-x86

Author: rengolin Date: Thu Oct 20 12:41:08 2016 New Revision: 284749 URL: http://llvm.org/viewvc/llvm-project?rev=284749=rev Log: [clang-cl] Fix test that shouldn't be running on non-x86 The clang-cl test required x86-registered-target but it defaulted to the host's triple and AArch64 still

[PATCH] D25761: Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.

rengolin added a comment. In https://reviews.llvm.org/D25761#573903, @srhines wrote: > > I think "clang -v" will show the linker invocation, with all its flags. > > But is there a way to get a dry-run of the linker? I don't want to run > /usr/bin/ld for ARM targets. It seems like all of the

[PATCH] D25761: Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.

rengolin added a comment. In https://reviews.llvm.org/D25761#573892, @srhines wrote: > From what I can tell, there is no nice way to generate tests for Clang's > driver when producing linker flags. -### only works for the -cc1 command line > (which won't see this flag, since it is only for

Re: r284335 - [analyzer] Make MallocChecker more robust against custom redeclarations

On 16 October 2016 at 20:36, Devin Coughlin wrote: > Reverted in r284340. Hi Devin, Sometimes Clang patches break on stage 2 or test-suite, but this is not the case. I dug deeper and found that there was another commit, not showing on that range (it should have, but that's

Re: r284335 - [analyzer] Make MallocChecker more robust against custom redeclarations

On 16 October 2016 at 18:26, Devin Coughlin via cfe-commits wrote: > Author: dcoughlin > Date: Sun Oct 16 12:26:06 2016 > New Revision: 284335 > > URL: http://llvm.org/viewvc/llvm-project?rev=284335=rev > Log: > [analyzer] Make MallocChecker more robust against custom

[PATCH] D25479: Guard flag –fdenormal-fp-math with –fno-fast-math

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

[PATCH] D25479: Guard flag –fdenormal-fp-math with –fno-fast-math

rengolin added inline comments. Comment at: test/Driver/denormal-fp-math.c:4 // RUN: %clang -### -target arm-unknown-linux-gnu -c %s -fdenormal-fp-math=positive-zero -v 2>&1 | FileCheck -check-prefix=CHECK-PZ %s +// RUN: %clang -### -target arm-unknown-linux-gnu -c %s

Re: [clang-tools-extra] r283981 - [ClangTidy] Add UsingInserter and NamespaceAliaser

On 12 October 2016 at 08:59, Haojian Wu via cfe-commits wrote: > Author: hokein > Date: Wed Oct 12 02:59:54 2016 > New Revision: 283981 > > URL: http://llvm.org/viewvc/llvm-project?rev=283981=rev > Log: > [ClangTidy] Add UsingInserter and NamespaceAliaser Hi Haojian,

Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

On 11 October 2016 at 16:34, Bruno Cardoso Lopes wrote: > Thanks Renato! So, Daniel Jasper did a trick on r283853 (clang || true) to make it not fail when it returns on error. However, I wasn't able to make it return anything but 0, so I'm at odds why this fails on the

Re: r283853 - Explicitly ignore return code in test for test systems that use pipefail

On 11 October 2016 at 12:39, Daniel Jasper wrote: > Just because I don't know shell very well :). Feel free to use "not" > instead. Ah, ok. I'll reapply. :) Thanks! --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: r283853 - Explicitly ignore return code in test for test systems that use pipefail

On 11 October 2016 at 07:13, Daniel Jasper via cfe-commits wrote: > Author: djasper > Date: Tue Oct 11 01:13:18 2016 > New Revision: 283853 > > URL: http://llvm.org/viewvc/llvm-project?rev=283853=rev > Log: > Explicitly ignore return code in test for test systems that

Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

On 11 October 2016 at 10:14, Renato Golin wrote: > clang-4.0: warning: no such sysroot directory: '/FOO' [-Wmissing-sysroot] > error: unable to create target: 'No available targets are compatible > with this triple.' > 1 error generated. Reverted in r283868, as it was

r283868 - Revert "[Driver][Diagnostics] Make 'show option names' default for driver warnings"

Author: rengolin Date: Tue Oct 11 05:26:33 2016 New Revision: 283868 URL: http://llvm.org/viewvc/llvm-project?rev=283868=rev Log: Revert "[Driver][Diagnostics] Make 'show option names' default for driver warnings" This reverts commit r283827, as it's breaking all ARM/AARch64 bots. Removed:

Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

On 11 October 2016 at 01:01, Bruno Cardoso Lopes via cfe-commits wrote: > Author: bruno > Date: Mon Oct 10 19:01:22 2016 > New Revision: 283827 > > URL: http://llvm.org/viewvc/llvm-project?rev=283827=rev > Log: > [Driver][Diagnostics] Make 'show option names' default

Re: r283753 - Revert r283683 because r283680 got reverted.

On 10 October 2016 at 15:20, Nico Weber via cfe-commits wrote: > Author: nico > Date: Mon Oct 10 09:20:35 2016 > New Revision: 283753 > > URL: http://llvm.org/viewvc/llvm-project?rev=283753=rev > Log: > Revert r283683 because r283680 got reverted. Great commit

Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

On 8 October 2016 at 11:27, Michal Gorny via cfe-commits wrote: > Author: mgorny > Date: Sat Oct 8 05:27:45 2016 > New Revision: 283659 > > URL: http://llvm.org/viewvc/llvm-project?rev=283659=rev > Log: > [cmake] Split linked libraries into private & public, for

Re: [clang-tools-extra] r283534 - Fix buildbot error.

On 7 October 2016 at 13:06, Renato Golin wrote: > On 7 October 2016 at 10:23, Haojian Wu via cfe-commits > wrote: >> Author: hokein >> Date: Fri Oct 7 04:23:28 2016 >> New Revision: 283534 >> >> URL:

[clang-tools-extra] r283553 - Revert "[clang-move] Support moving multiple classes in one run."

Author: rengolin Date: Fri Oct 7 08:58:10 2016 New Revision: 283553 URL: http://llvm.org/viewvc/llvm-project?rev=283553=rev Log: Revert "[clang-move] Support moving multiple classes in one run." This reverts commit r283526 et al as it keeps randomly breaking bots, even after the commit has

Re: [clang-tools-extra] r283534 - Fix buildbot error.

On 7 October 2016 at 10:23, Haojian Wu via cfe-commits wrote: > Author: hokein > Date: Fri Oct 7 04:23:28 2016 > New Revision: 283534 > > URL: http://llvm.org/viewvc/llvm-project?rev=283534=rev > Log: > Fix buildbot error. > > The error maybe caused by the mixed

[PATCH] D25254: test-suite: Change extension used for reference outputs by Makefile-based harness so we can start improving how the CMake-based harness works without breaking the old system or the bui

rengolin added a comment. Can you expand on how you plan to add the second set of reference outputs? We already have multiple reference outputs, for example big endian vs. little endian. I was expecting you to have done a similar thing, which doesn't involve changing every single reference

[PATCH] D24998: Add a new optimization option -Og

rengolin added reviewers: echristo, dberlin, keith.walker.arm. rengolin added a comment. Hi Sylvestre, Paul's comments on the bug are still pertinent: `-Og` is not the same as `-O1`. `-Og` means for "optimised for debuggers" which is short for "preserve the debug illusion without bloating the

[PATCH] D24084: [CMake] Cleanup libunwind lookup code.

rengolin added a comment. @EricWF any comments? https://reviews.llvm.org/D24084 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D24083: [CMake] Fix libc++abi __aeabi_idiv() link error.

rengolin added a comment. In https://reviews.llvm.org/D24083#534464, @EricWF wrote: > In https://reviews.llvm.org/D24083#534459, @logan wrote: > > > One solution might be adding the `libclang_rt.builtins.${arch}.a` detection > > rules[1] to CMakeLists.txt, and manually specify > >

[PATCH] D22272: ARM: define __ARM_VFPV5__ when present.

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Hi Tim, This patch seems stale. I think neither me nor Richard have any strong feelings against this, so I'll just approve and let you decide on which solution is best. I have a mild

Re: Broken bot

Funny, git-svnrevert is buggy, I had to do it by hand, but now it's done: r282289. Let me know if you need help testing it. --renato On 23 September 2016 at 21:28, Renato Golin wrote: > Now has broken the other: > >

Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

rengolin added a subscriber: rengolin. rengolin added a comment. Folks, this commit has broken both AArch64 test-suite buildbots: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/10449 I have reverted in

Re: Broken bot

Now has broken the other: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162 But when I try to revert, git get entangled with another commit and brings a lot of unrelated changes to it. I'll continue trying to revert, but if you can do it faster, I'd appreciate. thanks!

Re: r282255 - Fix for r280064 that added options for fp denormals and exceptions.

On 23 September 2016 at 17:12, Sjoerd Meijer wrote: > I don't think I am committing at will: I thought it was okay to commit > directly because it is a simple fix (or should be) for my own previous > half-working patch, but I don't mind going through phab. A review

Re: r282255 - Fix for r280064 that added options for fp denormals and exceptions.

On 23 September 2016 at 16:21, Sjoerd Meijer via cfe-commits wrote: > Author: sjoerdmeijer > Date: Fri Sep 23 10:21:33 2016 > New Revision: 282255 > > URL: http://llvm.org/viewvc/llvm-project?rev=282255=rev > Log: > Fix for r280064 that added options for fp denormals

r282184 - [OpenBSD] Add type sign information for OpenBSD

Author: rengolin Date: Thu Sep 22 14:28:20 2016 New Revision: 282184 URL: http://llvm.org/viewvc/llvm-project?rev=282184=rev Log: [OpenBSD] Add type sign information for OpenBSD Like NetBSD, OpenBSD prefers having a consistent set of typedefs across the architectures it supports over strictly

Re: OpenBSD/arm types

On 22 September 2016 at 16:19, Mark Kettenis wrote: > No I don't. No problems. Committed in r282184. cheers, --renato ___ cfe-commits mailing list cfe-commits@lists.llvm.org

Re: OpenBSD/arm types

Hi Mark, It seems not many people have additional comments, so LGTM. Do you have commit access? cheers, --renato On 20 September 2016 at 19:41, Mark Kettenis via cfe-commits wrote: > As discussed in cfe-dev@: > > Like NetBSD, OpenBSD prefers having a consistent set

[libunwind] r281346 - [3.9.1] Merge r279871 - [ARM] Adding .arch directives around WMMX unwind code

Author: rengolin Date: Tue Sep 13 10:40:36 2016 New Revision: 281346 URL: http://llvm.org/viewvc/llvm-project?rev=281346=rev Log: [3.9.1] Merge r279871 - [ARM] Adding .arch directives around WMMX unwind code Modified: libunwind/branches/release_39/src/UnwindRegistersRestore.S

r280968 - Revert "[XRay] ARM 32-bit no-Thumb support in Clang"

Author: rengolin Date: Thu Sep 8 12:12:32 2016 New Revision: 280968 URL: http://llvm.org/viewvc/llvm-project?rev=280968=rev Log: Revert "[XRay] ARM 32-bit no-Thumb support in Clang" This reverts commit r280889, as the original LLVM commits broke the thumb buildbots. Removed:

Re: r280597 - [AVX-512] Remove masked integer mullo builtins and replace with native IR.

On 6 September 2016 at 00:27, Craig Topper wrote: > This failure doesn't make sense. It's acting like the test was updated for > r280596, but not the intrinsic header or the clang binary. That's the only > way I can think that the output IR could contain >

Re: r280597 - [AVX-512] Remove masked integer mullo builtins and replace with native IR.

On 3 September 2016 at 20:19, Craig Topper via cfe-commits wrote: > Author: ctopper > Date: Sat Sep 3 14:19:49 2016 > New Revision: 280597 > > URL: http://llvm.org/viewvc/llvm-project?rev=280597=rev > Log: > [AVX-512] Remove masked integer mullo builtins and replace

Re: [PATCH] D24083: [CMake] Fix libc++abi __aeabi_idiv() link error.

rengolin added a comment. This looks like a work around the fact that --rtlib is being ignored with --nodefaultlibs. I'm not sure that's a sane behaviour, if you explicitly specify --rtlib. https://reviews.llvm.org/D24083 ___ cfe-commits mailing

Re: [PATCH] D24084: [CMake] Cleanup libunwind lookup code.

rengolin added a comment. In https://reviews.llvm.org/D24084#530427, @logan wrote: > We can either (1) specify the path to libunwind or (2) manually download > `unwind.h` header from libunwind project and place it to `include` directory. That is a horrible dependency... I never hit it because

Re: [PATCH] D24082: [CMake] Fix libc++abi arm build w/o libunwind.

rengolin added a comment. That match would only make sense if LLVM's unwinder was forced on ARM targets, and they're most certainly not. Expecting both unwindwers to behave identically makes no sense. This fix looks good to me, but I'll let Marshall or Eric have a look first.

Re: [PATCH] D24084: [CMake] Cleanup libunwind lookup code.

rengolin added a comment. > We have to do so because we need the modified "unwind.h" from libunwind. > (Note: which is bundled with clang/gcc is not sufficient.) So, you need libunwind's sources, even if you're not building or using them, to build libc++abi? https://reviews.llvm.org/D24084

Re: r280065 - Fix for commit 280064 that break the build.

On 31 August 2016 at 11:30, Sjoerd Meijer wrote: > Regression test test/CodeGen/noexceptionsfpmath.c makes sure > -fno-trapping-math ends up as a function attribute, and I relied on that. > Flag -fno-trapping-math is used a lot in test/Driver/fast-math.c, but you are >

Re: r280065 - Fix for commit 280064 that break the build.

On 30 August 2016 at 09:56, Sjoerd Meijer via cfe-commits wrote: > Author: sjoerdmeijer > Date: Tue Aug 30 03:56:00 2016 > New Revision: 280065 > > URL: http://llvm.org/viewvc/llvm-project?rev=280065=rev > Log: > Fix for commit 280064 that break the build. Any more

Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

Thanks! On 31 August 2016 at 01:02, Richard Smith wrote: > Hopefully r280178 should fix this. > > On Tue, Aug 30, 2016 at 4:00 PM, Renato Golin > wrote: >> >> On 30 August 2016 at 22:44, Renato Golin wrote: >> > This

Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

On 30 August 2016 at 22:44, Renato Golin wrote: > This breakage was hidden by Duncan's build breakage: > > http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/11172 Also, http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/9813 Same

Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

On 30 August 2016 at 19:55, Richard Smith via cfe-commits wrote: > Author: rsmith > Date: Tue Aug 30 13:55:16 2016 > New Revision: 280133 > > URL: http://llvm.org/viewvc/llvm-project?rev=280133=rev > Log: > PR30195: Fix clang-cl attempting to precompile bogus

  1   2   3   4   >