Gentle ping :-)

Minor review update

Address reviews, taking the « extend error function » path.

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

For reference, cross posted to https://sourceware.org/bugzilla/show_bug.cgi?id=26626

LGTM

Thanks for the recap, that's a very clarifying one.

Commited on your behalf using what I expect to be your official email address :-)

Thanks for the rely!

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

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:

This all LGTM, but I'd like an other eye on it. Maybe @Meinersbur ?

LGTM then :-)

Rebase

Take into account @nikic review.

Take review into account

In D86442#2235449, @foad wrote:

Looks good, but do we also need an equivalent of D80916 to check that passes are reporting "changed" correctly?

I'll need a contact email to preserve authorship information, can you send me one at sguelton@redhat.com? Thanks!

Sure, thanks for your patience!

Take review into account.

@nikic I'm curious about any binary/compilation time change?

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.

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?

LGTM, that's indeed a more helpful message. Thanks!

In D80707#2172200, @foad wrote:

Are you planning to pick this up again now D80916 has landed? It LGTM modulo the comments that have already been made.

LGTM, I still would appreciate @calixte feedback here.

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

Thanks!

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.

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 :-)

In D82767#2132903, @MyDeveloperDay wrote:

We may not be consistent across all of LLVM

$ find . -name '*.py' -print -exec /usr/bin/head -2 {} \; | grep "#!" | sort | uniq -c
      6 #! /usr/bin/env python
      2 #! /usr/bin/env python3
      2 #! /usr/bin/python
      1 #!/bin/env python
    133 #!/usr/bin/env python
     13 #!/usr/bin/env python3
     49 #!/usr/bin/python

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?

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