[PATCH] D155861: [Headers][doc] Add SHA1/SHA256 intrinsic descriptions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG775d6df6a5f2: [Headers][doc] Add SHA1/SHA256 intrinsic descriptions (authored by probinson). Herald added a project: clang. Changed prior to commit:

[PATCH] D155859: [Headers][doc] Add misc non-AVX2 intrinsic descriptions

probinson updated this revision to Diff 543075. probinson marked 4 inline comments as done. probinson added a comment. Address review comments. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155859/new/ https://reviews.llvm.org/D155859 Files: clang/lib/Headers/adxintrin.h clang/lib/

[PATCH] D155859: [Headers][doc] Add misc non-AVX2 intrinsic descriptions

probinson added inline comments. Comment at: clang/lib/Headers/rdseedintrin.h:56 +/// ELSE +/// Store16(__p, 0) +/// result := 0 pengfei wrote: > 32 Oops. Fixed. Comment at: clang/lib/Headers/rdseedintrin.h:84 +/// ELSE +/// Store16(__p,

[PATCH] D155998: Set default C++ level for Playstation(r) to C++17.

probinson added a comment. The value of a separate test for PS4/PS5 is questionable, now that it's the same as the general Clang default. Probably better to delete `lang-std-sie.cpp` and remove the UNSUPPORTED from `lang-std.cpp` ? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTI

[PATCH] D155998: Set default C++ level for PlayStation(r) to C++17.

probinson added a comment. (Also remove the now-incorrect comment from lang-std.cpp) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155998/new/ https://reviews.llvm.org/D155998 ___ cfe-commits mailing lis

[PATCH] D155998: Set default C++ level for PlayStation(r) to C++17.

probinson accepted this revision. probinson added a comment. This revision is now accepted and ready to land. Huh. It looks like someone else removed that stuff from lang-std.cpp recently. I'd have thought that would cause a failure on our bot, but whatever. LGTM. CHANGES SINCE LAST ACTION ht

[PATCH] D155539: [CUDA][HIP] Use the same default language std as C++

probinson added a comment. This change to lang-std.cpp causes it not to verify _which_ language standard is the default. It only verifies that cuda and hip don't _change_ it. If you run FileCheck on one of those output files, it would preserve that property. Repository: rG LLVM Github Monore

[PATCH] D155539: [CUDA][HIP] Use the same default language std as C++

probinson added a comment. In D155539#4524543 , @yaxunl wrote: > In D155539#4524189 , @probinson > wrote: > >> This change to lang-std.cpp causes it not to verify _which_ language >> standard is the default. It

[PATCH] D156143: Add Adrian and David as owners for debug info

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

[PATCH] D155859: [Headers][doc] Add misc non-AVX2 intrinsic descriptions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG69593aa5c054: [Headers][doc] Add misc non-AVX2 intrinsic descriptions (authored by probinson). Herald added a project: clang. Repository: rG LLVM

[PATCH] D155991: [DWARF] Make sure file entry for artificial functions has an MD5 checksum

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG7abb5fc618ce: [DWARF] Make sure file entry for artificial functions has an MD5 checksum (authored by probinson). Herald added a project: clang. Repo

[PATCH] D156127: Partially revert changes to test lang-std.cpp

probinson added inline comments. Comment at: clang/test/Preprocessor/lang-std.cpp:4 // RUN: %clang_cc1 -dM -E %s | grep __cplusplus >%T-cpp-std.txt +// RUN: cat %T-cpp-std.txt | FileCheck --check-prefix=CXX17 %s + Use `--input-file` and there's one fewer process

[PATCH] D156127: Partially revert changes to test lang-std.cpp

probinson accepted this revision. probinson added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156127/new/ https://reviews.llvm.org/D156127 ___ cfe-commits mailing list cfe-com

[PATCH] D156248: [Headers][doc] Add description of _mm256_movemask_epi8

probinson created this revision. probinson added reviewers: pengfei, RKSimon, goldstein.w.n, craig.topper. Herald added a project: All. probinson requested review of this revision. (Missed one from the list of functions I was asked to document. This really should be the last review!) https://re

