http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118357 introduced pedwarns about any static decls in external linkage inline functions, but ISO C99 6.4.7/3 has: "An inline definition of a function with external linkage shall not contain a definition of a modifiable object with static storage duration, and shall not contain a reference to an identifier with internal linkage." In -std=c99: inline int foo (void) { static const int c = 6; return c; } the static variable c isn't modifiable, so the first condition doesn't apply, and from 6.2.2 I gather c has no linkage rather than internal linkage and so the other condition doesn't apply either. In -std=c99: static const int c = 6; inline int foo (void) { return c; } I believe c has internal linkage and thus it is invalid (and therefore correctly diagnosed by the trunk).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11377 says otherwise.
Created attachment 15051 [details] gcc43-pr35017.patch TREE_READONLY isn't modifiable, so I guess that part is quite clear and I'm also pretty sure about the possibility to reference static const vars declared in the function. What is more unclear is in what kind of inline functions this should be warned about. 6.7.4p3 talks about inline definition of a function, is that function definition with inline keyword in this context (i.e. any non-static inline function) or is that inline definition in the 6.7.4p6 sense (one where there is no external definition)? The attached patch implements the first choice, leaving the original conditions for current_function_decl in both places would keep the second choice. Joseph?
BTW, the patch I've attached doesn't bootstrap, got an error on bitmap.c. Simplified testcase: typedef int bitmap_element; typedef struct { bitmap_element *first; } *bitmap; extern void bitmap_clear (bitmap); static void bitmap_elt_clear_from (bitmap, bitmap_element *); void bitmap_elt_clear_from (bitmap head, bitmap_element *elt) { (void) head; (void) elt; } inline void bitmap_clear (bitmap head) { if (head->first) bitmap_elt_clear_from (head, head->first); } If this is valid ISO C99, then I'll need to adjust the patch.
Created attachment 15052 [details] gcc43-pr35017.patch Alternative patch, which only pedwarns in inline definitions as defined in 4.7.6p6 as before, just doesn't warn when it should not.
Subject: Re: [4.3 Regression] PR11377 pedwarns even about valid code On Tue, 29 Jan 2008, jakub at gcc dot gnu dot org wrote: > TREE_READONLY isn't modifiable, so I guess that part is quite clear and I'm > also > pretty sure about the possibility to reference static const vars declared in > the function. > What is more unclear is in what kind of inline functions this should be warned > about. 6.7.4p3 talks about inline definition of a function, is that function > definition with inline keyword in this context (i.e. any non-static inline > function) or is that inline definition in the 6.7.4p6 sense (one where there is > no external definition)? > The attached patch implements the first choice, leaving the original conditions > for current_function_decl in both places would keep the second choice. > Joseph? I think it means inline definition as in 6.7.4p6 (where whether it's an inline definition depends on whether there are subsequent declarations after the definition with extern or without inline, but getting the diagnostics right for such cases is a separate bug).
Subject: Bug 35017 Author: jakub Date: Tue Jan 29 23:19:07 2008 New Revision: 131945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131945 Log: PR c/35017 * c-decl.c (start_decl): Don't pedwarn about TREE_READONLY static decls. * c-typeck.c (build_external_ref): Don't pedwarn about static vars in current function's scope. * gcc.dg/inline-25.c: New test. * gcc.dg/inline-26.c: New test. * gcc.dg/inline-27.c: New test. Added: trunk/gcc/testsuite/gcc.dg/inline-25.c trunk/gcc/testsuite/gcc.dg/inline-26.c trunk/gcc/testsuite/gcc.dg/inline-27.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
Fixed.