On Tue, Mar 10, 2020 at 1:51 AM Jani Nikula <jani.nikula(a)linux.intel.com> wrote:
On Mon, 09 Mar 2020, Nick Desaulniers <ndesaulniers(a)google.com> wrote:
> On Mon, Mar 9, 2020 at 1:32 AM Jani Nikula <jani.nikula(a)linux.intel.com>
wrote:
>>
>> On Fri, 06 Mar 2020, Nick Desaulniers <ndesaulniers(a)google.com> wrote:
>> > Based on the tree, I think this report was meant to go to Jani
(cc'ed)?
>>
>> It baffles me that the build bot burns resources on building random
>> branches in my personal repositories.
>
> It uses a branch naming convention to avoid testing branches:
>
https://github.com/intel/lkp-tests/wiki/LKP-FAQ#is-there-a-way-not-to-tri...
>
> But in this case, it seems it caught a build breakage even further
> upstream, which is valuable, right?
I guess, though I usually only use it to share some half-baked
stuff. Perhaps I'll also start using it for build testing some of the
more obscure ideas. ;)
>> That said, this builds on GCC 8 just fine. Is clang not able to do this?
>
> Places that require integer constant expressions can be very subtle.
> See this recent example in i915 for example:
>
https://github.com/ClangBuiltLinux/linux/issues/918
> Sometimes reproducing also depends on some configs. In this case,
> it's not as I've fetched your branch and can repro on defconfig.
So I've been taking a crack at implementing this in Clang.
https://reviews.llvm.org/D76096 Turns out the problem is very closely
related to `constexpr` handling in C++. It seems there's already
machinery for this, but it's explicitly disabled
(
https://reviews.llvm.org/D76169) because if you have a huge array or
struct or deeply nested struct, it can take a while to verify that
every single element/member is itself a constant expression.
Further, the C standard has language about initializer lists and
constant expressions, but provides no guidance on structs being
treated as constant expressions, though it has a vague loophole about
what may be considered constant expressions. ("An implementation may
accept other forms of constant expressions."). From what I can tell,
this seems like a GNU C extension, but one that's not documented,
AFAICT. Certainly would be something the ISO WG14 could provide more
clarification on. See discussion in
https://bugs.llvm.org/show_bug.cgi?id=45157.
I'll try to push further on this, but the comments in Clang came from
the owner of the codebase, who also happens to be the ISO WG21 spec
editor, so we'll see...
Yeah, reminds me of earlier issues with GCC and Clang having different
order in certain checks and optimizations, leading to Clang warnings in
code that GCC just optimized away.
> This is definitely our bug:
https://bugs.llvm.org/show_bug.cgi?id=45157
Any idea if older GCC is also limited in this regard? What versions does
the kbuild bot test?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
--
Thanks,
~Nick Desaulniers