- User Since
- Oct 10 2016, 10:44 AM (205 w, 6 d)
Fri, Sep 18
Gentle ping :-)
Minor review update
Address reviews, taking the « extend error function » path.
Thu, Sep 17
Add an extra argument to the script call, to allow for future extensions, as suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=26626
Wed, Sep 16
For reference, cross posted to https://sourceware.org/bugzilla/show_bug.cgi?id=26626
Tue, Sep 15
Thu, Sep 10
Wed, Sep 9
Tue, Sep 8
Thanks for the recap, that's a very clarifying one.
Mon, Sep 7
Commited on your behalf using what I expect to be your official email address :-)
Thanks for the rely!
Fri, Sep 4
Test case added
This fixes this build: https://firefox-ci-tc.services.mozilla.com/tasks/HwRa82dySq2_04Qth6nPQQ/runs/0/logs/https%3A%2F%2Ffirefox-ci-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FHwRa82dySq2_04Qth6nPQQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log
Wed, Sep 2
Perform masking and probing in the same location to nicely handle all combination of small/large alloc and small/large align
Take into account @cuviper review, split handling of alignment between three cases:
Tue, Sep 1
This all LGTM, but I'd like an other eye on it. Maybe @Meinersbur ?
Mon, Aug 31
LGTM then :-)
Fri, Aug 28
Thu, Aug 27
Take into account @nikic review.
Take review into account
Wed, Aug 26
Tue, Aug 25
I'll need a contact email to preserve authorship information, can you send me one at firstname.lastname@example.org? Thanks!
Sure, thanks for your patience!
Take review into account.
Mon, Aug 24
@nikic I'm curious about any binary/compilation time change?
Aug 8 2020
I have some difficulties to understand the exact scenario: if one knows at compile-time that polly is needed, why no just build it as a linked-in plugin, as suggested by @Meinersbur?
If one wants to specify a list of auto-loaded plugins at runtime, there's already several ways to do so, either through the C++ API or through CLI.
Aug 7 2020
Jul 31 2020
Added test case for large stack align
According to the doc, 'utf-8' is already the default encoding, at least on py3, but not on py2. i guess that the problem you're trying to fix?
Jul 28 2020
Jul 27 2020
LGTM, that's indeed a more helpful message. Thanks!
Jul 24 2020
Jul 23 2020
Jul 21 2020
Jul 17 2020
LGTM, I still would appreciate @calixte feedback here.
Jul 16 2020
Jul 15 2020
My understanding is that explicitly requiring python3 may make sense if the script is not backward-compatible with python2, while requiring python means the version is not important.
At the end-of-year, we should be able to harmonize shebangs to #!/usr/bin/env python3 or #!/usr/bin/env python
Fixing this to be consistent would be an improvement
Jul 14 2020
Jul 13 2020
In order to land the pass return status check before branching for LLVM-11, and given the trivial nature of that patch, I'll merge it in a day or so if there's no more activity there.
Jul 10 2020
Possible followup: shouldn't all the other Get* be flagged as const too?
Looks obviously good to me.
ping @kparzysz for the final review then :-)
Jul 9 2020
Sounds good. I can try a build on AArch64 in a bit.
Cross-compiling the test-suite for example should be relatively straight-forward, if you have a linker & libraries for the target architecture (e.g. on linux it should be easy to get the required toolchains for platforms like ARM and AArch64) https://llvm.org/docs/lnt/tests.html#cross-compiling
Hmm, where do other targets suffer from those errors? In the various backend pipelines/passes?
Jul 8 2020
Note: I had to revert this becasue I only tested X86 targe, and other targets suffer from a lot of « don't update return status » error. cc @fhahn
Take final review into account