* Undefined static functions
@ 2004-08-31 0:28 Joseph S. Myers
2004-08-31 6:02 ` Richard Henderson
2004-08-31 23:55 ` Mark Mitchell
0 siblings, 2 replies; 8+ messages in thread
From: Joseph S. Myers @ 2004-08-31 0:28 UTC (permalink / raw)
To: gcc
C requires a diagnostic if a static function is used but not defined in a
translation unit. The present implementation of this is a pedwarn in
check_global_declarations in toplev.c.
(a) Which language front ends use this pedwarn, rather than avoiding
getting that far with a translation unit using an undefined static
function?
(b) Is there any reason this shouldn't be a hard error rather than just a
pedwarn?
(c) This diagnostic is broken for C with -funit-at-a-time (implied by
-O2), ": Search converges between 2004-07-08-trunk (#482) and
2004-07-09-trunk (#483).". Test (should be diagnosed, now isn't at -O2):
static void f0(void);
void g0(void) { f0(); }
I would guess TREE_SYMBOL_REFERENCED is being tested too early for
unit-at-a-time mode; certainly it's the wrong way to implement this
diagnostic.
(d) It also has always been broken with regard to calls that are optimised
away; C90 and C99 are explicit that it is any use outside sizeof (sizeof
whose result is an integer constant, in C99) that is erroneous. For
example,
static void f1(void);
void g1(void) { if (0) { f1(); } }
should be diagnosed. Is there any reason this shouldn't be a hard error
as well?
I propose to fix this C90 issue (which was missing from my original C90
project proposal) in the front end, and there is nothing tricky about so
doing (flag all used static function decls, ignoring uses inside
__alignof__ and keeping lists inside sizeof/typeof so they can be flagged
afterwards if the result turns out nonconstant). It would however be
convenient to be able to get rid of the checks in toplev.c (or make them
internal_error if no errors have been given by the front end) by having
all front ends give proper errors, to avoid the need to do anything
special to avoid duplicate error messages.
(e) Consider the following C++ variation on the above program:
inline static void f1(void);
void g1(void) { if (0) { f1(); } }
Does "no diagnostic required" in C++03 [basic.def.odr] paragraph 3 apply
to the whole paragraph, or only to the sentence it appears in? That is,
is "An inline function shall be defined in every translation unit in which
it is used." a diagnosable rule? If so, this program should be diagnosed
by the C++ compiler (and the existing diagnostic for inline functions used
but not defined should be a pedwarn or error not a warning).
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined static functions
2004-08-31 0:28 Undefined static functions Joseph S. Myers
@ 2004-08-31 6:02 ` Richard Henderson
2004-08-31 9:11 ` Joseph S. Myers
2004-08-31 23:55 ` Mark Mitchell
1 sibling, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2004-08-31 6:02 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc
On Tue, Aug 31, 2004 at 12:11:20AM +0000, Joseph S. Myers wrote:
> (b) Is there any reason this shouldn't be a hard error rather than just a
> pedwarn?
The function implementation is contained within a file-scope asm. I need
to tell the compiler that the symbol is locally defined (static as opposed
to extern), so that the proper set of relocations are selected.
I have used this often in kernel and libc code.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined static functions
2004-08-31 6:02 ` Richard Henderson
@ 2004-08-31 9:11 ` Joseph S. Myers
2004-08-31 20:44 ` Richard Henderson
0 siblings, 1 reply; 8+ messages in thread
From: Joseph S. Myers @ 2004-08-31 9:11 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc
On Mon, 30 Aug 2004, Richard Henderson wrote:
> On Tue, Aug 31, 2004 at 12:11:20AM +0000, Joseph S. Myers wrote:
> > (b) Is there any reason this shouldn't be a hard error rather than just a
> > pedwarn?
>
> The function implementation is contained within a file-scope asm. I need
> to tell the compiler that the symbol is locally defined (static as opposed
> to extern), so that the proper set of relocations are selected.
>
> I have used this often in kernel and libc code.
This does rather make me wonder whether what check_global_declarations
does after warning,
/* This symbol is effectively an "extern" declaration now. */
TREE_PUBLIC (decl) = 1;
is particularly safe. Certainly it looks like setting TREE_PUBLIC after
pedwarning in the front end wouldn't be a particularly good way to stop
check_global_declarations from warning - defining TREE_NO_WARNING to apply
to decls as well as expressions looks safer.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined static functions
2004-08-31 9:11 ` Joseph S. Myers
@ 2004-08-31 20:44 ` Richard Henderson
2004-08-31 20:56 ` Joseph S. Myers
0 siblings, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2004-08-31 20:44 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc
On Tue, Aug 31, 2004 at 08:31:09AM +0000, Joseph S. Myers wrote:
> This does rather make me wonder whether what check_global_declarations
> does after warning,
>
> /* This symbol is effectively an "extern" declaration now. */
> TREE_PUBLIC (decl) = 1;
>
> is particularly safe.
Doesn't sound like it. I guess the reason it works is that
encode_section_info has already done its job, and we don't
call back into it now.
> ... defining TREE_NO_WARNING to apply
> to decls as well as expressions looks safer.
TREE_NO_WARNING *does* apply to decls. See warn_uninit in tree-ssa.c.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined static functions
2004-08-31 0:28 Undefined static functions Joseph S. Myers
2004-08-31 6:02 ` Richard Henderson
@ 2004-08-31 23:55 ` Mark Mitchell
2004-09-01 0:10 ` Joseph S. Myers
1 sibling, 1 reply; 8+ messages in thread
From: Mark Mitchell @ 2004-08-31 23:55 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc
Joseph S. Myers wrote:
>C requires a diagnostic if a static function is used but not defined in a
>translation unit. The present implementation of this is a pedwarn in
>check_global_declarations in toplev.c.
>
>(a) Which language front ends use this pedwarn, rather than avoiding
>getting that far with a translation unit using an undefined static
>function?
>
>(b) Is there any reason this shouldn't be a hard error rather than just a
>pedwarn?
>
>(c) This diagnostic is broken for C with -funit-at-a-time (implied by
>-O2), ": Search converges between 2004-07-08-trunk (#482) and
>2004-07-09-trunk (#483).". Test (should be diagnosed, now isn't at -O2):
>
>static void f0(void);
>void g0(void) { f0(); }
>
>I would guess TREE_SYMBOL_REFERENCED is being tested too early for
>unit-at-a-time mode; certainly it's the wrong way to implement this
>diagnostic.
>
>(d) It also has always been broken with regard to calls that are optimised
>away; C90 and C99 are explicit that it is any use outside sizeof (sizeof
>whose result is an integer constant, in C99) that is erroneous. For
>example,
>
>static void f1(void);
>void g1(void) { if (0) { f1(); } }
>
>should be diagnosed. Is there any reason this shouldn't be a hard error
>as well?
>
>I propose to fix this C90 issue (which was missing from my original C90
>project proposal) in the front end, and there is nothing tricky about so
>doing (flag all used static function decls, ignoring uses inside
>__alignof__ and keeping lists inside sizeof/typeof so they can be flagged
>afterwards if the result turns out nonconstant). It would however be
>convenient to be able to get rid of the checks in toplev.c (or make them
>internal_error if no errors have been given by the front end) by having
>all front ends give proper errors, to avoid the need to do anything
>special to avoid duplicate error messages.
>
>(e) Consider the following C++ variation on the above program:
>
>inline static void f1(void);
>void g1(void) { if (0) { f1(); } }
>
>Does "no diagnostic required" in C++03 [basic.def.odr] paragraph 3 apply
>to the whole paragraph, or only to the sentence it appears in? That is,
>is "An inline function shall be defined in every translation unit in which
>it is used." a diagnosable rule?
>
Yes. (And there's nothing wrong with issuing diagnostics that are not
strictly required.)
>If so, this program should be diagnosed
>by the C++ compiler (and the existing diagnostic for inline functions used
>but not defined should be a pedwarn or error not a warning).
>
>
I agree.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined static functions
2004-08-31 23:55 ` Mark Mitchell
@ 2004-09-01 0:10 ` Joseph S. Myers
0 siblings, 0 replies; 8+ messages in thread
From: Joseph S. Myers @ 2004-09-01 0:10 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
On Tue, 31 Aug 2004, Mark Mitchell wrote:
> > (e) Consider the following C++ variation on the above program:
> >
> > inline static void f1(void);
> > void g1(void) { if (0) { f1(); } }
> >
> > Does "no diagnostic required" in C++03 [basic.def.odr] paragraph 3 apply to
> > the whole paragraph, or only to the sentence it appears in? That is, is "An
> > inline function shall be defined in every translation unit in which it is
> > used." a diagnosable rule?
> Yes. (And there's nothing wrong with issuing diagnostics that are not
> strictly required.)
Thanks - I've filed bug 17256 to record this issue as I wouldn't expect to
be looking at fixing it myself in the near future.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-09-01 22:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-31 0:28 Undefined static functions Joseph S. Myers
2004-08-31 6:02 ` Richard Henderson
2004-08-31 9:11 ` Joseph S. Myers
2004-08-31 20:44 ` Richard Henderson
2004-08-31 20:56 ` Joseph S. Myers
2004-09-01 22:24 ` Richard Henderson
2004-08-31 23:55 ` Mark Mitchell
2004-09-01 0:10 ` Joseph S. Myers
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 read-only IMAP folder(s) and NNTP newsgroup(s).