[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] D143745: Make section attribute and -ffunction-sections play nicely

probinson created this revision. probinson added reviewers: rjmccall, 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 t

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

probinson added a comment. This works in my simple test cases, but I'm not 100% sure it's (a) the best place to do this, or (b) the only place that needs to do this. Really we should guarantee that `comdat any` wins over `comdat nodeduplicate` in all cases. CHANGES SINCE LAST ACTION https://

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

probinson added a comment. I'm not sure I understand the linker's mechanics here. Let me say some things and you can describe my misunderstanding. - If the linker was going to discard all of section foo (in the current scheme), that means it had no reason to retain either f() or g(). In the new

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

probinson abandoned this revision. probinson added a comment. Discussion on the GCC bug has persuaded me this is not a good idea. I'll solve my user's problem a different way. @MaskRay you can close the GCC bug, it looks like I can't do it myself. CHANGES SINCE LAST ACTION https://reviews.ll

[PATCH] D144188: Tighten up a modules test

probinson created this revision. probinson added a reviewer: ChuanqiXu. Herald added a project: All. probinson requested review of this revision. https://reviews.llvm.org/D144188 Files: clang/test/CXX/module/basic/basic.def.odr/p4.cppm Index: clang/test/CXX/module/basic/basic.def.odr/p4.cppm

[PATCH] D144188: Tighten up a modules test

probinson added a comment. I looked at this test only because it caused a merge conflict downstream. While it does work, it will not catch some kinds of mistakes; by being less specific in the "not" checks, it will catch more potential problems. Comment at: clang/test/CXX/mod

[PATCH] D144188: Tighten up a modules test

This revision was automatically updated to reflect the committed changes. Closed by commit rG17a90f1196c1: Tighten up a modules test (authored by probinson). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144188/new/ ht

[PATCH] D144586: [PS4/PS5] Specify no or

probinson created this revision. probinson added a reviewer: aaron.ballman. Herald added a project: All. probinson requested review of this revision. We've never provided these headers so set the preprocessor toggles to reflect that. https://reviews.llvm.org/D144586 Files: clang/lib/Basic/Tar

[PATCH] D144586: [PS4/PS5] Specify no or

probinson added a comment. That's correct, I do see in our SDK. I don't see a need for a release note; we're not actually removing anything that we used to support. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144586/new/ https://reviews.llvm.org/D144586 ___

[PATCH] D144586: [PS4/PS5] Specify no or

This revision was automatically updated to reflect the committed changes. Closed by commit rG32d441bfb4f3: [PS4/PS5] Specify no or (authored by probinson). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[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] D150114: [Headers][doc] Add "add/sub/mul" intrinsic descriptions to avx2intrin.h

probinson marked an inline comment as done. probinson added inline comments. Comment at: clang/lib/Headers/avx2intrin.h:412 +///vectors of [16 x i16] and returns the lower 16 bits of each difference +///in an element of the [16 x i16] result (overflow is ignored). +///

[PATCH] D150114: [Headers][doc] Add "add/sub/mul" intrinsic descriptions to avx2intrin.h

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. probinson marked an inline comment as done. Closed by commit rGd8291908ef49: [Headers][doc] Add add/sub/mul intrinsic descriptions to avx2intrin.h (authored by probinso

[PATCH] D151749: [Headers][doc] Add "shuffle-like" intrinsic descriptions to avx2intrin.h

probinson created this revision. probinson added reviewers: RKSimon, pengfei, goldstein.w.n, craig.topper. Herald added a project: All. probinson requested review of this revision. (Time to look for the next round of embarrassing mistakes...) https://reviews.llvm.org/D151749 Files: clang/lib/

[PATCH] D151749: [Headers][doc] Add "shuffle-like" intrinsic descriptions to avx2intrin.h

probinson updated this revision to Diff 526782. probinson added a comment. Update some SATURATEx to SATURATExU CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151749/new/ https://reviews.llvm.org/D151749 Files: clang/lib/Headers/avx2intrin.h Index: clang/lib/Headers/avx2intrin.h

[PATCH] D151749: [Headers][doc] Add "shuffle-like" intrinsic descriptions to avx2intrin.h

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGe5399f1d7cab: [Headers][doc] Add shuffle-like intrinsic descriptions to avx2intrin.h (authored by probinson). Herald added a project: clang. Changed

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

probinson added a comment. I'm traveling but will look at this on Monday. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152017/new/ https://reviews.llvm.org/D152017 ___ cfe-commits mailing list cfe-commi

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

probinson added a comment. I experimented with this. Looks like it emits info only for //defined// methods, and not //used// methods. That is, if you change the test to say `void t1::f1() { f2(); }` you get DWARF for f1 but not f2. The way Sony does it, you get DWARF for f1 and f2. (Neither case

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

probinson added a comment. In D152017#4397113 , @dblaikie wrote: > What's the particular goal/value in including called-but-not-defined > functions? Are your users generally building only parts of their program with > debug info & you want it to be comp

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

probinson added a comment. My debugger guy says "this shouldn't be a problem." Given that, my request is that `-gincomplete-types` should be default-true for `DebuggerTuning == SCE` if you want to commit this; otherwise I'll redo our downstream patch to match yours. Repository: rG LLVM Gith

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

probinson added a comment. I have to say I'm not super excited about "-gincomplete-types" given that "incomplete type" means something different to a C++ user. "-gdefined-methods-only" ? reads awkwardly in the no- form. "-gsuppress-undefined-methods" ? which is similar to what we called it. "-gu

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

probinson added a comment. Oh, `-fstandalone-debug` should override this? In the Sony implementation, it does. (Sorry for not remembering that sooner.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152017/new/ https://reviews.llvm.org/D152017 ___

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

probinson added a comment. Could always go with `-gsuppress-undefined-methods` if you're not happy about default-on options. I don't have a strong opinion. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152017/new/ https://reviews.llvm.org/D152017

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5596 + DefaultedSMFArePOD = false; + } + Does this mean `-fclang-abi-compat` will override the PS4/Darwin special case? I think we don't want to do that. Repository: rG

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5596 + DefaultedSMFArePOD = false; + } + dblaikie wrote: > probinson wrote: > > Does this mean `-fclang-abi-compat` will override the PS4/Darwin special > > case? I think w

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5596 + DefaultedSMFArePOD = false; + } + dblaikie wrote: > probinson wrote: > > dblaikie wrote: > > > probinson wrote: > > > > Does this mean `-fclang-abi-compat` will overri

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

probinson added a comment. I'm in the middle of upstreaming PS5 support and I still didn't think of this... doh! Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5588 + bool DefaultedSMFArePOD = !RawTriple.isPS4() && !RawTriple.isOSDarwin(); + `isPS4()` =>

[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] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson created this revision. probinson added reviewers: uweigand, Kai. Herald added a project: All. probinson requested review of this revision. Herald added projects: clang, LLVM. Herald added subscribers: llvm-commits, cfe-commits. Part of the project to eliminate special handling for triple

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson added a comment. The changes in this patch assume that there aren't any possible suffixes after the `-zos` part of the triple (no version numbers, like you might find with darwin or macos, and nothing like `-elf` or `-eabi` like some targets have). If there are suffixes, I'll happily

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

probinson added a comment. LGTM. I agree with the commentary in the test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138597/new/ https://reviews.llvm.org/D138597 ___ cfe-commits mailing list cfe-comm

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

probinson added a comment. Oh, right, PS4 defaults to C99. It's okay with me if you make those two unsupported for PS4. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D138597/new/ https://reviews.llvm.org/D138597 __

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson added a comment. In D139444#3978189 , @uweigand wrote: > In D139444#3975182 , @probinson > wrote: > >> The changes in this patch assume that there aren't any possible suffixes >> after the `-zos` part

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson updated this revision to Diff 481421. probinson added a comment. Add trailing '{{.*}}' as requested. Have not changed the encoding.ll test, waiting on @uweigand about correct value to test in Python. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139444/new/ https://reviews.ll

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson added a comment. I suppose we could temporarily add a test that does ; REQUIRES: target={{.*}}-zos ; RUN: %python -c 'import platform; print(platform.system())' && false and see what gets printed. Searching the buildbot console page for 'zos' turns up nothing; 's390' turns up cla

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson updated this revision to Diff 482180. probinson added a comment. Herald added a subscriber: delcypher. Define 'system-zos' and use it in the one test that needs it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139444/new/ https://reviews.llvm.org/D139444 Files: clang/test/

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

probinson added a comment. Thanks @Kai and @uweigand, good to know a z/OS bot is in the works. Hope this patch now meets your needs. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139444/new/ https://reviews.llvm.org/D139444 ___ cfe-commits m

[PATCH] D139444: [ZOS] Convert tests to check 'target={{.*}}-zos'

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG7793e676514b: [ZOS] Convert tests to check 'target={{.*}}-zos{{.*}}' (authored by probinson). Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D138675: [flang] Add -ffast-math and -Ofast

probinson added a comment. See D139967 for why `UNSUPPORTED: powerpc` didn't work. That patch will put it back, and also update the lit config so the check will work now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.

[PATCH] D139953: [llvm][DebugInfo] Backport DW_AT_default_value for template args

probinson added a comment. > IIUC the labels have to match a line in the file uniquely, which the DW_TAGs > wouldn't CHECK-LABEL doesn't have to match a line in the file uniquely. What happens is that all the -LABEL directives are processed first, in order, subdividing the input text into regi

[PATCH] D139953: [llvm][DebugInfo] Backport DW_AT_default_value for template args

probinson added a comment. > CHECK-LABEL doesn't have to match a line in the file uniquely. I mean, it's good practice if they do match uniquely; that way you don't get excessively confusing results when the output changes, and things start matching where you didn't expect. But it's not a requ

[PATCH] D133191: Driver test: remove `REQUIRES: x86-registered-target` and set `--sysroot=""` to support clang with `DEFAULT_SYSROOT`.

probinson closed this revision. probinson added a comment. Closing this for @MaggieYi the commit message didn't cite the Phabricator review. https://github.com/llvm/llvm-project/commit/5de4d97a00b2a5d710892e96d77810784fd2cd5c Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION ht

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

probinson added a reviewer: probinson. probinson added a comment. > Yeah, but it seems that it is not possible to use lld for PS4 It's correct that PS4 does not use lld. PS5 does use lld (under a different name). But, we don't use addLTOOptions() for either PS4 or PS5, so this patch doesn't af

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

probinson added a comment. I'm happy if @dblaikie is happy. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:515 +// +// And as @dblaikie noted, this solution is far from perfert, better to +// encode it into IR metadata, but this may not worth it, since looks

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

probinson added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:515 +// +// But note, this solution is far from perfert, better to encode it into IR +// metadata, but this may not worth it, since looks like aranges on the way T

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

probinson added a comment. > we don't use addLTOOptions() for either PS4 or PS5, so this patch doesn't > affect (or help) them. I'm okay with saying we'll need to deal with that case > separately. FTR, I've raised an internal ticket about this, and someone from Sony will handle it. Repositor

[PATCH] D133875: [clang] fix generation of .debug_aranges with LTO (resubmit)

probinson added inline comments. Comment at: clang/test/Driver/debug-options-aranges.c:7 +// RUN: %clang -### -g -target x86_64-linux -flto=thin -fuse-ld=lld -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=PLUGIN_GARANGE %s +// GARANGE: -generate-arange-section +// PLUGIN_GARA

[PATCH] D147655: Implement mangling rules for C++20 concepts and requires-expressions.

probinson added a comment. Hi @rsmith, > these two different templates would have the same mangling: template T returnit() {return I;}; template T returnit() { return I; } I tried compiling `long foo() { return returnit(); }` with these two templates, and got different manglings. `_Z8re

[PATCH] D147655: Implement mangling rules for C++20 concepts and requires-expressions.

probinson added a comment. > You need to do `returnit`. Doh! Thanks. Those two instantiations could have different function bodies, but would have the same mangled name. Got it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147655/new/ https://re

<    1   2   3   4   5   6