[PATCH] D156248: [Headers][doc] Add description of _mm256_movemask_epi8

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG1fde372b3200: [Headers][doc] Add description of _mm256_movemask_epi8 (authored by probinson). Herald added a project: clang. Repository: rG LLVM G

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. Ping CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156571/new/ https://reviews.llvm.org/D156571 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGca1295c5a15f: [DebugInfo] Alternate (more efficient) MD5 fix (authored by probinson). Herald added a project: clang. Repository: rG LLVM Github Mo

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. Detail added in the commit message, good idea! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156571/new/ https://reviews.llvm.org/D156571 ___ cfe-commits mailing list cfe-commi

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. This patch is possibly a suspect in at least some bot failures although I'm at a loss to understand why. Perhaps I can't just blithely call getChecksum() and copy what it sends back? The ways of metadata remai

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. Thanks @DavidSpickett the patch is currently reverted. I have a revised patch coming soon and I will keep a close eye on the bots. I believe it's a string-lifetime issue and so whether it manifests is unpredictable, but we have enough different bots in the farm that it

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added inline comments. Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:423 + if (!CSInfo) { +SmallString<64> Checksum; +std::optional CSKind = In the final commit, `Checksum` is outside the `if` so that its lifetime persists to the end of the fu

[PATCH] D158614: [UBSan] Disable the function sanitizer on an execute-only target.

probinson added a comment. The PS5 bits LGTM, but as I'm not familiar with the ARM aspects I won't give final approval. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158614/new/ https://reviews.llvm.org/D158614 ___

[PATCH] D155991: [DWARF] Make sure file entry for artificial functions has an MD5 checksum

probinson added a comment. > Any memory usage measurements to check this doesn't have a significant > adverse impact by copying all the strings? Not actual measurements, no; but intuitively the size should not be much greater than the size of the filename entries in the .debug_line section for

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson created this revision. probinson added reviewers: dblaikie, nikic. probinson added a project: debug-info. Herald added a subscriber: StephenFan. Herald added a project: All. probinson requested review of this revision. Should have lower memory and time cost than D155991

[PATCH] D155991: [DWARF] Make sure file entry for artificial functions has an MD5 checksum

probinson added a comment. See https://reviews.llvm.org/D156571 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155991/new/ https://reviews.llvm.org/D155991 ___ cfe-commits mailing list cfe-commits@lists.l

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. The CU's DIFile is conjured up in CGDebugInfo::CreateCompileUnit(), and the name is derived from `-main-file-name` rather than anything SourceManager provides. Although there is a comment wondering about that. CreateCompileUnit() computes a checksum for that DIFile, b

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson updated this revision to Diff 546115. probinson added a comment. Use the main FileID instead of expensive string compares. Figured this out after staring at CreateCompileUnit for long enough. Seeding the DIFileCache with the DIFile created there made another test unhappy (difile_entry

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson added a comment. Of course this means we're rerunning MD5 on the main source file; probably can capture that from TheCU and save that cost as well. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156571/new/ https://reviews.llvm.org/D156571

[PATCH] D156571: [DebugInfo] Alternate MD5 fix, NFC

probinson updated this revision to Diff 546144. probinson added a comment. Reuse the main file's checksum instead of recalculating it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156571/new/ https://reviews.llvm.org/D156571 Files: clang/lib/CodeGen/CGDebugInfo.cpp clang/lib/CodeG

[PATCH] D153276: [clang][Interp] Reject reinterpret_cast expressions

probinson added inline comments. Comment at: clang/lib/AST/Interp/Interp.h:1761 + S.FFDiag(Loc, diag::note_constexpr_invalid_cast) + << static_cast(Kind) << S.Current->getRange(OpPC); + return false; Would you mind changing this cast from `uint8_t` to `uns

[PATCH] D153276: [clang][Interp] Reject reinterpret_cast expressions

probinson added inline comments. Comment at: clang/lib/AST/Interp/Interp.h:1761 + S.FFDiag(Loc, diag::note_constexpr_invalid_cast) + << static_cast(Kind) << S.Current->getRange(OpPC); + return false; aaron.ballman wrote: > tbaeder wrote: > > probinson wrot

[PATCH] D159054: [Driver] Removal of C_INCLUDE_DIRS feature

probinson added a comment. In D159054#4626772 , @brad wrote: > Just FYI I am not in a rush to commit this. I am posting this more so as a > means of prodding for discussion of the feature. So far nobody has popped up to say they want it. @MaskRay I pok

[PATCH] D159054: [Driver] Removal of C_INCLUDE_DIRS feature

probinson added a comment. @MaskRay thanks for the info! In D159054#4638322 , @brad wrote: > I was going to hold this over for a bit longer. 2 weeks and if no one says > anything then go ahead? The main thing to worry about, clearly, is what happens as

[PATCH] D138247: PR58819: Correct linkage and mangling of lambdas in inline static member initializers

probinson added a comment. If this is specifically for C++17, I believe Sony doesn't officially support that yet although I am checking. It looks like this is only part of the fix for #58819? The original report also had a `static int n` with an internal-linkage name. Repository: rG LLVM Gi

[PATCH] D138463: [windows-itanium] Propagate DLL storage class to Initialisation Guard Variables

probinson added a subscriber: cfe-commits. probinson added a comment. +cfe-commits CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138463/new/ https://reviews.llvm.org/D138463 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://list

[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

probinson added a comment. Hmmm I might be inclined to emit 17 and 20 only under not-strict-DWARF for v5, although it makes the logic more complicated. The codes have been allocated but AFAICT the website doesn't have the new codes listed (I looked at http://wiki.dwarfstd.org/index.php/DWARF_L

[PATCH] D137437: [lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'

probinson updated this revision to Diff 478382. probinson retitled this revision from "[lit][AIX] Convert clang tests to use 'target={{.*}}aix{{.*}}'" to "[lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'". probinson added a comment. Be consistent about using `-aix` CHANGES SINCE

[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

probinson added a comment. In D138597#3957356 , @dblaikie wrote: > In D138597#3954269 , @probinson > wrote: > >> The codes have been allocated but AFAICT the website doesn't have the new >> codes listed (I looke

[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

probinson added a comment. > They're published on the website too: https://dwarfstd.org/LanguagesV6.php (sigh) sorry, distracted by other things today. Yeah, using the v6 codes with the v6 attributes for the new ones WFM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https

[PATCH] D137437: [lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'

probinson added a comment. Lacking an LGTM from someone with AIX knowledge, I see there's a bot "clang-ppc64-aix" where I can verify that the test results haven't changed. For this review the set of tests are mostly UNSUPPORTED, except for three XFAIL. I'll let this sit a little while in case

[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

probinson added a comment. One not-yet-asked question, does gcc produce the C++17/20 codes? If so, does fstrict-dwarf affect that? The major consumers of this would be lldb (which we control) and gdb, so following gcc's lead here would seem appropriate. I can accept that listing the codes on

[PATCH] D137437: [lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG64e4d03c681a: [lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}' (authored by probinson). Changed prior to commit: https://reviews.ll

[PATCH] D137437: [lit][AIX] Convert clang tests to use 'target={{.*}}-aix{{.*}}'

probinson added a comment. The clang-ppc64-aix bot ran with these changes here and all results are as expected. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137437/new/ https://reviews.l

[PATCH] D76377: Correctly initialize the DW_AT_comp_dir attribute of Clang module skeleton CUs

probinson added inline comments. Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:2499 +DIB.createFile(Mod.getModuleName(), TheCU->getDirectory()), +TheCU->getProducer(), false, StringRef(), 0, Mod.getASTFile(), +llvm::DICompileUnit::FullDebug, Signature); --

[PATCH] D74324: Tools emit the bug report URL on crash

probinson added a comment. Hi @leonardchan Owen is on UK time so I took a look. I think Owen inadvertently put the new API in a place that is guarded by `#if ENABLE_BACKTRACES` and I'm guessing that your build has that turned off. I've posted D76893 because so

[PATCH] D69393: [RFC][DebugInfo] emit user specified address_space in dwarf

probinson added a subscriber: rsmith. probinson added a comment. In D69393#1729772 , @yonghong-song wrote: > During experimenting with linux kernel codes, I found that clang does not > allow address_space attribute for function pointers, specifically, in

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. > Want to decouple setting the DWARF version from enabling/disabling generation > of debug info. Um, why? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69822/new/ https://reviews.llvm.org/D69822 ___ cfe-commits

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added inline comments. Comment at: clang/include/clang/Driver/Options.td:2002 def gno_codeview_ghash : Flag<["-"], "gno-codeview-ghash">, Flags<[CoreOption]>; + def ginline_line_tables : Flag<["-"], "ginline-line-tables">, Flags<[CoreOption]>; Unexp

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. In D69822#1733243 , @dblaikie wrote: > In D69822#1733226 , @probinson wrote: > > > > Want to decouple setting the DWARF version from enabling/disabling > > > generation of debug info. > >

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added inline comments. Comment at: clang/include/clang/Driver/Options.td:1955 Flags<[CC1Option]>; +def fdebug_default_version: Joined<["-"], "fdebug-default-version=">, Group; def fdebug_prefix_map_EQ If this is specifically the default DWARF versi

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. In D69822#1733269 , @dblaikie wrote: > In D69822#1733262 , @probinson wrote: > > > The maze of twisty -g passages gets a new secret door. Oh well. > > > If you find this to be a significa

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1151 + || Value > 5 + || Value < 1) +TC.getDriver().Diag(diag::err_drv_invalid_int_value) dblaikie wrote: > probinson wrote: > > Clang doesn't support DWARF v1.

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. The test is in the right place, now it needs to behave more like other driver tests. Sorry if it feels like I'm whaling on you, but the driver is a bit of a peculiar beast with an atypical testing mode. Taming it is harder than it looks. Comment

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added inline comments. Comment at: clang/include/clang/Driver/Options.td:1955 Flags<[CC1Option]>; +def fdebug_default_version: Joined<["-"], "fdebug-default-version=">, Group; def fdebug_prefix_map_EQ dblaikie wrote: > probinson wrote: > > If this

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:6171 + + if (DwarfVersion == 0) +DwarfVersion = ParseDwarfDefaultVersion(getToolChain(), Args); MaskRay wrote: > lang=cpp > if (DwarfVersion == 0) { > DwarfVersion = P

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. Just a couple of typos, and I'm happy. I agree with the other reviewers on the last needed test tweaks. Comment at: clang/include/clang/Driver/Options.td:1955 Flags<[CC1Option]>; +def fdebug_default_version: Joined<["-"], "fdebug-default-version=

[PATCH] D69893: libunwind: Evaluating DWARF operation DW_OP_pick is broken

probinson added a comment. Is it tested? Intuitively I would expect DW_OP_pick to be kind of an unusual operator, unlikely to be seen in the wild. Repository: rUNW libunwind CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69893/new/ https://reviews.llvm.org/D69893

[PATCH] D69822: [clang] Add new -fdebug-default-version flag.

probinson added a comment. Sigh, one last typo. I'm happy otherwise. Comment at: clang/test/Driver/debug-default-version.c:11 +// environment, we should use codeview. You can enable dwarf, which implicitly +// disables codeview, of you can explicitly ask for both if you don't

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added inline comments. Comment at: llvm/test/DebugInfo/X86/debug-info-auto-return.ll:30 +; CHECK: DW_TAG_subprogram [7] * +; CHECK-NEXT: DW_AT_linkage_name [DW_FORM_strx1](indexed (0007) string = "_ZN7myClass7findMaxEv") +; CHECK: DW_AT_type [DW_FORM_ref4] {{.

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

probinson added a comment. In D49466#1761156 , @MaskRay wrote: > The ugly path separator pattern `{{(/|)}}` appears in 60+ tests. Can we > teach clang and other tools to > > 1. accept both `/` and `\` input In general they do, AFAIK, although it's n

[PATCH] D70537: [clang] CGDebugInfo asserts `!DT.isNull()` when compiling with debug symbols

probinson added a comment. I guess first I'm confused about why the type would be undeduced in the first place, given that it is actually instantiated. And if undeduced is correct, wouldn't we rather emit these with DW_TAG_unspecified_type? Comment at: clang/test/CodeGenCXX/p

[PATCH] D70696: [DebugInfo] Support to emit debugInfo for extern variables

probinson added a comment. For the case: cat def.c int global_var = 2; def.o should have debug info for the definition of global_var. For the case: cat noref.c extern int global_var; int main() {} I would not expect to see debug info for the declaration of global_var. For

[PATCH] D70696: [DebugInfo] Support to emit debugInfo for extern variables

probinson added a comment. In D70696#1765675 , @yonghong-song wrote: > It is just strange that gcc 7.3.1 (did not test, but maybe later gcc versions > as well) emits the debuginfo (encoded in dwarf) > even if the external variable is not used in the cur

[PATCH] D70696: [DebugInfo] Support to emit debugInfo for extern variables

probinson added a comment. In D70696#1765671 , @dblaikie wrote: > In D70696#1765637 , @probinson wrote: > > > For the case: > > > > cat ref.c > > extern int global_var; > > int main() { return global_v

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added a comment. In D70524#1771522 , @shafik wrote: > @probinson I was reading the C++ "auto" return type > issue and I can't come up > with a case where we don't have class descriptions across

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added a comment. In D70524#1772117 , @dblaikie wrote: > In D70524#1771709 , @probinson wrote: > > > In D70524#1771522 , @shafik wrote: > > > > > @probinson I was re

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added a comment. > Perhaps we should implement this mode under -fno-standalone-debug (or > something more aggressive) since "standalone" is one of the only places I can > think of where having the full class definition would be handy You'd also want it for type units, so they deduplic

[PATCH] D71185: [DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified.

probinson added a comment. Address the inline comments and LGTM. Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:866 + ? dwarf::DW_AT_dwo_name + : dwarf::DW_AT_GNU_dwo_name; NewCU.addUInt(Di

[PATCH] D71185: [DWARF5] Start emitting DW_AT_dwo_name when -gdwarf-5 is specified.

probinson accepted this revision. probinson added a comment. This revision is now accepted and ready to land. Yep LGTM. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71185/new/ https://reviews.llvm.org/D71185 ___ cfe-commits mailing list cf

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added a comment. > Hmm, maybe this feature/suggestion is broken or at least not exactly awesome > when it comes to auto-returning functions that are eventually void-returning > functions? Now the function definition has no DW_AT_type to override the > unspecified_type in the declarati

[PATCH] D71508: [DebugInfo] Duplicate file names in debug info

probinson added a comment. Do we have a similar problem if the filespec has an embedded ./ or ../ in it? I'm thinking some broader canonicalization ought to be done here. $ clang ./dir1/dir2/../dir3/file.c should resolve to dir1/dir3/file.c shouldn't it? Repository: rG LLVM Github Monorepo

[PATCH] D70537: [clang] CGDebugInfo asserts `!DT.isNull()` when compiling with debug symbols

probinson added a comment. I have to wonder if we're not being too eager to produce the debug info. It seems that the undeduced type problem arises because we're trying to produce debug info before we've really finished instantiating `value` here. But how Clang works pretty much always confus

[PATCH] D71508: [DebugInfo] Duplicate file names in debug info

probinson added a comment. In D71508#1786122 , @kamleshbhalui wrote: > In D71508#1785767 , @probinson wrote: > > > Do we have a similar problem if the filespec has an embedded ./ or ../ in > > it? > > > problems

[PATCH] D70524: Support DebugInfo generation for auto return type for C++ functions.

probinson added a comment. > "DW_TAG_unspecified_type auto" should be emitted for the function > declared/defined as auto returnning. Do you have other test cases in mind, > where above points diverges ?? The declaration would have DW_AT_type point to DW_TAG_unspecified_type, but the definitio

[PATCH] D70537: [clang] CGDebugInfo asserts `!DT.isNull()` when compiling with debug symbols

probinson added a comment. @dblaikie let me reflect this back to make sure I get it: Template members (methods or variables) would never appear in the *metadata* description of the struct; but metadata descriptions of the instances would refer back to that struct (as the scope for the instance).

[PATCH] D73261: [dwarf5] Support DebugInfo for constexpr for C++ variables and functions

probinson added a comment. I put in a lot of comments about spelling for the new parameter (constExpr, isConstexpr, isConstExpr) which should be named consistently throughout. Please do not use Constant or any variant, as that tends to mean something else. But, what I would rather see instead

[PATCH] D73261: [dwarf5] Support DebugInfo for constexpr for C++ variables and functions

probinson added a comment. In D73261#1838552 , @djtodoro wrote: > > Is it necessary to use DIFlags? I am willing to do that but generally, it > > is not welcomed because we have a limited number of DIFlags and most of > > them are currently in use. > > A

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

probinson added a comment. I don't think requiring a new option is a great user interface. In existing use cases the location of the .dwo file matches the location of the output file. Why is this one different? Repository: rC Clang https://reviews.llvm.org/D44788 __

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

probinson added a comment. In https://reviews.llvm.org/D44788#1046093, @dblaikie wrote: > In implicit ThinLTO, the object files are only temporary. > > Sort of similar to using -gsplit-dwarf when compiling straight to an > executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where >

[PATCH] D39239: [AST] Incorrectly qualified unscoped enumeration as template actual parameter.

probinson added a comment. Have you tried the GDB suite yet? If it has no problems, and we can make LLDB happy, I'm okay with it. https://reviews.llvm.org/D39239 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin

[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

probinson added inline comments. Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1558 + EmitSeparator = FieldIt->isBitField(); + } + I might not be following this correctly, but it feels like EmitSeparator will end up true if the last field is a bitfield, ev

[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

probinson added a comment. Is it possible you need to look only at the immediately preceding field, and not iterate? For example, struct zero_bitfield { char a : 8; char : 0; char b : 8; char c : 8; }; If processing `b` sees the zero-length bitfield and does the needful, the

[PATCH] D146802: [Documentation] improved documentation of diagnostic messages by explaining thier syntax and test of clang by telling which subobject is uninitialized

probinson added a comment. You are combining documentation of the syntax for defining diagnostics, and changes to the content of certain diagnostics. The LLVM project wants to see one topic per patch, so these things need to be done separately. Also, the documentation probably does not want to

[PATCH] D145803: [clang][DebugInfo] Emit DW_AT_type of preferred name if available

probinson added subscribers: wolfgangp, probinson. probinson added a comment. This is pretty different from the "always desugar to the canonical type" habit that has always been in place. Sony has done some downstream things to try to work around that in the past. @wolfgangp will remember it bet

[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

probinson added a comment. Still one question, and haven't dug into the test in detail yet. Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1552 + + auto *PreviousMDEntry = + PreviousFieldsDI.empty() ? nullptr : PreviousFieldsDI.back(); Maybe a comment here

[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

probinson accepted this revision. probinson added a comment. This revision is now accepted and ready to land. One entirely optional suggestion on the test. LGTM. Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1563 + + assert(PreviousBitfield->isBitField()); + j

[PATCH] D145173: Make section attribute and -ffunction-sections play nicely

probinson created this revision. probinson added a reviewer: MaskRay. Herald added a project: All. probinson requested review of this revision. People use -ffunction-sections to put each function into its own object-file section; this makes linker garbage-collection simpler. However, if there's an

[PATCH] D145271: [MSVC compatibility][DLLEXPORT/DLLIMPORT] Allow dllexport/dllimport for local classes

probinson added a subscriber: cfe-commits. probinson added a project: clang. probinson added a comment. I've looked at this but I'd like someone more in tune with MSVC behavior to review as well. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D145271/new/ https://reviews.llvm.org/D145271

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

probinson added a comment. See D145173 for a different tactic to solve this. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143745/new/ https://reviews.llvm.org/D143745 ___ cfe-commits mailing list cfe-commi

[PATCH] D145173: Make section attribute and -ffunction-sections play nicely

probinson abandoned this revision. probinson added a comment. I think the GC behavior with explicit section names is currently a little peculiar. For functions without a section name, -ffunction-sections allows GC to happen at the individual function level. With a section name, GC would happen

[PATCH] D153462: [Headers][doc] Add various arith/logical intrinsic descriptions to avx2intrin.h

probinson created this revision. probinson added reviewers: pengfei, RKSimon, goldstein.w.n, craig.topper. Herald added a project: All. probinson requested review of this revision. https://reviews.llvm.org/D153462 Files: clang/lib/Headers/avx2intrin.h Index: clang/lib/Headers/avx2intrin.h

[PATCH] D153462: [Headers][doc] Add various arith/logical intrinsic descriptions to avx2intrin.h

This revision was automatically updated to reflect the committed changes. Closed by commit rGbfa467bdc0e9: [Headers][doc] Add various arith/logical intrinsic descriptions to avx2intrin.h (authored by probinson). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D153576: [Headers] Fix up some conditionals

probinson created this revision. probinson added reviewers: craig.topper, RKSimon, pengfei, goldstein.w.n. Herald added a project: All. probinson requested review of this revision. While looking at adding intrinsic function descriptions, I found some oddities in the conditionals. I've fiddled with

[PATCH] D153576: [Headers] Fix up some conditionals

probinson added a comment. The Intel documentation doesn't hint that `_mulx_32` isn't available in 64-bit mode. I'm guessing gcc messed up and we copied them. CHANGES SINCE

[PATCH] D153576: [Headers] Fix up some conditionals

probinson closed this revision. probinson added a comment. Committed [[here|https://github.com/llvm/llvm-project/commit/3db8410487ce704f02ef8a175e87295d4e86c8df]] and closing manually because I forgot to put the review link in the commit message. CHANGES SINCE LAST ACTION https://reviews.ll

[PATCH] D153993: [Headers][doc] Add load/store/cmp/cvt intrinsic descriptions to avx2intrin.h

probinson added a subscriber: cfe-commits. probinson added a comment. + cfe-commits which didn't get added automatically. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153993/new/ https://reviews.llvm.org/D153993 ___ cfe-commits mailing list

[PATCH] D153993: [Headers][doc] Add load/store/cmp/cvt intrinsic descriptions to avx2intrin.h

probinson added inline comments. Comment at: clang/lib/Headers/avx2intrin.h:3474 +/// IF __M[j+31] == 1 +/// result[j+31:j] := Load32(__X+(i*4)) +/// ELSE pengfei wrote: > A more intrinsic guide format is `MEM[__X+j:j]` LoadXX is the syntax in the gather

[PATCH] D153993: [Headers][doc] Add load/store/cmp/cvt intrinsic descriptions to avx2intrin.h

probinson updated this revision to Diff 535804. probinson added a comment. s/:7/:j/ correcting bit references. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153993/new/ https://reviews.llvm.org/D153993 Files: clang/lib/Headers/avx2intrin.h Index: clang/lib/Headers/avx2intrin.h =

[PATCH] D153993: [Headers][doc] Add load/store/cmp/cvt intrinsic descriptions to avx2intrin.h

probinson added inline comments. Comment at: clang/lib/Headers/avx2intrin.h:3474 +/// IF __M[j+31] == 1 +/// result[j+31:j] := Load32(__X+(i*4)) +/// ELSE pengfei wrote: > probinson wrote: > > pengfei wrote: > > > A more intrinsic guide format is `MEM[__X

[PATCH] D152017: [DebugInfo] Add flag to only emit referenced member functions

probinson added a comment. > we might emit member function declarations for call sites in DWARF, for > instance So are you now leaning more toward wanting to emit the "used" declarations as well? I'm sure you don't want to implement it the way we did... I *think* the template parameter thing h

<    1   2   3   4   5   6   >