[clang] 5fee693 - [AST] Use PrintingPolicy for format string diagnosis

Author: Jessica Clarke Date: 2020-04-28T23:43:48+01:00 New Revision: 5fee6936b8b241b36fadaf0dcd962e9c9adc8a69 URL: https://github.com/llvm/llvm-project/commit/5fee6936b8b241b36fadaf0dcd962e9c9adc8a69 DIFF: https://github.com/llvm/llvm-project/commit/5fee6936b8b241b36fadaf0dcd962e9c9adc8a69.diff

[clang] [llvm] [SPARC] Support reserving arbitrary general purpose registers (PR #74927)

jrtc27 wrote: Doesn’t the ABI require you to emit magic STT_REGISTER or whatever they are symbols to mark this? https://github.com/llvm/llvm-project/pull/74927 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mail

[clang] [libc] [clang-tools-extra] [libcxx] [lldb] [llvm] [compiler-rt] [lld] [flang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

@@ -286,7 +286,33 @@ clang::analyze_format_string::ParseLengthModifier(FormatSpecifier &FS, lmKind = LengthModifier::AsInt3264; break; case 'w': - lmKind = LengthModifier::AsWide; ++I; break; + ++I; + if (I == E) return false; + if (*I == 'f

[clang-tools-extra] [clang] [llvm] [libc] [compiler-rt] [lld] [flang] [lldb] [libcxx] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

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

[clang] [llvm] [RISCV] Always emit relocations for resolved symbols and relax (PR #73793)

jrtc27 wrote: As far as I can tell this is pointless. If you want relaxation you need R_RISCV_RELAX and R_RISC_ALIGN relocations to be emitted. If you don't want relaxation you don't need these. Therefore it seems like all this does is emit a whole bunch of useless relocations for the case whe

[clang] [llvm] [RISCV] Always emit relocations for resolved symbols and relax (PR #73793)

jrtc27 wrote: > Also, we cannot trust Subtarget features here, because it may be empty in > case of LTO codegen, preventing relaxations. And that's the problem. It's vital that we have the information. Anything else is just a hack that papers over the fundamental issue. https://github.com/llv

[mlir] [polly] [clang] [libunwind] [flang] [lld] [lldb] [compiler-rt] [clang-tools-extra] [libcxxabi] [libcxx] [openmp] [libc] [llvm] Make clang report invalid target versions. (PR #75373)

@@ -786,4 +786,7 @@ def warn_android_unversioned_fallback : Warning< " directories will not be used in Clang 19. Provide a versioned directory" " for the target version or lower instead.">, InGroup>; + +def err_android_version_invalid : Error< + "Version %0 in triple %1

[llvm] [clang] [SPARC] Support reserving arbitrary general purpose registers (PR #74927)

@@ -1125,6 +1130,10 @@ Register SparcTargetLowering::getRegisterByName(const char* RegName, LLT VT, .Case("g4", SP::G4).Case("g5", SP::G5).Case("g6", SP::G6).Case("g7", SP::G7) .Default(0); + const SparcRegisterInfo *TRI = Subtarget->getRegisterInfo(); + if (!TRI->

[clang] 0e79a94 - [Utils] Support class template specializations in update_cc_test_checks

Author: Jessica Clarke Date: 2021-07-28T16:03:41+01:00 New Revision: 0e79a94836d7127a87c36fdca43ffaf6a17d8964 URL: https://github.com/llvm/llvm-project/commit/0e79a94836d7127a87c36fdca43ffaf6a17d8964 DIFF: https://github.com/llvm/llvm-project/commit/0e79a94836d7127a87c36fdca43ffaf6a17d8964.diff

[clang] 40080e7 - [Clang interpreter] Avoid storing pointers at unaligned locations

Author: Jessica Clarke Date: 2021-07-28T16:03:41+01:00 New Revision: 40080e7e7f42857c8edac4a53e476a68563f1a98 URL: https://github.com/llvm/llvm-project/commit/40080e7e7f42857c8edac4a53e476a68563f1a98 DIFF: https://github.com/llvm/llvm-project/commit/40080e7e7f42857c8edac4a53e476a68563f1a98.diff

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

jrtc27 wrote: I have always been unconvinced that these are a good idea to have / add significant value over using inline assembly. IIRC Arm has them but nobody uses them? https://github.com/llvm/llvm-project/pull/85091 ___ cfe-commits mailing list c

[clang] [clang] Define SwiftInfo for RISCVTargetCodeGenInfo (PR #82152)

jrtc27 wrote: What purpose does this serve if swiftcall doesn't work? Given the tests only test that you can produce IR from Clang, that suggests that it doesn't actually do anything useful?.. (And if it does do something useful, *that* should be being tested) https://github.com/llvm/llvm-pro

[clang] [DRAFT][RISCV] Emit arch string macro to facilitate ASM programming (PR #85063)

jrtc27 wrote: Attributes are added automatically, unless you override it with your own .attribute arch. https://github.com/llvm/llvm-project/pull/85063 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/list

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

jrtc27 wrote: > > I have always been unconvinced that these are a good idea to have / add > > significant value over using inline assembly. IIRC Arm has them but nobody > > uses them? > > Is this a comment about the general concept of builtins to produce specific > instructions or about these

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

jrtc27 wrote: > > I support adding these builtins personally, but I think we need more > > discussions on the design. We can achieve the same thing via inline > > assemblies, that's true. But, from the compiler side, inline assemblies are > > kind of barriers, we can't do a lot of optimization

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

jrtc27 wrote: You can just use `({ ... })` to achieve that same goal with inline assembly (and write doesn't even need that, you can do it with a single statement). I'm not convinced the intrinsics gain you anything. https://github.com/llvm/llvm-project/pull/85091 _

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

jrtc27 wrote: I guess my underlying point is that Arm's ACLE provides functions like __arm_rsr, but I'm not aware of them really being used, with inline assembly being the far more common alternative, so what's the real point of providing an interface that developers have already demonstrated

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -0,0 +1,22 @@ +// REQUIRES: spirv-registered-target jrtc27 wrote: Does it actually? Normally -emit-llvm works regardless of the enabled backends https://github.com/llvm/llvm-project/pull/85460 ___ cfe-commits mailin

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

https://github.com/jrtc27 commented: Some minor comments, but otherwise would be good to see this upstream. We've had this downstream in CHERI LLVM for many years and never got round to upstreaming it. https://github.com/llvm/llvm-project/pull/85460

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -0,0 +1,22 @@ +// REQUIRES: spirv-registered-target +// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm -o - %s | FileCheck %s +struct x { + double b; + long a; +}; + +void testva(int n, ...) { + __builtin_va_list ap; + __builtin_va_start(ap, n)

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -0,0 +1,22 @@ +// REQUIRES: spirv-registered-target +// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm -o - %s | FileCheck %s +struct x { + double b; + long a; +}; + +void testva(int n, ...) { + __builtin_va_list ap; + __builtin_va_start(ap, n)

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -1713,7 +1716,7 @@ def int_coro_subfn_addr : DefaultAttrsIntrinsic< ///===-- Other Intrinsics --===// // -// TODO: We should introduce a new memory kind fo traps (and other side effects +// TODO: We should introduce a new m

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -0,0 +1,22 @@ +// REQUIRES: spirv-registered-target +// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm -o - %s | FileCheck %s +struct x { jrtc27 wrote: Newline before https://github.com/llvm/llvm-project/pull/85460 __

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

jrtc27 wrote: Doesn’t AutoUpgrade automatically infer overloads? You can see a bunch of tests in this patch where the output references the overloaded intrinsics but the input is unchanged. https://github.com/llvm/llvm-project/pull/85460 ___ cfe-comm

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

jrtc27 wrote: This probably also needs to tweak LangRef https://github.com/llvm/llvm-project/pull/85460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

https://github.com/jrtc27 approved this pull request. LGTM once typo is fixed https://github.com/llvm/llvm-project/pull/85460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -1318,16 +1318,16 @@ define void @instructions.va_arg(i8* %v, ...) { %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) - ; CHECK: call void @llvm.va_start(ptr %ap2) + ; CHECK: call void @llvm.va_start.p0(ptr %ap2) va_arg i8* %ap2, i32 ; CHECK:

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

jrtc27 wrote: > I just noticed we only set EF_RISCV_RVC based on C, and not Zca. Is that a > bug? I think so; binutils sets it for both. https://github.com/llvm/llvm-project/pull/80760 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://l

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

jrtc27 wrote: > > I just noticed we only set EF_RISCV_RVC based on C, and not Zca. Is that a > > bug? > > I think so; binutils sets it for both. (R_RISCV_ALIGN can probably fail if you don't, I don't think it's just a missing optimisation) https://github.com/llvm/llvm-project/pull/80760

[clang] [lld] [llvm] [llvm-driver] Fix usage of `InitLLVM` on Windows (PR #76306)

jrtc27 wrote: llvm-driver-template.cpp.in is what should be generating the real main for Clang (and call clang_main), and that was patched in this commit. https://github.com/llvm/llvm-project/pull/76306 ___ cfe-commits mailing list cfe-commits@lists.l

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

jrtc27 wrote: That's fair. I just imagine this is going to result in people forgetting about the underlying issue and adding their own patchwork fixes to work around it in their targets, so it would be a nice motivation to fix it properly. https://github.com/llvm/llvm-project/pull/80760 __

[clang] [clang][CodeGen] Emit atomic IR in place of optimized libcalls. (PR #73176)

jrtc27 wrote: Part of that confusion comes from SPARC's own naming. V9 is the CPU, but a V9 CPU being used for 32-bit code is called V8+... https://github.com/llvm/llvm-project/pull/73176 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https:/

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

jrtc27 wrote: > By the way, is there any plan to support `CFLUSH.I.L1` in the future? Flushing the instruction cache doesn't make sense given it can never be dirty. Invalidating/discarding does, but that's just what fence.i is doing? https://github.com/llvm/llvm-project/pull/83896

[clang] [RISCV][Clang] Added builtin support for experimental Zimop extension (PR #79971)

jrtc27 wrote: Surely we should instead be defining intrinsics with actual names for the operations we know about? What's the actual use case for needing an arbitrary unnamed one? https://github.com/llvm/llvm-project/pull/79971 ___ cfe-commits mailing

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

jrtc27 wrote: > @jrtc27 does this look better now? Yes; thanks https://github.com/llvm/llvm-project/pull/83896 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

https://github.com/jrtc27 dismissed https://github.com/llvm/llvm-project/pull/83896 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [compiler-rt] [flang] [libclc] [libcxx] [lld] [lldb] [llvm] [NFC] Remove trailing whitespace across all non-test related files (PR #82838)

jrtc27 wrote: Also this is the kind of commit that should really be done by a core trusted member of the community. It's way too easy to hide something nefarious (not that I'm accusing you of that, just that we always need to be vigilant) in an 8k+ diff, and it's not much fun to review that co

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

https://github.com/jrtc27 requested changes to this pull request. These need the vendor "sf." prefix https://github.com/llvm/llvm-project/pull/83896 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

@@ -234,7 +235,7 @@ Supported .. _riscv-profiles-extensions-note: -``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, ``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, ``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscounterenw``

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

@@ -234,7 +235,7 @@ Supported .. _riscv-profiles-extensions-note: -``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, ``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, ``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscounterenw``

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

@@ -807,6 +807,9 @@ def FeatureStdExtSsccptr : SubtargetFeature<"ssccptr", "HasStdExtSsccptr", "true", "'Ssccptr' (Main memory supports page table reads)", []>; +def FeatureStdExtSscofpmf +: SubtargetFeature<"sscofpmf", "HasStdExtSscofpmf", "tru

[llvm] [clang-tools-extra] [mlir] [libc] [libcxx] [lldb] [libcxxabi] [clang] [lld] [compiler-rt] [flang] [Mips] Fix unable to handle inline assembly ends with compat-branch o… (PR #77291)

jrtc27 wrote: What assembly does GCC emit, and how does GNU as deal with that assembly? That is, how do those two tools interact in the GNU world when dealing with forbidden slots? https://github.com/llvm/llvm-project/pull/77291 ___ cfe-commits maili

[clang] [RISCV] Add -march string as Module metadata in IR. (PR #80760)

jrtc27 wrote: My thoughts on this in the past have been: 1. target-abi should really be a target-independent thing we record; its meaning depends on the target, but the ABI exists throughout LLVM as a concept regardless of the target 2. module-level target features in general likely should be

[llvm] [clang] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating the runtime into the operating system should be preferred since otherwise all thread creation and destruction would need to be intercepted by the application. -The instrumentation makes use of the p

[llvm] [clang] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating the runtime into the operating system should be preferred since otherwise all thread creation and destruction would need to be intercepted by the application. -The instrumentation makes use of the p

[clang] [clang-tools-extra] [llvm] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error< "%select{expected|'expected-no-diagnostics'}0 directive cannot follow " "%select{'expected-no-diagnostics' directive|other expected directives}0">; def err_verify_no_directives : Error< -"no expected direc

[clang-tools-extra] [llvm] [clang] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error< "%select{expected|'expected-no-diagnostics'}0 directive cannot follow " "%select{'expected-no-diagnostics' directive|other expected directives}0">; def err_verify_no_directives : Error< -"no expected direc

[clang-tools-extra] [llvm] [clang] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error< "%select{expected|'expected-no-diagnostics'}0 directive cannot follow " "%select{'expected-no-diagnostics' directive|other expected directives}0">; jrtc27 wrote: This looks like it needs templ

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

@@ -22,8 +22,8 @@ started guide `_. .. code-block:: console - cd ~/clang-llvm - git clone https://github.com/llvm/llvm-project.git + mkdir ~/clang-llvm && cd ~/clang-llvm + git clone https://github.com/llvm/llvm-p

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

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

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

https://github.com/jrtc27 approved this pull request. Thanks, this looks better now https://github.com/llvm/llvm-project/pull/71313 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

jrtc27 wrote: Though please make sure to update the PR message (which will become the commit message) before merging, as it's no longer accurate https://github.com/llvm/llvm-project/pull/71313 ___ cfe-commits mailing list cfe-commits@lists.llvm.org ht

[clang] [llvm] [RISCV] Add support for Smepmp 1.0 (PR #78489)

@@ -722,6 +722,11 @@ def FeatureStdExtSsaia "'Ssaia' (Advanced Interrupt Architecture Supervisor " "Level)", []>; +def FeatureStdExtSmepmp +: SubtargetFeature<"smepmp", "HasStdExtSmepmp", "true", + "'Smepm

[clang] [llvm] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

jrtc27 wrote: I guess Zaamo + Zacas is technically a way one could implement atomics without LR/SC? https://github.com/llvm/llvm-project/pull/77424 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

@@ -33,8 +33,3 @@ #error "__STDC_VERSION_STDINT_H__ not defined" // expected-error@-1 {{"__STDC_VERSION_STDINT_H__ not defined"}} #endif - -#include -#ifndef __STDC_VERSION_STDCKDINT_H__ -#error "__STDC_VERSION_STDCKDINT_H__ not defined" jrtc27 wrote: And thi

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

@@ -177,7 +177,7 @@ C23 Feature Support - Clang now supports ``N3007 Type inference for object definitions``. - Clang now supports which defines several macros for performing - checked integer arithmetic. + checked integer arithmetic. And it is also exposed in pre-C23

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

@@ -21,9 +21,6 @@ /* C23 7.20.1 Defines several macros for performing checked integer arithmetic*/ -#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L -#define __STDC_VERSION_STDCKDINT_H__ 202311L jrtc27 wrote: This needs to stay, `__STDC_VERSION_

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: Rebased to verify CI still passes before merging (thanks Aaron for the reverse ping) https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

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

[clang] 788c7d2 - [clang][docs] Fix documentation of -O

Author: Jessica Clarke Date: 2020-09-17T13:44:01+01:00 New Revision: 788c7d2ec11dfc868a5b03478c922dc9699c6d47 URL: https://github.com/llvm/llvm-project/commit/788c7d2ec11dfc868a5b03478c922dc9699c6d47 DIFF: https://github.com/llvm/llvm-project/commit/788c7d2ec11dfc868a5b03478c922dc9699c6d47.diff

[clang] 22215e4 - [Driver][NFC] Add explicit break to final case

Author: Jessica Clarke Date: 2021-02-23T14:17:15Z New Revision: 22215e49233861e52158fcb0b71449ac62e1b41b URL: https://github.com/llvm/llvm-project/commit/22215e49233861e52158fcb0b71449ac62e1b41b DIFF: https://github.com/llvm/llvm-project/commit/22215e49233861e52158fcb0b71449ac62e1b41b.diff LOG

[clang] 9e0d550 - [clang][NFC] Clean up whitespace in ClangOpcodesEmitter output

Author: Jessica Clarke Date: 2021-02-27T01:28:56Z New Revision: 9e0d55024d4ed776f209ee04e260bdd314854993 URL: https://github.com/llvm/llvm-project/commit/9e0d55024d4ed776f209ee04e260bdd314854993 DIFF: https://github.com/llvm/llvm-project/commit/9e0d55024d4ed776f209ee04e260bdd314854993.diff LOG

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

jrtc27 wrote: Its limitations, i.e. how in various cases it can break or change correct code, need to be documented somewhere alongside the option (ideally a disclaimer in --help's output and a longer explanation in the rendered documentation). https://github.com/llvm/llvm-project/pull/67684 _

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

jrtc27 wrote: I mean places like https://clang.llvm.org/docs/ClangCommandLineReference.html and https://clang.llvm.org/docs/UsersManual.html#command-line-options. https://github.com/llvm/llvm-project/pull/67684 ___ cfe-commits mailing list cfe-commits

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

jrtc27 wrote: Oh and https://clang.llvm.org/docs/CommandGuide/clang.html. https://github.com/llvm/llvm-project/pull/67684 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [RISCV][LLD] Add RISCV zcmt optimise in linker relaxation (PR #68551)

jrtc27 wrote: > This patch is moved from https://reviews.llvm.org/D134600 Why? That loses all the context in the Phabricator review. Keep the review there. https://github.com/llvm/llvm-project/pull/68551 ___ cfe-commits mailing list cfe-commits@lists

[clang] [RISCV][LLD] Add RISCV zcmt optimise in linker relaxation (PR #68551)

jrtc27 wrote: > > > This patch is moved from https://reviews.llvm.org/D134600 > > > > > > Why? That loses all the context in the Phabricator review. Keep the review > > there. > > yes, I will keep it there. > > But the [Phabricator shutdown > timeline](https://discourse.llvm.org/t/update-on

[clang] [clang][CodeGen] Simplify code based on opaque pointers (PR #65624)

@@ -51,14 +51,11 @@ struct CodeGenTypeCache { llvm::IntegerType *PtrDiffTy; }; - /// void* in address space 0 + /// void*, void** in address space 0 union { +llvm::PointerType *UnqualPtrTy; jrtc27 wrote: Not qualified (c.f. QualType) https://g

[clang] [clang][CodeGen] Simplify code based on opaque pointers (PR #65624)

@@ -51,14 +51,11 @@ struct CodeGenTypeCache { llvm::IntegerType *PtrDiffTy; }; - /// void* in address space 0 + /// void*, void** in address space 0 union { +llvm::PointerType *UnqualPtrTy; jrtc27 wrote: (Presumably the IR type's nomenclature h

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

@@ -1220,3 +1220,15 @@ // RUN: -march=rv64i_zve32x_zvkt1p0 -x c -E -dM %s \ // RUN: -o - | FileCheck --check-prefix=CHECK-ZVKT-EXT %s // CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}} + +// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32i -x c -E -dM %s \

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

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

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

@@ -322,6 +327,8 @@ bool RISCVTargetInfo::handleTargetFeatures(std::vector &Features, if (ISAInfo->hasExtension("zfh") || ISAInfo->hasExtension("zhinx")) HasLegalHalfType = true; + FastUnalignedAccess = llvm::is_contained(Features, "+unaligned-scalar-mem"); ---

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

@@ -0,0 +1,12 @@ +// RUN: %clang_cc1 -triple riscv64 -target-feature +v \ +// RUN: -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify +// REQUIRES: riscv-registered-target +// expected-no-diagnostics +#include jrtc27 wrote: This is shipped by Clang no

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

@@ -0,0 +1,12 @@ +// RUN: %clang_cc1 -triple riscv64 -target-feature +v \ +// RUN: -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify jrtc27 wrote: -disable-O0-optnone is pointless unless you're generating code *and* piping it to opt, but you're doing

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

https://github.com/jrtc27 requested changes to this pull request. https://github.com/llvm/llvm-project/pull/65778 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

@@ -0,0 +1,12 @@ +// RUN: %clang_cc1 -triple riscv64 -target-feature +v \ +// RUN: -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify +// REQUIRES: riscv-registered-target +// expected-no-diagnostics jrtc27 wrote: ```suggestion // expected-no-diagnost

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

https://github.com/jrtc27 review_requested https://github.com/llvm/llvm-project/pull/65778 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

@@ -0,0 +1,11 @@ +// RUN: %clang_cc1 -triple riscv64 -target-feature +v -fopenmp %s jrtc27 wrote: Commenting here rather than the commit: What happened to -fsyntax-only -verify? https://github.com/llvm/llvm-project/pull/65778

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: I've added a release note (with hopefully valid reST syntax) and made the source comment less terse as requested https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.o

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 review_requested https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: > ", where the aka will be skipped" in the commit message still doesn't make > sense to me , otherwise lgtm Comments in Clang's ASTDiagnostic use "aka" and "aka clause" synonymously, referring to the parenthesised clause in `'foo' (aka 'bar')` that is sometimes printed in diagno

[clang] [RISCV] Support target attribute for function (PR #65948)

jrtc27 wrote: Please do not move from Phabricator to GitHub for existing changes, it loses all the context that was built up from previous reviews. New changes should be proposed on GitHub but existing ones should stay put. https://github.com/llvm/llvm-project/pull/65948 __

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

jrtc27 wrote: The title isn't a proper commit subject, the tense/mood doesn't make sense https://github.com/llvm/llvm-project/pull/65483 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

@@ -3362,6 +3362,7 @@ Address CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction &CGF, break; case OMPAllocateDeclAttr::OMPLargeCapMemAlloc: case OMPAllocateDeclAttr::OMPCGroupMemAlloc: + AS = getLangASFromTargetAS(CGF.CGM.getModule().getDataLayo

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

@@ -3362,6 +3362,7 @@ Address CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction &CGF, break; case OMPAllocateDeclAttr::OMPLargeCapMemAlloc: case OMPAllocateDeclAttr::OMPCGroupMemAlloc: + AS = getLangASFromTargetAS(CGF.CGM.getModule().getDataLayo

[clang] 3450272 - [Driver][FreeBSD] Generalise lib32 handling to support arm

Author: Jessica Clarke Date: 2023-07-10T01:40:58+01:00 New Revision: 3450272fc281979388bb845a9fffb59b42cc2e7e URL: https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59b42cc2e7e DIFF: https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59b42cc2e7e.diff

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 review_requested https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 review_requested https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 opened https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 review_requested https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

https://github.com/jrtc27 review_request_removed https://github.com/llvm/llvm-project/pull/65214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

@@ -315,12 +315,16 @@ std::string JSONNodeDumper::createPointerRepresentation(const void *Ptr) { llvm::json::Object JSONNodeDumper::createQualType(QualType QT, bool Desugar) { SplitQualType SQT = QT.split(); - llvm::json::Object Ret{{"qualType", QualType::getAsString(SQT,

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: > > These are an artifact of how types are structured but serve little > > purpose, merely showing that the type is sugared in some way. For > > example, ElaboratedType's existence means struct S gets printed as > > 'struct S':'struct S' in the AST, which is unnecessary visual clutt

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

@@ -677,13 +677,18 @@ void TextNodeDumper::dumpBareType(QualType T, bool Desugar) { ColorScope Color(OS, ShowColors, TypeColor); SplitQualType T_split = T.split(); - OS << "'" << QualType::getAsString(T_split, PrintPolicy) << "'"; + std::string T_str = QualType::getAsSt

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: > So it looks like some of these changes undo some of the change introduced by > @mizvekov in some tests. Maybe @zygoloid or @AaronBallman has some more input > here. Do you have a pointer to such changes? https://github.com/llvm/llvm-project/pull/65214 _

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

jrtc27 wrote: > > > So it looks like some of these changes undo some of the change introduced > > > by @mizvekov in some tests. Maybe @zygoloid or @AaronBallman has some > > > more input here. > > > > > > Do you have a pointer to such changes? > > One of the commits is here: > [15f3cd6](htt

[clang] 74f2078 - [clang] Fix emitVoidPtrVAArg for non-zero default alloca address space

Author: Jessica Clarke Date: 2023-05-15T20:26:49+01:00 New Revision: 74f207883bc5fe2a7300c4b4f1ff080a107ab148 URL: https://github.com/llvm/llvm-project/commit/74f207883bc5fe2a7300c4b4f1ff080a107ab148 DIFF: https://github.com/llvm/llvm-project/commit/74f207883bc5fe2a7300c4b4f1ff080a107ab148.diff

  1   2   3   >