* [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).