Re: _GL_INLINE issue
Paul Eggert wrote: > > what was the motivation of changing > > 'static inline' to 'static' - other than "it's not needed" > > Partly so that the relevant modules wouldn't require AC_C_INLINE. This is a bit backwards: In gnulib, we usually write the C code first, and then put together the .m4 file and the module description so that it fits with the C code. Not the other way around. > I wanted to work around issues when gcc -fno-inline was used. > This was during the reorganization when we got Gnulib to work > better with extern inline and C11. OK, so I guess this is not a sufficient reason for eliminating all current and future uses of 'static inline', from dfa.c to regexec.c. Ben Pfaff wrote: > For functions defined in .c files, I like to avoid "static inline" > because "inline" prevents the compiler from warning me when a function > is unused, which I often find to be a useful warning. Good point. And debuggability with gdb. Single-stepping through inline functions is quite confusing. On the other hand, for debugging, I most often compile with "-O0 -ggdb" anyway, which inhibits the inlining even of 'static inline' functions. Bruno
Re: _GL_INLINE issue
On 04/13/2018 07:03 AM, Bruno Haible wrote: what was the motivation of changing 'static inline' to 'static' - other than "it's not needed" Partly so that the relevant modules wouldn't require AC_C_INLINE. As I vaguely recall, I wanted to work around issues when gcc -fno-inline was used. This was during the reorganization when we got Gnulib to work better with extern inline and C11. Simplicity is good too
Re: _GL_INLINE issue
On Fri, Apr 13, 2018 at 04:03:45PM +0200, Bruno Haible wrote: > By the way, Paul, what is the problem with telling the compiler what to > 'static inline'? In other words, what was the motivation of changing > 'static inline' to 'static' - other than "it's not needed" - in the > 13 patches presented on November 09, 2012 in > https://lists.gnu.org/archive/html/bug-gnulib/2012-11/ and committed on > 2012-11-29 ? For functions defined in .c files, I like to avoid "static inline" because "inline" prevents the compiler from warning me when a function is unused, which I often find to be a useful warning.
Re: _GL_INLINE issue
Hi Bruno, On 04/13/2018 04:03 PM, Bruno Haible wrote: > Hi Tim, > >> We use 'static _GL_INLINE' for some static functions we want to get >> inlined. > > This is a wrong use of '_GL_INLINE'. > > There are 3 uses of the keyword 'inline' in C: > 1) 'static inline'. > 2) 'inline' and 'extern inline'. > > Portable use of 1) is simple: > - use AC_REQUIRE([AC_C_INLINE]) > - use 'static inline' in the code. > > Portable use of 2) is more involved: This is what > https://www.gnu.org/software/gnulib/manual/html_node/extern-inline.html > is about. > > When you write 'static _GL_INLINE', you are mixing up the cases 1) and 2). Ah ! Thanks for the clarification :-) We indeed only wanted to use 1) With Best Regards, Tim signature.asc Description: OpenPGP digital signature
Re: _GL_INLINE issue
Hi Tim, > We use 'static _GL_INLINE' for some static functions we want to get > inlined. This is a wrong use of '_GL_INLINE'. There are 3 uses of the keyword 'inline' in C: 1) 'static inline'. 2) 'inline' and 'extern inline'. Portable use of 1) is simple: - use AC_REQUIRE([AC_C_INLINE]) - use 'static inline' in the code. Portable use of 2) is more involved: This is what https://www.gnu.org/software/gnulib/manual/html_node/extern-inline.html is about. When you write 'static _GL_INLINE', you are mixing up the cases 1) and 2). > "C code ordinarily should not use inline. Typically it is better to let > the compiler figure out whether to inline, as compilers are pretty good > about optimization nowadays. In this sense, inline is like register, > another keyword that is typically no longer needed." This advice applies to modern compilers. By the way, Paul, what is the problem with telling the compiler what to 'static inline'? In other words, what was the motivation of changing 'static inline' to 'static' - other than "it's not needed" - in the 13 patches presented on November 09, 2012 in https://lists.gnu.org/archive/html/bug-gnulib/2012-11/ and committed on 2012-11-29 ? Bruno
