[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 https://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 (GIT_DISCOVERY_ACROSS

[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 (GIT_DISCOVERY_ACROSS

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

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

[PATCH] D152433: [ARM,AArch64] Add a full set of -mtp= options.

rengolin added a subscriber: olista01. rengolin added inline comments. Comment at: clang/include/clang/Driver/Options.td:3525 + "For AArch32: 'soft' uses a function call, or 'tpidrurw', 'tpidruro' or 'tpidrprw' use the three CP15 registers. 'cp15' is an alias for 'tpi

[PATCH] D152433: [ARM,AArch64] Add a full set of -mtp= options.

rengolin added a comment. The only minor visible difference is the removal of `read-tp-hard` option from the LLVM side, which could be used by other downstream implementations. I personally don't think this is a big deal. First, we don't promise stability on that layer, and second, it would be

[PATCH] D149946: [LoongArch] Define `ual` feature and override `allowsMisalignedMemoryAccesses`

rengolin added a reviewer: peter.smith. rengolin added a comment. Rationale and implementation make sense to me. I'll let this one sit so that other folks, including Arm, can have a look, too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149946/ne

[PATCH] D145833: Switch ABI references to env/environment

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. IIRC, "abi" used to be what Arm called, but "env" is equally good. And it it's consistent with `Triple.h`, even better. LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D141750: [docs] Add llvm & clang release notes for LoongArch

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Nice! Thanks for the detailed reporting. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141750/new/ https://reviews.llvm.org/D141750 _

[PATCH] D134638: [Clang][LoongArch] Add inline asm support for constraints k/m/ZB/ZC

rengolin accepted this revision. rengolin added a comment. Looks good, with some nits. Thanks! Comment at: llvm/lib/Target/LoongArch/LoongArchAsmPrinter.cpp:76 + // TODO: handle extra code. + if (!ExtraCode) { +const MachineOperand &BaseMO = MI->getOperand(OpNo);

[PATCH] D134157: [Clang][LoongArch] Add inline asm support for constraints f/l/I/K

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Thanks, looks good to me! I wouldn't split this in two commits. One of the benefits of having a monorepo is that we don't have to do that anymore. :) Comment at: llvm/l

[PATCH] D134157: [Clang][LoongArch] Add inline asm support for constraints f/l/I/K

rengolin added inline comments. Comment at: llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp:1958 + // constraints while the official register name is prefixed with a '$'. + // So we manually select general purpose registers here. + // For now, no need to support ABI names

[PATCH] D132285: [Clang][LoongArch] Implement ABI lowering

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. I can't vouch for your ABI correctness, but you seem to have a lot of tests covering what you claim to have implemented, so looks good to me. Thanks for opening an issue for RISC-V. Clang

[PATCH] D133109: [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

rengolin added a comment. I think we can safely say that we care less about jazelle than we care about armv1/2/3, so feel free to ignore that, too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133109/new/ https://reviews.llvm.org/D133109 ___

[PATCH] D133109: [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

rengolin accepted this revision. rengolin added a comment. Agree. Even 10 years ago we made the concerted effort not to care about pre-v4, so I'd be a little surprised if people are actually using modern clang to target those platforms. Projects that rely on it can work in the same way as gcc a

[PATCH] D132550: Changes to code ownership in clang and clang-tidy

rengolin accepted this revision. rengolin added a comment. W00t! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132550/new/ https://reviews.llvm.org/D132550 ___ cfe-commits mailing list cfe-commits@lists.

[PATCH] D130255: [Clang][LoongArch] Add initial LoongArch target and driver support

rengolin added a comment. This looks great, thanks! Exciting that we can finally go all the way from C source to LoongArch binary. The changes look good to me, other than a few nits. But please wait for a day or two for other people to review on their own time. Comment at: c

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

rengolin added a comment. In D126451#3541590 , @zixuan-wu wrote: > I don't think it is largely similar to RISCV implementation except for the > code structure and test reuse. And the test result is big different. Sorry, that's what I meant. There are no

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

rengolin added a comment. This looks good to me, but wait to make sure others see it, too. My reasons are: it is largely similar to RISCV implementation, it seems to follow what I expected of the ABI (which is similar to other targets) and has a large corpus of tests. I can't comment on the sp

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

rengolin added inline comments. Comment at: clang/test/Sema/builtin-alloca-with-align.c:32 void test8(void) { +#if defined(__csky__) __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_w

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

rengolin added inline comments. Comment at: clang/test/Sema/builtin-alloca-with-align.c:32 void test8(void) { +#if defined(__csky__) __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_w

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. In D121445#3418195 , @zixuan-wu wrote: > I have met this before because the downloading of patch will ignore empty > files. You can have a check t

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

rengolin added a comment. I just applied this to a recent HEAD and got a few warnings. Please make sure there are no new warnings on changes / new files. /home/rengolin/devel/llvm-project/llvm/lib/Target/CSKY/CSKYInstrFormats.td:658:62: warning: unused template argument: R_Z_2:pattern clas

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

rengolin added a comment. I'm surprised these tests are passing for you. Perhaps you're not building or running them all. To make sure you're running your tests, you need to build both clang and llvm (`-DLLVM_ENABLE_PROJECTS=clang`) and run ninja/make `check-all`. You can also run `lit` direct

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

rengolin added inline comments. Comment at: clang/test/Driver/csky-arch-error.c:1 +// RUN: %clang -target csky-unknown-elf -march=csky -### %s \ +// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=CSKY %s This will error out and fail the test. You need to add a

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

rengolin added a comment. I don't know enough about your toolchain requirements, but this looks good to me. Please check the clang-format warnings. If you did pass clang-format, perhaps you need to upgrade to a newer one? I won't approve just yet, to let other people review it also. ===

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, awesom

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 n

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 platf

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 versio

[PATCH] D100372: [Clang][ARM] Define __VFP_FP__ macro unconditionally

rengolin accepted this revision. rengolin added a comment. It's a weird flag, for sure, but if that's the semantics of it, than this change LGTM. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100372/new/ https://reviews.llvm.org/D100372 _

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

rengolin added inline comments. Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2089 + static const char *const M68kTriples[] = { + "m68k-linux-gnu", "m68k-unknown-linux-gnu", "m68k-suse-linux"}; + jrtc27 wrote: > rengolin wrote: > > The front-end supports

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

rengolin accepted this revision. rengolin added a comment. LGTM too, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88394/new/ https://reviews.llvm.org/D88394 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.o

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

rengolin added inline comments. Comment at: clang/include/clang/Driver/Options.td:164 +def m_m68k_Features_Group: OptionGroup<"">, + Group, DocName<"M68k">; def m_mips_Features_Group : OptionGroup<"">, craig.topper wrote: > bruno wrot

[PATCH] D88393: [cfe][M68k] (Patch 7/8) Basic Clang support

rengolin added a comment. Thanks for the changes. This looks good to me but I'll let others check again and approve. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88393/new/ https://reviews.llvm.org/D88393 ___ cfe-commits mailing list cfe-co

[PATCH] D87981: [X86] AMX programming model.

rengolin added a comment. You should at least get @craig.topper's feedback, given this is a significant change in the x86 backend. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87981/new/ https://reviews.llvm.org/D87981 __

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

rengolin added inline comments. Comment at: clang/include/clang/Driver/Options.td:3125 +foreach i = {0-4} in + def m680#i#0 : Flag<["-"], "m680"#i#"0">, Group; Same question as @RKSimon had below: Shouldn't this cover all models the back-end recognises? ===

[PATCH] D88393: [cfe][M68k] (Patch 7/8) Basic Clang support

rengolin added inline comments. Comment at: clang/lib/Basic/Targets.cpp:314 +default: + return new M68kTargetInfo(Triple, Opts); +} No support for bare-metal? Comment at: clang/lib/Basic/Targets/M68k.cpp:123 +"d0", "d1", "d2",

[PATCH] D90956: [clang][SVE] Activate macro `__ARM_FEATURE_SVE_VECTOR_OPERATORS`.

rengolin accepted this revision. rengolin added a comment. Hi @fpetrogalli, the document is so dense that it took me a while to check the macros and I was still wrong. Either I'm losing my skill to read Arm documents or folks are getting worse at writing them. Giving this is a change that only

[PATCH] D90956: [clang][SVE] Additional macros implied by `-msve-vector-bits=`.

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Simple and straightforward, with documentation! :) LGTM, thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90956/new/ https://reviews.l

[PATCH] D83088: Introduce CfgTraits abstraction

rengolin added a comment. I have read all of the comments in this review and have looked at all the other pending reviews because of this and I still see strong disagreement on the design and implementation. Unfortunately, I can't contribute with the technical discussion because there's a lot

[PATCH] D88154: Initial support for vectorization using Libmvec (GLIBC vector math library).

rengolin added inline comments. Comment at: clang/include/clang/Driver/Options.td:1564 def fveclib : Joined<["-"], "fveclib=">, Group, Flags<[CC1Option]>, -HelpText<"Use the given vector functions library">, Values<"Accelerate,MASSV,SVML,none">; +HelpText<"Use the given

[PATCH] D87338: [Driver][PGO] Driver support for de-Optimizing cold functions (PATCH 2/2)

rengolin added inline comments. Comment at: clang/docs/ClangCommandLineReference.rst:2021 + +Adds ``optnone`` attributes to functions whose instrumentation-based PGO profiling counts are equal to zero (i.e. "cold"). + Following discussions in the mailing list, I

[PATCH] D77683: [Docs] Make code review policy clearer about requested pre-commit reviews

rengolin added a comment. +1 to Chris, Mehdi and John comments. I think I get the idea, but the text is certainly not conveying that, for me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77683/new/ https://reviews.llvm.org/D77683 _

[PATCH] D65572: Fix static linking failure with --unwindlib=libunwind

rengolin added reviewers: compnerd, mstorsjo, jroelofs, theraven. rengolin added a comment. This is a tricky one which may vary depending on the libraries available on different systems. Which toolchain is this? Can you add more context? Repository: rC Clang CHANGES SINCE LAST ACTION https

[PATCH] D65404: [AArch64] Disable __ARM_FEATURE_SVE without ACLE.

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. I see, makes sense. LGTM, thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65404/new/ https://reviews.llvm.org/D65404 ___ cfe-c

[PATCH] D65404: [AArch64] Disable __ARM_FEATURE_SVE without ACLE.

rengolin added a comment. I understand (and agree with) the reasoning of this patch, but wouldn't this also make it harder to test the current behaviour? I mean, LLVM doesn't support officially SVE entirely, so there's no point in expecting anything to work for now. What is the coverage of the

[PATCH] D23610: [ARM] Add pre-defined macros for ROPI and RWPI

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Sorry for the delay, this fell out of my radar and just saw the ping now. Given it's in ACLE and there are only mechanical (obvious) changes, LGTM. I'm assuming those two parameters are al

[PATCH] D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Thanks, LGTM! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53928/new/ https://reviews.llvm.org/D53928 ___ c

[PATCH] D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions

rengolin added a comment. Herald added a subscriber: jdoerfert. Funny thing is, SVML is also only supported, AFAIK, for Intel. I agree that we should emit errors, but we should also emit a similar error on SVML. I know it's not entirely relevant to this patch, but we should keep the behaviour c

[PATCH] D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions

rengolin added a comment. @hfinkel There are changes in this patch, as well as its LLVM counterpart D53927 . Please, re-review. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53928/new/ https://reviews.llvm.org/D53928 _

[PATCH] D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions

rengolin requested changes to this revision. rengolin added a comment. This revision now requires changes to proceed. Since the previous version was approved already, I'm "requesting changes" so that we can look at it again, together with D53927 to make sure it'

[PATCH] D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions

rengolin added reviewers: rsmith, chandlerc, rnk, ABataev. rengolin added a comment. Adding clang/omp developers for proper review. Please feel free to add more. FYI, there are four main ongoing discussions on the LLVM thread (D53927 ): 1. There is collusion bet

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&view=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 bui

[PATCH] D52784: [ARM][AArch64] Pass through endianness flags to the GNU assembler

rengolin added a comment. Hi Peter, Looks ok. Why did you need to change all cmdlines to have -EL? I imagine you just need one for each case, everything else remains the default (which should still work). Also, it would be interesting to know what happens on cases like "aarch64_be -EL" et al,

[PATCH] D52595: [ARM] Alter test to account for change to armv6k default CPU

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

[PATCH] D45240: [ARM] Compute a target feature which corresponds to the ARM version.

rengolin added a subscriber: joerg. rengolin added a comment. LTO is something I never considered before in the context of the target parser, but I understand the issues are similar to what the build attributes were trying to solve, so adding more info shouldn't make it worse. However, this wil

[PATCH] D40256: [ARM] disable FPU features when using soft floating point.

rengolin added a comment. Wasn't that the mess about -mfpu=softfp? https://reviews.llvm.org/D40256 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[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&view=rev Log: Merge r311574: ARM: explicitly specify the 8-byte alignment Fixing the last libunwind failure on ARM. Modified: libunwind/branches/release_50/include/unwin

[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&view=rev Log: Merging r316657: fixing libunwind tests Modified: libunwind/branches/release_50/test/libunwind/test/config.py Modified: libunwind/branches/release_50/test/li

[PATCH] D38479: Make -mgeneral-regs-only more like GCC's

rengolin added a comment. In https://reviews.llvm.org/D38479#886587, @efriedma wrote: > 1. We don't correctly ignore inline asm clobbers for registers which aren't > allocatable (https://bugs.llvm.org/show_bug.cgi?id=30792) This looks like a different (but related) issue. That should be fixed

[PATCH] D36731: [ARM][AArch64] Cortex-A75 and Cortex-A55 tests

rengolin added a comment. I'm happy with the patch, but I'll let @SjoerdMeijer approve. https://reviews.llvm.org/D36731 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36731: [ARM][AArch64] Cortex-A75 and Cortex-A55 support

rengolin added a comment. This change seems to have nothing to do with adding core support but exposing features from CPU names. If this was required to "support" the new cores in Clang, why wasn't it needed before? If this is a new, more generic way, of getting support, shouldn't you remove

[PATCH] D35826: [Driver] Error if ARM mode was selected explicitly for M-profile CPUs.

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. This makes sense to me. LGTM. Thanks! https://reviews.llvm.org/D35826 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.ll

[PATCH] D35118: [AArch64] Add support for handling the +sve target feature

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

[PATCH] D35118: [AArch64] Add support for handling the +sve target feature

rengolin added a comment. In https://reviews.llvm.org/D35118#807712, @aemerson wrote: > In https://reviews.llvm.org/D35118#806730, @rengolin wrote: > > > @jmolloy Can you check this change, please? > > > I'm not really removing FPUMode, I'm just converting an enum to a bit field. > FPUMode, i.e.

[PATCH] D35118: [AArch64] Add support for handling the +sve target feature

rengolin added a reviewer: jmolloy. rengolin added a subscriber: jmolloy. rengolin added a comment. @jmolloy Can you check this change, please? Comment at: lib/Basic/Targets.cpp:6245 enum FPUModeEnum { -FPUMode, -NeonMode +NeonMode = (1 << 0), +SveMode = (1 <

[PATCH] D35118: [AArch64] Add support for handling the +sve target feature

rengolin added a reviewer: t.p.northover. rengolin added a subscriber: t.p.northover. rengolin added inline comments. Comment at: lib/Basic/Targets.cpp:6245 enum FPUModeEnum { -FPUMode, -NeonMode +NeonMode = (1 << 0), +SveMode = (1 << 1) Is the

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&view=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&view=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

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 nasty! > This is actual

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 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/b

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 were red at the previous change too, but some o

[PATCH] D32427: Fix float abi for SUSE ARM triples

rengolin added reviewers: compnerd, rovka, joerg. rengolin added a comment. I'm not sure this will work at all. Not because it doesn't make sense (it does), but because of several bugs in the soft vs. hard float implementation in the Triple related classes all the way to the back-end. I'm addin

[PATCH] D32347: Add support for openSUSE ARM Triples

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Ok, I see no harm in letting you work upstream, since no one should be relying on the correct behaviour on opensuse for now. LGTM. Thanks! https://reviews.llvm.org/D32347 _

[PATCH] D32347: Add support for openSUSE ARM Triples

rengolin added reviewers: rovka, compnerd. rengolin added a comment. In https://reviews.llvm.org/D32347#733475, @ismail wrote: > Yes openSUSE prefers the "hl" prefix to mean HardFloat. I'm not sure that'll do what you expect it, though. Having the "hf" at the end of the triple has some magical

[PATCH] D32347: Add support for openSUSE ARM Triples

rengolin added a comment. Nothing new here, pretty much standard. No "gnueabihf"? https://reviews.llvm.org/D32347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32132: [AArch64][clang] Pass cpu/arch information to assembler for AArch64.

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Silly omission. LGTM. Thanks! https://reviews.llvm.org/D32132 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/c

[PATCH] D31417: [OpenMP] Add support for omp simd pragmas without runtime

rengolin added a comment. Hi Graham, It looks much simpler now, thanks! I'm ok with the change, but I'd like @ABataev to confirm that the semantics is the expected one for all cases and approve. cheers, --renato Comment at: lib/Parse/ParseOpenMP.cpp:174 + case OMPD_tar

[PATCH] D31417: [OpenMP] Add support for omp simd pragmas without runtime

rengolin added a comment. In https://reviews.llvm.org/D31417#713171, @huntergr wrote: > The other alternative I thought of was to perform the filtering in > ParseOpenMP.cpp instead, but I need to figure out how to delete or skip > tokens there without cluttering up the rest of the OpenMP parsin

[PATCH] D31417: [OpenMP] Add support for omp simd pragmas without runtime

rengolin added a comment. Hi Graham, I don't know much about Clang's machinery, but would it be possible to have `-fopenmp-simd` generate the same handler, but with restrictions? I fear this slight duplication could get considerably worse as we support more and more "non-RT" OMP pragmas. Alte

[PATCH] D31178: [libcxxabi] Fix exception address alignment test for EHABI

rengolin added a comment. This looks like a simple oversight from my perspective, so looks good. But I'll let the others have a look at it, as I'm not overly familiar with libcxxabi. cheers, --renato https://reviews.llvm.org/D31178 ___ cfe-commit

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&view=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: cfe/trunk/include/clang/B

[PATCH] D30739: [OpenMP] "declare simd" for AArch64 Advanced SIMD.

rengolin added inline comments. Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:6821 + ISADataTy ISAData[] = { + {'n', 64}, // double-word Advanced SIMD + {'n', 128}, // quad-word Advanced SIMD fpetrogalli wrote: > rengolin wrote: > > No f32?

[PATCH] D30739: [OpenMP] "declare simd" for AArch64 Advanced SIMD.

rengolin added reviewers: Hahnfeld, carlo.bertolli, arpith-jacob. rengolin added a comment. Looks ok to me, but I'm not very knowledgeable in that area. Hopefully some OpenMP Clang developers I added could give you a more concrete approval. :) Comment at: lib/CodeGen/CGOpenMPR

[PATCH] D30582: [Driver] Restructure handling of -ffast-math and similar options

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Ok, with the break fix, this looks goof to me. Thanks! Comment at: lib/Driver/ToolChains/Clang.cpp:2452 + if (!HonorInfs && !HonorNans && !MathErrno && AssociativeMath &

[PATCH] D30582: [Driver] Restructure handling of -ffast-math and similar options

rengolin added inline comments. Comment at: lib/Driver/ToolChains/Clang.cpp:2452 + if (!HonorInfs && !HonorNans && !MathErrno && AssociativeMath && + ReciprocalMath && !SignedZeros && !TrappingMath && FpContract == "fast") +CmdArgs.push_back("-ffast-math");

[PATCH] D30582: [Driver] Restructure handling of -ffast-math and similar options

rengolin added inline comments. Comment at: lib/Driver/ToolChains/Clang.cpp:2320 + + for (Arg *A : Args) + { format Comment at: lib/Driver/ToolChains/Clang.cpp:2324 +{ +// Options controlling individual features +case options::OPT

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&view=rev > Log: > clang-format: Don't leave behind temp files in -i mode on Windows, PR26125 > > Fix and an

[PATCH] D30290: [libcxx][zorg] Fix no-exceptions builder configurations

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. LGTM, thanks! I'll add a local task to look into that, but with Connect coming, I'm not sure how long that will take. :) https://reviews.llvm.org/D30290 __

[PATCH] D30290: [libcxx][zorg] Fix no-exceptions builder configurations

rengolin added inline comments. Comment at: buildbot/osuosl/master/config/builders.py:1196 +lit_extra_opts={'link_flags': '"-lc++abi -lc -lm -lpthread -ldl -L/opt/llvm/lib/clang/3.9.0/lib/linux -lclang_rt.builtins-armhf"'}, +cmake_extra_opts={'LIBCXX_ENAB

[PATCH] D30290: [libcxx][zorg] Fix no-exceptions builder configurations

rengolin added inline comments. Comment at: buildbot/osuosl/master/config/builders.py:1196 +lit_extra_opts={'link_flags': '"-lc++abi -lc -lm -lpthread -ldl -L/opt/llvm/lib/clang/3.9.0/lib/linux -lclang_rt.builtins-armhf"'}, +cmake_extra_opts={'LIBCXX_ENAB

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 http://lists.llvm.org/cgi

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&view=rev > Log: > Hopefully fixes a compile error introduced by r294861. Didn't... :) http://l

r294910 - Revert "Attributes on K&R 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&view=rev Log: Revert "Attributes on K&R 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 I'm confused, since I ha

  1   2   3   4   5   >