On 6/16/2017 1:58 PM, Ferruh Yigit wrote:
> On 6/16/2017 1:19 PM, Adrien Mazarguil wrote:
>> Hi Ferruh,
>>
>> On Tue, Jun 13, 2017 at 04:32:03PM +0100, Ferruh Yigit wrote:
>>> Hi Adrien, Nelio,
>>>
>>> I am getting following build error [1] with clang [2] when debug enabled
>>> for mlx4 and mlx5.
>>>
>>> This started after I update my box, not sure what triggered this.
>>> Can you please help fixing this?
>>>
>>> Thanks,
>>> ferruh
>>>
>>>
>>> [1]
>>>
>>> .../drivers/net/mlx4/mlx4_flow.c:731:3: error: use of GNU statement
>>> expression extension [-Werror,-Wgnu-statement-expression]
>>> claim_zero(ibv_destroy_qp(fdq->qp));
>>> ^
>>> .../drivers/net/mlx4/mlx4.h:185:25: note: expanded from macro 'claim_zero'
>>> #define claim_zero(...) assert((__VA_ARGS__) == 0)
>>> ^
>>> /usr/include/assert.h:95:6: note: expanded from macro 'assert'
>>> ({ \
>>> ^
>>>
>>> ....
>>>
>>> .../drivers/net/mlx5/mlx5_fdir.c:278:2: error: use of GNU statement
>>> expression extension [-Werror,-Wgnu-statement-expression]
>>> assert(((uint8_t *)attr + sizeof(*attr)) == (uint8_t *)spec_offset);
>>> ^
>>> /usr/include/assert.h:95:6: note: expanded from macro 'assert'
>>> ({ \
>>> ^
>>>
>>> [Many of similar ...]
>>>
>>>
>>> [2]
>>> target: x86_64-native-linuxapp-clang
>>>
>>> clang version 4.0.0 (tags/RELEASE_400/final)
>>
>> Recent Glibc versions now apparently handle assert() through a nonstandard
>> ({ }) construct, which is not pedantic-safe due to a missing __extension__
>> keyword.
>>
>> assert.h still provides a standard assert() definition that shouldn't cause
>> compilation to fail when the following condition is met:
>>
>> #if !defined __GNUC__ || defined __STRICT_ANSI__
>>
>> However __GNUC__ is (always?) defined by clang for maximum compatibility
>> with GCC while __STRICT_ANSI__ is not due to the -std=gnu99 parameter,
>> assert.h thinks it's OK to use a ({ }) construct but is then caught by
>> clang's -pedantic parameter.
>>
>> There are two ways to address this issue while keeping our beloved -pedantic
>> parameter in debug mode:
>>
>> 1. Replacing -std=gnu99 with -std=c99 (which is even stricter) to bring back
>> __STRICT_ANSI__.
>> 2. Replacing assert() statements with RTE_ASSERT().
>>
>> The former should be doable now that DPDK includes have been cleaned up, and
>> we're thinking about doing the latter at some point.
>>
>> Since I don't have a recent Glibc handy, can you try replacing -std=gnu99
>> with -std=c99 in both Makefiles (mlx4 and mlx5), and report how GCC and
>> clang fare? (GCC at least seems to have no problem with that on my side)
>
> Sure, I will try -std=c99
This fixes the build error.
>
>>
>
