[Mesa-dev] [PATCH 1/8] nir: Silence missing field initializer warnings for nir_src

Ian Romanick idr at freedesktop.org
Mon Dec 14 17:12:34 PST 2015


On 12/14/2015 04:39 PM, Ilia Mirkin wrote:
> On Mon, Dec 14, 2015 at 7:28 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 12/14/2015 03:38 PM, Ilia Mirkin wrote:
>>> It's a pretty standard feature of compilers to init things to 0 and
>>> not have the full structure specified like that... what compiler are
>>> you seeing these with? Can we just fix the glitch with a
>>> -Wno-stupid-warnings?
>>
>> I have observed this with several versions of GCC.
>>
>> In C, you can avoid this with a trailing comma like:
>>
>> #define NIR_SRC_INIT (nir_src) { { NULL }, }
>>
>> However, nir.h is also used in some C++ code where that doesn't help.
>>
>> To be honest, I'm not a big fan of these macros.  Without C99 designated
>> initalizers, maintaining initializers like these (or the ones in
>> src/glsl/builtin_variables.cpp) is a real pain.  We can't use those, and
>> we can't use C++ constructors.  We have no good options available. :(
>>
>> I thought about replacing them with a static inline function that
>> returns a zero-initialized struct.  The compiler should generate the
>> same code.  However, that doesn't work with uses like those in patch 3.
>>
>> I'm also a little curious why you didn't raise this issue when I sent
>> these patches out in August.  I removed the patch from the series that
>> you objected to back then.
> 
> I have absolutely no recollection of any of that. Perhaps I saw "nir"
> and thought to myself, "don't care, let them do whatever, this won't
> ever affect me". Which is a sentiment I'm happy to continue with, by
> the way.

Fair enough. :)  The patch I removed was one that removed the gl_context
parameter from a function in dd_function_table.

http://patchwork.freedesktop.org/patch/58048/

> I know that doing
> 
> x = {}
> 
> is a gcc extension, but I thought that {0} should always work (with
> enough {} nesting in case the first element is a struct). Perhaps it

{0} is, basically what we're doing now, and GCC complains about it with
-Wmissing-field-initializers or -Wextra.  When we added C-style struct
and array initializers to GLSL, we discussed adding this sort of
implicit zero initialization.  I did some digging in the C89 and C99
specs, and I have some recollection that in this case the missing fields
get undefined values... but, starting with C99, {0, } implicitly
initializes the missing fields to zero.  I also seem to recall that bit
of weirdness in C is why quite a few people were opposed to adding it to
GLSL.  This was several years ago, so my memory may not be completely
reliable.

> doesn't in C++? I could believe that, although I'd be surprised.

The initializer support in C++ intentionally quite a bit more primitive
than in C99.  The language designers want you to use constructors
whether it's the best tool for the job or not... which is why there are
no designated initializers.

> Anyways, didn't mean to stir the pot too much, just thought there
> might be a simpler way out of all this.

Well, there are. :) We just can't use them due to some combination of
MSVC, C++, and C99.

> Cheers,
> 
>   -ilia



More information about the mesa-dev mailing list