Using both -fmudflap and -Wnested-externs generates spurious errors.

localhost$ touch tmp.c
localhost$ gcc -fmudflap -Wnested-externs -S tmp.c
<built-in>:0: warning: nested extern declaration of ‘__mf_lookup_cache’
<built-in>:0: warning: nested extern declaration of ‘__mf_lc_shift’
<built-in>:0: warning: nested extern declaration of ‘__mf_lc_mask’
<built-in>:0: warning: nested extern declaration of ‘__mf_check’
<built-in>:0: warning: nested extern declaration of ‘__mf_register’
<built-in>:0: warning: nested extern declaration of ‘__mf_unregister’
<built-in>:0: warning: nested extern declaration of ‘__mf_init’
<built-in>:0: warning: nested extern declaration of ‘__mf_set_options’
cc1: error: mf-runtime.h: No such file or directory

You can ignore the mf-runtime.h error.  The ones I'm concerned about here are
all of the false nested extern warnings.

I can reproduce the problem with all gcc versions from 4.0.x to mainline 4.3.

This problem exists only with the C (and maybe C++) front end because of how
the C front end handles scoping.

The problem here is that the function mudflap_init creates some variables via
pushdecl.  However, the C front end has an implicit assumption that no
variables will be created until after we start parsing, at which time
push_file_scope is called.  Since mudflap creates variables before
push_file_scope is called, they end up being placed in the wrong scope, and the
C front end gets confused and emits the warning.

A possible solution is to add a builtin_variable hook similar to the existing
builtin_function hook.  Note that the C front end builtin_function hook calls
bind directly, instead of calling pushdecl which then calls bind.  A
builtin_variable hook could do something similar which would solve the problem.

There are also other simpler but less elegant ways to solve the problem.  We
could mark these mudflap variables with the DECL_IN_SYSTEM_HEADER bit to
disable the -Wnested-externs warning for them.  Or we could maybe disable the
warning for variables in the external_scope, which I think can only happen in
this case, though I haven't tried to verify that.


-- 
           Summary: -fmudflap and -Wnested-externs conflict
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilson at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30592

Reply via email to