[clang] additional trees/branches

[nickdesaulniers]

per our discussion on the mailing list, I think it would be worthwhile to expand testing coverage of defconfigs from -next to mainline, and stable for 4.19, 4.14, 4.9, and maybe 4.4 (we do support arm64 and x86_64 defconfigs back to 4.4).

[broonie]

I'm unconvinced about stable as it'd seem better to expand stable coverage to include allmodconfig (which IIRC we dropped for builder resource) as at present a bunch of stable isn't getting tested at all.

[nickdesaulniers]

allmodconfig SGTM; getting some coverage of stable is important.

[broonie]

There's outstanding issues with the UI for clang reports that we probably want to address before rolling this out to more trees:

#127
kernelci/kernelci-frontend#44

It also looks like arm64 big endian boots are broken with clang, that probably needs looking at too.

[mattface]

Since boots were disabled for clang, issue #127 isn't a blocker for these additional trees and branches builds to be added.

[gctucker]

So, should we add arm64 defconfig and x86_64_defconfig on stable 4.9, 4.14, 4.19 with clang-8?

Adding allmodconfig to all the stable branches for arm64 and x86, and on top of that both for gcc and clang would mean a significant increase in build time. I think there's still enough headroom for it but we need to be sure it's really worth it and if so then we may soon need to add more builders or reduce the build coverage on other branches.

[nickdesaulniers]

Yes please, but can we move to clang-9 for all clang builds?

…

On Fri, Nov 8, 2019, 4:58 AM Guillaume Tucker ***@***.***> wrote: So, should we add arm64 defconfig and x86_64_defconfig on stable 4.9, 4.14, 4.19 with clang-8? Adding allmodconfig to all the stable branches for arm64 and x86, and on top of that both for gcc and clang would mean a significant increase in build time. I think there's still enough headroom for it but we need to be sure it's really worth it and if so then we may soon need to add more builders or reduce the build coverage on other branches. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#103?email_source=notifications&email_token=AAN5IXZV6WJP4NOASPSWLUTQSVO67A5CNFSM4H3LSSV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDRQVYY#issuecomment-551750371>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN5IX7BSKP4NEGFF5KPOS3QSVO67ANCNFSM4H3LSSVQ> .

[broonie]

Since clang-8 is supported upstream for at least arm64 and is shipping in released distributions like Debian it seems good to keep that, especially since features are being added to newer versions of clang and it's likely we'll get breakage for users if those aren't properly version guarded.

Ideally we'd be able to support multiple versions of compilers...

[gctucker]

Yes we can add clang-9, which would mean more build power of course but if it's only -next master then it should be fine. There were issues with the Docker image for clang-9 though so we would need to get that back on track first.

Sounds like it's worth a separate Github issue (for clang-9).