----- Original Message ----- > From: "Joseph Fernandes" <josferna@xxxxxxxxxx> > Agree with Jeff > But now the question is should we have this patch go through or leave it to > float in time and space :) > http://review.gluster.org/#/c/11214/ > > The patch just makes the existing inline calls static or extern appropriately > without causing any harm to the existing > code but removes the risk of undefined symbols for normal inline functions in > gcc 5 and above! > That's the wrong fix IMO. Adding the statics (or extern) is good. Get rid of the inlines. I've only looked at a couple of the inlines. They were, as I recall, only called by a single caller. Which actually seems pretty silly. IMO anyway. On top of which we have had one or two examples of why inlines may actually be worse than silly in our cases, they actually have the ability to randomly not work and be really hard to debug when they do file. (E.g. calling alloca() in an inline function.) As the patch stands now, I won't retract my -1. Remove the inlines and I'll give it a +1. And then we'll see where it goes from there. At a minimum though we need to fix the two that Prashanth found: dht_layout_span() and changelog_dispatch_vec(). > ----- Original Message ----- > From: "Jeff Darcy" <jdarcy@xxxxxxxxxx> > To: "Kaleb S. KEITHLEY" <kkeithle@xxxxxxxxxx> > Cc: "gluster-infra" <gluster-infra@xxxxxxxxxxx>, "Gluster Devel" > <gluster-devel@xxxxxxxxxxx> > Sent: Friday, July 3, 2015 6:05:14 AM > Subject: Re: Gluster and GCC 5.1 > > > Or perhaps we could just get everyone to stop using 'inline' > > I agree that it would be a good thing to reduce/modify our use of > 'inline' significantly. Any advantage gained from avoiding normal > function-all entry/exit has to be weighed against cache pollution from > having the same code repeated over and over each place the function is > invoked. Careful use of 'extern inline' can be good for performance > and/or readability once in a great while, but IMO we should avoid > 'inline' except in cases where the benefits are *proven*. > > On a similar note, can we please please please get people to stop > abusing macros so much? I get that they're sometimes useful to get > around C's lack of generics or other features, but many of our long > complicated macros have no such justification. These pollute the cache > just like 'inline' does, plus they make code harder to debug or edit. > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
