[dpdk-dev] mlx debug build error with clang

[Ferruh Yigit]

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

>