compiling Xorg's X11 with gcc 4.0.0 20041215 (experimental) fails because the handling of '#pragma weak' seems to hve changed. The testcode, derived from xc/lib/xtrans/Xtranssock.c: ------------------cut----------------- extern int foo; static const int bar = 1; #pragma weak foo=bar -------------------------------------- when compiled with gcc 3.3.4 the resulting object shows 0000000000000000 r bar 0000000000000000 V foo i.e. bar as local symbol and foo as a weak alias. When compiled with 4.0.0 20041215, the object only has bar listed as an undefined Symbol. The X.org Xtranssock.c code is doing the above trick to define a weak alias for in6addr_any to provide compatibility for apps linked against system libraries that don't have IPv6 support. Now the question is, who is wrong. If it's the X11 code, how could the code possibly be changed?
Well the following patch changed it: 2004-11-29 Daniel Jacobowitz <dan@codesourcery.com> PR c/7544 * Makefile.in (c-lang.o): Update dependencies. * c-lang.c: Include "c-pragma.h". (finish_file): Call maybe_apply_pending_pragma_weaks. * c-pragma.c (maybe_apply_pending_pragma_weaks): New function. * c-pragma.h (maybe_apply_pending_pragma_weaks): New prototype.
Further testing showed that this is a fallout from unit-at-a-time: aj@reger:~/tmp> /opt/gcc/4.0-devel/bin/gcc -c test.c aj@reger:~/tmp> nm test.o 0000000000000000 r bar 0000000000000000 V foo aj@reger:~/tmp> /opt/gcc/4.0-devel/bin/gcc -c test.c -O2 aj@reger:~/tmp> nm test.o U bar aj@reger:~/tmp> /opt/gcc/4.0-devel/bin/gcc -c test.c -O2 -fno-unit-at-a-time aj@reger:~/tmp> nm test.o 0000000000000000 r bar 0000000000000000 V foo The question still remains, what are the symantics? Do we have to declare the variable as extern or not?
Subject: Re: [4.0 Regression] #pragma weak handling changes in 4.0.0 On Fri, 17 Dec 2004, aj at gcc dot gnu dot org wrote: > The question still remains, what are the symantics? Do we have to declare > the variable as extern or not? http://docs.sun.com/source/817-5064/sun.specific.html#48658 has the specification of #pragma weak for C, such as it is. It doesn't address your question.
Well, the question should be, what the semantics of weak aliases are, no matter how they're created. This is because using __attribute__((weak, alias())) leads to the same results as '#pragma weak'. Richard, can you opossibly enlighten us?
Not being able to build X is pretty critical.
I think that this sort of thing *ought* to work. How, exactly, to teach cgraph to make it happen is perhaps tricky...
Subject: Re: [4.0 Regression] #pragma weak handling changes in 4.0.0 > > ------- Additional Comments From rth at gcc dot gnu dot org 2004-12-31 23:30 ------- > I think that this sort of thing *ought* to work. How, exactly, to teach > cgraph to make it happen is perhaps tricky... OK, if I understand it right the main trickyness of this is the fact that we no longer can get cgraph node from the identifier, right? One possibility is to set TREE_SYMBOL_REFERENCED and teach cgraphunit to walk all the nodes once after finalization and put them into the queue, but it is particularly ugly and clash with Zack's plans on killing TREE_SYMBOL_REFERENCED (in that case we can probably use just the hash of string instead). If no one sees better sollution, I will implement it... Honza > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org > |dot org | > Status|UNCONFIRMED |ASSIGNED > Ever Confirmed| |1 > Last reconfirmed|0000-00-00 00:00:00 |2004-12-31 23:30:52 > date| | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
Subject: Bug 19031 CVSROOT: /cvs/gcc Module name: gcc Changes by: rth@gcc.gnu.org 2005-01-02 07:52:31 Modified files: gcc : ChangeLog c-decl.c c-lang.c cgraph.c cgraph.h varasm.c gcc/objc : objc-act.c Added files: gcc/testsuite/gcc.dg: attr-alias-2.c gcc/testsuite/gcc.dg/weak: weak-11.c Log message: PR c/19031 * c-decl.c (pop_file_scope): Call maybe_apply_pending_pragma_weaks. * c-lang.c (finish_file): Don't do it here. * objc/objc-act.c (objc_finish_file): Likewise. * cgraph.c (decl_assembler_name_equal): New. (cgraph_node_for_asm, cgraph_varpool_node_for_asm): New. (cgraph_varpool_node): Actually link up cgraph_varpool_nodes. * cgraph.h (struct cgraph_varpool_node): Add next. (cgraph_node_for_asm, cgraph_varpool_node_for_asm): Declare. * varasm.c (assemble_alias): Mark the target as needed. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7000&r2=2.7001 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.621&r2=1.622 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-lang.c.diff?cvsroot=gcc&r1=1.137&r2=1.138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.c.diff?cvsroot=gcc&r1=1.61&r2=1.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcc&r1=1.41&r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.471&r2=1.472 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff?cvsroot=gcc&r1=1.259&r2=1.260 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-alias-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/weak/weak-11.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed.