search for: jmozizgbv3rvkrsx

...llvm at ca.ibm.com>; Nemanja Ivanovic <nemanjai at ca.ibm.com> > *Subject:* Re: [llvm-dev] Flakey failure on clang-ppc64le-linux-multistage > > > > https://llvm.org/docs/CommandGuide/lit.html > <https://urldefense.com/v3/__https:/llvm.org/docs/CommandGuide/lit.html__;!!JmoZiZGBv3RvKRSx!pMM0AcKS3gRL1wx2OJk-DMZG6KNuO3f602ILYnDX01_Q_Se_K_tNOHEg9mWS8jKYBA$> > already lists %T as "parent directory of %t (not unique, deprecated, do not > use)". See also https://reviews.llvm.org/D35396 > <https://urldefense.com/v3/__https:/reviews.llvm.org/D35396__;!!JmoZiZGBv3R...

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t

Hi Scott, It's possible they've missed it, so I've explicitly CC'ed a number of the usual DWARF suspects, at least some of whom are on the standards committee. I don't have anything specific to add myself. James On Mon, 27 Apr 2020 at 15:25, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I don't know what an acceptable ping rate on an RFC is, but I also

...jai at ca.ibm.com>; > llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] Flakey failure on clang-ppc64le-linux-multistage > > > > I think that was maybe the discussion on https://reviews.llvm.org/D78245 > <https://urldefense.com/v3/__https:/reviews.llvm.org/D78245__;!!JmoZiZGBv3RvKRSx!qUxaxgSDhAK0UvjN4Fw4SZNtpJl1UErEyIr-afENDwN-PUSngxiJsLPt6J7cBGD38A$> > > > > On Thu, Sep 3, 2020 at 6:22 PM Robinson, Paul <paul.robinson at sony.com> > wrote: > > I have a vague memory that libcxx wanted it for something, and claimed it > would be hard to work arou...

Another thing to consider about your feature idea is that the output may be noisy depending on what you were hoping for. SLH tries to mitigate anything that could potentially be a problem and thus it instruments almost every branch, load, and function entry, for example. There isn't a lot of signal about what is really a gadget among the code instrumented by SLH. It really tries to be

...st in debug_ranges - maybe in all > debug sections? (doing it in other sections could break ) > 3) Revisit the discussion about using an even more 'blessed' value, > like int max-1? ( https://reviews.llvm.org/D59553<https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> ) > (I don't have links to all the recent threads about this discussion - I think D59553 > might've spawned a separate broader discussion/non-review - oh, Alexey wrote a > good summary with links to other dis...

On Mon, Apr 27, 2020 at 6:42 AM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Older releases are still available for download at releases.llvm.org; I > believe the 3.0 release was supposed to be able to read 2.x bitcode, so you > should be able to upgrade the bitcode with 3.0 tools and proceed from > there. I **think** everything since 3.0 is still readable

...- oh, > > Alexey > > >> wrote a > > >> > > >> > good summary with links to other discussions here: > > >> > > >> > https://urldefense.com/v3/__http://lists.llvm.org/pipermail/llvm- > > dev/2019-September/135068.html__;!!JmoZiZGBv3RvKRSx!sRjL4Vdx9oC8TPFhKZ- > > QbL7LtpIL-1Zdb4OydT2xVhpDTRyUixtaozLYiey_aMV0lQ$ > > >> <https://urldefense.com/v3/__http:/lists.llvm.org/pipermail/llvm- > > dev/2019- > > September/135068.html__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE > > 70_57b4_rsj1TN0qB...

...; debug sections? (doing it in other sections could break ) >> > 3) Revisit the discussion about using an even more 'blessed' value, >> >> > like int max-1? ( https://reviews.llvm.org/D59553 >> <https://urldefense.com/v3/__https:/reviews.llvm.org/D59553__;!!JmoZiZGBv3RvKRSx!r2Jqc2yEgxrb2QcQEocDHJBizj0KUKE70_57b4_rsj1TN0qB8NpBvVKtY63HSqgMOg$> >> ) >> >> > (I don't have links to all the recent threads about this discussion - I >> think D59553 >> >> > might've spawned a separate broader discussion/non-review - oh, Al...

...ogle.com>> wrote: From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730<https://urldefense.com/v3/__https:/chromium-review.googlesource.com/c/breakpad/breakpad/*/2317730__;Kw!!JmoZiZGBv3RvKRSx!ofVK1otXjQ1pPSV3TC8HS9Gwe9JwuC91OgFyvfCtZ57p55u8aHljgBgPTWYCu7N-Fg$> > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b)....

...t; > > > > R_X86_64_64 relocations in .debug_ranges are resolved to 1, ignoring > > the > > > > addend > > > > > > > > (Behavior introduced in > > > > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > > 3DkTDxuwRVwsyw$ > > > > > > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > > > > > > fdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39 > >...

...ug_ranges are resolved to 1, ignoring > >> > the > >> > > > addend > >> > > > > >> > > > (Behavior introduced in > >> > > > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > >> > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > >> > 3DkTDxuwRVwsyw$ > >> > > > > >> > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > >> > > > > >> > fdf;hp=18a3a67be3a5980998c4461b5a739e54f...

...GWPAsan(!) to the fact > that the new pass manager doesn't properly skip passes like the old pass > manager. For example, when a function is marked optnone, or when using > https://llvm.org/docs/OptBisect.html > <https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$> > . > > > > Lots of passes (e.g. SROA) will do the following under the legacy pass > manager: > > > > bool runOnFunction(Function &F) override { > if (skipFunction(F)) > retur...

...t;> > the > >> >> > > > addend > >> >> > > > > >> >> > > > (Behavior introduced in > >> >> > > > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > >> >> > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > >> >> > 3DkTDxuwRVwsyw$ > >> >> > > > > >> >> > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > >> >> > > > > >> >>...

...topher Tetreault > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uFI6EncSLawiF8_tUteK_rGAExNn6WIHz8XYhuuZ6C62D3a852NK-FDno1smmiyVQg$> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200420/9ba4384c/attachment.html>

...gt; Alex > >> >> _______________________________________________ > >> >> LLVM Developers mailing list > >> >> llvm-dev at lists.llvm.org > >> >> https://urldefense.com/v3/__https://lists.llvm.org/cgi- > bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pnSYzjQly_yuEU- > ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9hAdGQGg$ > >> > > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > llvm-dev at lists.llvm.org > >> > https://urldefense.com/v3/...

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that

...t;> >> _______________________________________________ >> >> >> LLVM Developers mailing list >> >> >> llvm-dev at lists.llvm.org >> >> >> https://urldefense.com/v3/__https://lists.llvm.org/cgi- >> bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pnSYzjQly_yuEU- >> ng7OYd8nr3h3tSYOjeCwnH7cr3hA73rA8aVlNzOfQPo9hAdGQGg$ >> >> > >> >> > _______________________________________________ >> >> > LLVM Developers mailing list >> >> > llvm-dev at lists.llvm.org >> >> > ht...

...homas _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!u8dXPx858KRkn3NJFFUKY46ZVBaBOz9jKGaTk7iC6v9IhpabzCjCnB1FRnf7DQ0Bbw$> ** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<https://urldefense.com/v3/__http:/www.graphcore.ai/priv...

So there have been several recent discussions about the issues around DWARF-agnostic linking and gc-sections, linkonce function definitions being dropped, etc - and just how much DWARF-awareness would be suitable in a linker to help with this situation. I'd like to discuss a narrower instance of this issue: Zero length gc'd/deduplicated functions. LLVM seems to at least produce zero