From: Dave Gordon <david.s.gordon@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Jeff Mahoney <jeffm@suse.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] i915: fix build error with -Werror
Date: Tue, 19 Jul 2016 15:18:18 +0100 [thread overview]
Message-ID: <578E36AA.5020905@intel.com> (raw)
In-Reply-To: <20160719070513.GJ17101@phenom.ffwll.local>
On 19/07/16 08:05, Daniel Vetter wrote:
> On Mon, Jul 04, 2016 at 11:30:06AM -0400, Jeff Mahoney wrote:
>> This fixes the following build error with -Werror and gcc 6.1:
>>
>> drivers/gpu/drm/i915/i915_debugfs.c:2103:6: error: suggest explicit braces to avoid ambiguous 'else' [-Werror=parentheses]
>>
>> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
>
> This doesn't apply on -next any more ... Is this still an issue on latest
> kernels?
> -Daniel
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2100,9 +2100,10 @@ static int i915_dump_lrc(struct seq_file
>> return ret;
>>
>> list_for_each_entry(ctx, &dev_priv->context_list, link)
>> - if (ctx != dev_priv->kernel_context)
>> + if (ctx != dev_priv->kernel_context) {
>> for_each_engine(engine, dev_priv)
>> i915_dump_lrc_obj(m, ctx, engine);
>> + }
>>
>> mutex_unlock(&dev->struct_mutex);
That's a curious warning. Ever since
commit 373701b1fc7d7c0013ae4fffd8103615c150751e
drm: fix potential dangling else problems in for_each_ macros
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Nov 24 21:21:55 2015 +0200
Link:
http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-1-git-send-email-jani.nikula@intel.com
we've avoided leaving a dangling else; the code should expand as
for ( /* each entry */ )
if (ctx != dev_priv->kernel_context)
for ( /* each engine */ )
if (!intel_engine_initialized(engine))
{}
else
i915_dump_lrc_obj(m, ctx, engine);
... so that the (hidden) else is clearly matched with the (hidden) if()
generated by the macro expansion. Surely the compiler can't think that
an else inside a for-loop could be mistakenly paired with one outside
the loop?
Of course we did *have* a proposal for an alternative iterator strategy
that didn't expose any if/else at all, but some people didn't like it :L
Oh well, it just shows that using macros to rewrite C syntax is still an
abomination, Stephen Bourne notwithstanding. If you want iterators and
blocks, use Ruby ;)
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2016-07-19 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-04 14:29 [PATCH] i915: fix build error with -Werror Jeff Mahoney
2016-07-04 15:29 ` Jeff Mahoney
2016-07-04 15:30 ` [PATCH v2] " Jeff Mahoney
2016-07-19 7:05 ` Daniel Vetter
2016-07-19 14:18 ` Dave Gordon [this message]
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=578E36AA.5020905@intel.com \
--to=david.s.gordon@intel.com \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jeffm@suse.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