* [dpdk-dev] mlx debug build error with clang
@ 2017-06-13 15:32 Ferruh Yigit
2017-06-16 12:19 ` Adrien Mazarguil
0 siblings, 1 reply; 5+ messages in thread
From: Ferruh Yigit @ 2017-06-13 15:32 UTC (permalink / raw)
To: Adrien Mazarguil, Nelio Laranjeiro; +Cc: DPDK
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] mlx debug build error with clang
2017-06-13 15:32 [dpdk-dev] mlx debug build error with clang Ferruh Yigit
@ 2017-06-16 12:19 ` Adrien Mazarguil
2017-06-16 12:58 ` Ferruh Yigit
0 siblings, 1 reply; 5+ messages in thread
From: Adrien Mazarguil @ 2017-06-16 12:19 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Nelio Laranjeiro, DPDK
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)
--
Adrien Mazarguil
6WIND
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] mlx debug build error with clang
2017-06-16 12:19 ` Adrien Mazarguil
@ 2017-06-16 12:58 ` Ferruh Yigit
2017-06-16 14:49 ` Ferruh Yigit
0 siblings, 1 reply; 5+ messages in thread
From: Ferruh Yigit @ 2017-06-16 12:58 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Nelio Laranjeiro, DPDK
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] mlx debug build error with clang
2017-06-16 12:58 ` Ferruh Yigit
@ 2017-06-16 14:49 ` Ferruh Yigit
2017-06-23 10:16 ` Ferruh Yigit
0 siblings, 1 reply; 5+ messages in thread
From: Ferruh Yigit @ 2017-06-16 14:49 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Nelio Laranjeiro, DPDK
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.
>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] mlx debug build error with clang
2017-06-16 14:49 ` Ferruh Yigit
@ 2017-06-23 10:16 ` Ferruh Yigit
0 siblings, 0 replies; 5+ messages in thread
From: Ferruh Yigit @ 2017-06-23 10:16 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Nelio Laranjeiro, DPDK
On 6/16/2017 3:49 PM, Ferruh Yigit wrote:
> 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.
Hi Adrien,
Are you planning to send a patch for this?
Thanks,
ferruh
>
>>
>>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-06-23 10:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-13 15:32 [dpdk-dev] mlx debug build error with clang Ferruh Yigit
2017-06-16 12:19 ` Adrien Mazarguil
2017-06-16 12:58 ` Ferruh Yigit
2017-06-16 14:49 ` Ferruh Yigit
2017-06-23 10:16 ` Ferruh Yigit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).