From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Marek Olšák" <maraeo@gmail.com>,
"Emil Velikov" <emil.l.velikov@gmail.com>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers
Date: Mon, 18 Jan 2016 17:51:28 +0200 [thread overview]
Message-ID: <87mvs2x4vz.fsf@intel.com> (raw)
In-Reply-To: <CAAxE2A7dNCMeNyE55uia_PKNbyouCXX8Tn0JPbSYuhfkvbNEJA@mail.gmail.com>
On Mon, 18 Jan 2016, Marek Olšák <maraeo@gmail.com> wrote:
> On Mon, Jan 18, 2016 at 3:45 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 15 January 2016 at 17:24, Marek Olšák <maraeo@gmail.com> wrote:
>>> On Fri, Jan 15, 2016 at 12:12 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> On 12 January 2016 at 23:14, Marek Olšák <maraeo@gmail.com> wrote:
>>>>> From: Marek Olšák <marek.olsak@amd.com>
>>>>>
>>>>> It warns for all "{}" initializers. Well, I want us to use {}.
>>>>> ---
>>>>> configure.ac | 3 ++-
>>>>> intel/intel_decode.c | 2 --
>>>> The whole of libdrm, minus the intel_decode can get away without using
>>>> such constructs. And yes that includes radeon and amdgpu.
>>>>
>>>> NACK on this one - please be consistent with existing code base.
>>>
>>> Consistent with what? {} is the same as memset on each structure
>>> member. The warning says that a structure member is initialized to
>>> zero because of {}, which is why {} is used in the first place. It's
>>> the same as using memset and getting a warning "memset initializes the
>>> memory to zero". How useful is that?
>>>
>> There was a IRC discussion along the lines of "just use memset", but
>> for the sake of me I cannot find it.
>>
>>> libdrm does have a lot of optional warnings enabled. Mesa does not,
>>> and Mesa does not even have this one. This means libdrm is
>>> inconsistent with Mesa and, BTW, it's also inconsistent with the kernel.
>>>
>>> It looks like somebody enabled optional warnings for libdrm in the
>>> past. All I'm doing is aligning the behavior with Mesa/kernel, which
>>> is what we would like to have and so would Intel apparently.
>>>
>>> Do you still think we are inconsistent?
>>>
>> If you look throughout libdrm you'll see - c99, {} (the one that's
>> causing you problems ?) and {0} initializers. ... And zero warnings
>> from Wmissing-field-initializers ? Don't know what your patch does,
>> but if things flag that normally means "you're doing something new".
>>
>> If if bothers you that much - drop the warning. Just the next time
>> please don't go for "I want", it feels a bit ...
>
> over the top? Sorry about that.
>
> The thing is libdrm enables too many warnings. It's annoying and they
> caused quite a lot of emotional discussion inside AMD. This is in configure.ac:
Please try upgrading your compiler.
BR,
Jani.
>
> MAYBE_WARN="-Wall -Wextra \
> -Wsign-compare -Werror-implicit-function-declaration \
> -Wpointer-arith -Wwrite-strings -Wstrict-prototypes \
> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs \
> -Wpacked -Wswitch-enum -Wmissing-format-attribute \
> -Wstrict-aliasing=2 -Winit-self \
> -Wdeclaration-after-statement -Wold-style-definition \
> -Wno-unused-parameter \
> -Wno-attributes -Wno-long-long -Winline -Wshadow
>
> Marek
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-01-18 15:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 21:14 [PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers Marek Olšák
2016-01-15 11:12 ` Emil Velikov
2016-01-15 15:24 ` Marek Olšák
2016-01-16 19:46 ` David Herrmann
2016-01-18 14:45 ` Emil Velikov
2016-01-18 15:43 ` Marek Olšák
2016-01-18 15:51 ` Jani Nikula [this message]
2016-01-18 16:05 ` Emil Velikov
2016-01-18 22:53 ` Marek Olšák
2016-01-21 10:51 ` Emil Velikov
2016-01-21 12:08 ` Marek Olšák
2016-01-21 13:09 ` Emil Velikov
2016-01-21 16:58 ` Marek Olšák
2016-01-22 17:13 ` Emil Velikov
2016-01-22 17:18 ` Marek Olšák
2016-01-22 17:29 ` Ilia Mirkin
2016-01-22 17:40 ` Emil Velikov
2016-01-22 17:47 ` Ville Syrjälä
2016-01-22 17:48 ` Ilia Mirkin
2016-01-22 19:18 ` Jan Vesely
2016-01-22 17:50 ` Emil Velikov
2016-01-22 17:59 ` Emil Velikov
2016-01-22 18:49 ` Ville Syrjälä
2016-01-22 19:21 ` Emil Velikov
2016-01-22 19:33 ` Ville Syrjälä
2016-01-19 3:42 ` Michel Dänzer
2016-01-16 19:49 ` Ilia Mirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvs2x4vz.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=maraeo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox