From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8CAF7A0471 for ; Sat, 22 Jun 2019 18:17:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C29F81BD47; Sat, 22 Jun 2019 18:17:48 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id F3FB81BC6E for ; Sat, 22 Jun 2019 18:17:46 +0200 (CEST) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1heihO-0007JS-8S; Sat, 22 Jun 2019 12:17:09 -0400 Date: Sat, 22 Jun 2019 12:17:00 -0400 From: Neil Horman To: David Marchand Cc: Aaron Conole , Adrien Mazarguil , Gage Eads , dev , Jerin Jacob Kollanukkaran , Van Haaren Harry , Nikhil Rao , Erik Gabriel Carrillo , Bruce Richardson , Pablo de Lara Message-ID: <20190622161700.GB16476@hmswarspite.think-freely.org> References: <20190620164206.3972-1-gage.eads@intel.com> <20190621162726.GA21895@hmswarspite.think-freely.org> <20190621174023.GC21895@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 21, 2019 at 09:58:41PM +0200, David Marchand wrote: > On Fri, Jun 21, 2019 at 7:41 PM Neil Horman wrote: > > > On Fri, Jun 21, 2019 at 06:47:31PM +0200, David Marchand wrote: > > > On Fri, Jun 21, 2019 at 6:28 PM Neil Horman > > wrote: > > > > > > > On Fri, Jun 21, 2019 at 02:45:45PM +0200, David Marchand wrote: > > > > > Ok, did a new pass on the tree.. found quite some sites where we have > > > > > issues (and other discrepancies... I started a new patchset). > > > > > Looked at gcc documentation [1], and to me the safer approach would > > be to > > > > > enforce that __rte_experimental is the first thing of a symbol > > > > declaration. > > > > > > > > > > Comments? > > > > > > > > > Yes, thats the only way it works, in fact I'm suprised gcc didn't > > throw an > > > > error > > > > about expecting an asm statement if you put it anywhere else > > > > > > > > > > - I tried this, but then I hit issues with inlines. > > > Like for example: > > > > > > static inline char * __rte_experimental > > > rte_mbuf_buf_addr(struct rte_mbuf *mb, struct rte_mempool *mp) > > > { > > > return (char *)mb + sizeof(*mb) + rte_pktmbuf_priv_size(mp); > > > } > > > > > > I did not find a way to move the __rte_experimental tag without getting > > > warnings. > > Right, thats the way its supposed to work on gcc/icc/clang. function > > attributes > > must be declared between the return type and the function name, anything > > else > > will generate compiler warnings/errors. Because __rte_experimental > > expands to a > > __attribute__(...), you have to place it there. > > > > > If I try to compile some sources which includes rte_mbuf.h but without > > > -DALLOW_EXPERIMENTAL_API, then gcc errors at including the header, > > > complaining that rte_mbuf_buf_addr() is deprecated, even if this inline > > is > > > not called. > > > > > Thats...odd. I wonder if thats an artifact of the function being marked as > > inline. The compiler is supposed to insert the warning for any remaining > > calls > > after dead code eliminitaion. If the function is inline, I wonder if the > > compiler conservatively inserts the warning because it got expanded into > > another > > function, when it can't tell if it will be entirely elimintated. Can you > > provide a code sample that demonstrates this? > > > > > rte_mbuf_buf_addr() is called in rte_mbuf_data_addr_default(), both of them > are unused by the includers of rte_mbuf.h. > > > Reproduced it like this: > > [dmarchan@dmarchan ~]$ cat deprecated.c > __attribute__((deprecated)) static inline void *plap(void) > { > return 0; > } > > __attribute__((deprecated)) static inline void *plep(void) > { > plap(); > return 0; > } > > int main(int argc, char *argv[]) > { > return 0; > } > [dmarchan@dmarchan ~]$ gcc -o deprecated -Wall deprecated.c > deprecated.c: In function ‘plep’: > deprecated.c:8:2: warning: ‘plap’ is deprecated (declared at > deprecated.c:1) [-Wdeprecated-declarations] > plap(); > ^ > Hmm, yes, that seems buggy to me. I wonder if you are seeing this bug in action: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=80680 Seem like the behavior fits. It would be interesting to know if clang and icc suffer from the same issue Neil > -- > David Marchand