This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Compile this: int i; static int j; int foo() { static int k; return k; } with -fleading-underscore (gcc -S -fleading-underscore foo.c). The variable k is compiled as "k.0" with no leading underscore. This worked correctly in 3.3. I suspect that this problem also appears in a compiler targeted for sh-elf, which sets USER_LABEL_PREFIX to "_". In that case there is no need to use -fleading-underscore, as it is implied. The problem came up on the gdb-patches list, and I tried recreating it using -fleading-underscore rather than building an sh-elf compiler.
Confirmed, I think this was caused by one of Geoff Keatings changes.
Geoff -- Would you please look into this problem, as Andrew thinks this is related to one of your changes? -- Mark
I should note that the one I think this is caused by is the IMA one.
This appears to be a new manifestation of the old bug that int foo() { static int k asm ("k"); return k; } when compiled with -fleading-underscore calls the variable '_k' (but not if you use any assembler name *other than* 'k').
Geoff, if this is related to your changes, you are still obligated to fix it. Even if it's not, since you've taken a look at the problem would you please see if you can solve it?
Subject: Re: [3.4/3.5 regression] -fleading-underscore does not work correctly for file static variables On 12/06/2004, at 3:15 PM, mmitchel at gcc dot gnu dot org wrote: > Geoff, if this is related to your changes, you are still obligated to > fix it. I do not feel that comments like that are likely to be helpful. The bug is in code that you wrote, yet you do not seem to feel any obligation to fix it. > Even if it's not, since you've taken a look at the problem would you > please see if you can solve it? I have a design and a patch, but have not yet tried building the patch. I will not have more time to work on it for about a month.
This patch fixes the reported problem. It doesn't fix the problem which Geoff mentions. I haven't really tested this patch, and I don't know whether it is completely correct. I also don't know whose code this is. --- langhooks.c 14 May 2004 02:29:20 -0000 1.63 +++ langhooks.c 13 Jun 2004 01:42:32 -0000 @@ -35,6 +35,7 @@ Boston, MA 02111-1307, USA. */ #include "langhooks-def.h" #include "ggc.h" #include "diagnostic.h" +#include "output.h" /* Do nothing; in many cases the default hook. */ @@ -188,8 +189,15 @@ lhd_set_decl_assembler_name (tree decl) if (!TREE_PUBLIC (decl) && DECL_CONTEXT (decl)) { const char *name = IDENTIFIER_POINTER (DECL_NAME (decl)); + char *a; char *label; - + + if (user_label_prefix[0] != '\0') + { + a = alloca (strlen (user_label_prefix) + strlen (name) + 1); + sprintf (a, "%s%s", user_label_prefix, name); + name = a; + } ASM_FORMAT_PRIVATE_NAME (label, name, var_labelno); var_labelno++; SET_DECL_ASSEMBLER_NAME (decl, get_identifier (label));
Subject: Re: [3.4/3.5 regression] -fleading-underscore does not work correctly for file static variables On 12/06/2004, at 6:43 PM, ian at wasabisystems dot com wrote: > This patch fixes the reported problem. It doesn't fix the problem > which Geoff > mentions. The patch introduces other problems.
Geoff, I understand that this is a latent bug. Can you confirm whether or not your change exposed it? If so, would you please fix that? If not, would you please indicate that it was not your change that caused it so that I can hassle someone else? Postponed until GCC 3.4.2 in the meantime.
Subject: Re: [3.4/3.5 regression] -fleading-underscore does not work correctly for file static variables On 18/06/2004, at 4:59 PM, mmitchel at gcc dot gnu dot org wrote: > > ------- Additional Comments From mmitchel at gcc dot gnu dot org > 2004-06-18 23:59 ------- > Geoff, I understand that this is a latent bug. Can you confirm > whether or not > your change exposed it? If so, would you please fix that? It has been six days since I said that I had a design and a patch but that I couldn't work on this for about a month. Last I looked, six days was about 24 days less than a month. Ironically, today I actually had some time available to work on it. I updated my tree, started to build it, and spent the rest of the time responding to your e-mail.
Subject: Bug 14516 CVSROOT: /cvs/gcc Module name: gcc Changes by: geoffk@gcc.gnu.org 2004-08-05 05:52:01 Modified files: gcc : ChangeLog c-common.c c-common.h c-decl.c c-semantics.c expr.c passes.c toplev.c toplev.h tree.h varasm.c gcc/ada : utils.c gcc/cp : ChangeLog call.c class.c decl.c decl2.c init.c method.c gcc/fortran : f95-lang.c trans-decl.c trans-intrinsic.c trans-types.c gcc/java : builtins.c class.c constants.c decl.c except.c expr.c resource.c gcc/objc : objc-act.c gcc/treelang : treetree.c Log message: 2004-08-04 Geoffrey Keating <geoffk@apple.com> PR 14516 * c-common.c (c_expand_decl): Don't special-case static VAR_DECLs. * c-common.h (make_rtl_for_local_static): Delete. * c-decl.c (shadow_tag_warned): Clean up comment. (finish_decl): Clean up spacing. Use set_user_assembler_name when appropriate. Don't pass asmspec to rest_of_decl_compilation. * c-semantics.c (make_rtl_for_local_static): Delete. * expr.c (init_block_move_fn): Use set_user_assembler_name. (init_block_clear_fn): Likewise. * passes.c (rest_of_decl_compilation): Remove asmspec parameter, expect it to be in DECL_ASSEMBLER_NAME. Update callers in many files. * toplev.h (rest_of_decl_compilation): Remove asmspec parameter. * tree.h (make_decl_rtl): Remove second parameter. (set_user_assembler_name): New. * varasm.c (set_user_assembler_name): New. (make_decl_rtl): Remove second parameter. Update callers in many files. Index: cp/ChangeLog 2004-08-04 Geoffrey Keating <geoffk@apple.com> * decl.c (make_rtl_for_nonlocal_decl): Set DECL_ASSEMBLER_NAME rather than passing it as a parameter to rest_of_decl_compilation. * decl2.c (grokfield): Use set_user_assembler_name. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4806&r2=2.4807 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&r1=1.546&r2=1.547 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h.diff?cvsroot=gcc&r1=1.253&r2=1.254 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.551&r2=1.552 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-semantics.c.diff?cvsroot=gcc&r1=1.90&r2=1.91 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.694&r2=1.695 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&r1=2.35&r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.910&r2=1.911 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.h.diff?cvsroot=gcc&r1=1.126&r2=1.127 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.580&r2=1.581 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.436&r2=1.437 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/utils.c.diff?cvsroot=gcc&r1=1.71&r2=1.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4262&r2=1.4263 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.497&r2=1.498 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.648&r2=1.649 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1269&r2=1.1270 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.731&r2=1.732 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.389&r2=1.390 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.307&r2=1.308 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/f95-lang.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-intrinsic.c.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/builtins.c.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.200&r2=1.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/constants.c.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.193&r2=1.194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/except.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.200&r2=1.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/resource.c.diff?cvsroot=gcc&r1=1.14&r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.233&r2=1.234 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/treetree.c.diff?cvsroot=gcc&r1=1.39&r2=1.40
Yup, fixed.
but only for 3.5.0, so reopening.
I'm fairly sure you don't want to do anything this dramatic to a stable release branch, especially for a bug whose worst-case failure is that it makes it harder to debug programs that don't have full debugging info.
Will not fix in GCC 3.4.x.
*** Bug 26013 has been marked as a duplicate of this bug. ***