[Intel-gfx] [PATCH v2] i915: fix build error with -Werror

Dave Gordon david.s.gordon at intel.com
Tue Jul 19 14:18:18 UTC 2016


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 at 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 at 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.


More information about the Intel-gfx mailing list