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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.