public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/19031] New: #pragma weak handling changes in 4.0.0
@ 2004-12-16 10:43 pth at suse dot de
2004-12-16 16:31 ` [Bug c/19031] [4.0 Regression] " pinskia at gcc dot gnu dot org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: pth at suse dot de @ 2004-12-16 10:43 UTC (permalink / raw)
To: gcc-bugs
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?
--
Summary: #pragma weak handling changes in 4.0.0
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pth at suse dot de
CC: aj at suse dot de,gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
@ 2004-12-16 16:31 ` pinskia at gcc dot gnu dot org
2004-12-17 10:30 ` aj at gcc dot gnu dot org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-12-16 16:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:31 -------
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.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu dot org
Keywords| |wrong-code
Summary|#pragma weak handling |[4.0 Regression] #pragma
|changes in 4.0.0 |weak handling changes in
| |4.0.0
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
2004-12-16 16:31 ` [Bug c/19031] [4.0 Regression] " pinskia at gcc dot gnu dot org
@ 2004-12-17 10:30 ` aj at gcc dot gnu dot org
2004-12-17 10:37 ` joseph at codesourcery dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: aj at gcc dot gnu dot org @ 2004-12-17 10:30 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From aj at gcc dot gnu dot org 2004-12-17 10:30 -------
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?
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jh at suse dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
2004-12-16 16:31 ` [Bug c/19031] [4.0 Regression] " pinskia at gcc dot gnu dot org
2004-12-17 10:30 ` aj at gcc dot gnu dot org
@ 2004-12-17 10:37 ` joseph at codesourcery dot com
2004-12-19 0:41 ` philipp dot thomas at t-link dot de
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: joseph at codesourcery dot com @ 2004-12-17 10:37 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From joseph at codesourcery dot com 2004-12-17 10:37 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (2 preceding siblings ...)
2004-12-17 10:37 ` joseph at codesourcery dot com
@ 2004-12-19 0:41 ` philipp dot thomas at t-link dot de
2004-12-31 13:15 ` steven at gcc dot gnu dot org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: philipp dot thomas at t-link dot de @ 2004-12-19 0:41 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From philipp dot thomas at t-link dot de 2004-12-19 00:41 -------
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?
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (3 preceding siblings ...)
2004-12-19 0:41 ` philipp dot thomas at t-link dot de
@ 2004-12-31 13:15 ` steven at gcc dot gnu dot org
2004-12-31 23:30 ` rth at gcc dot gnu dot org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: steven at gcc dot gnu dot org @ 2004-12-31 13:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2004-12-31 13:15 -------
Not being able to build X is pretty critical.
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (4 preceding siblings ...)
2004-12-31 13:15 ` steven at gcc dot gnu dot org
@ 2004-12-31 23:30 ` rth at gcc dot gnu dot org
2005-01-01 23:27 ` jh at suse dot cz
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-12-31 23:30 UTC (permalink / raw)
To: gcc-bugs
------- 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...
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (5 preceding siblings ...)
2004-12-31 23:30 ` rth at gcc dot gnu dot org
@ 2005-01-01 23:27 ` jh at suse dot cz
2005-01-02 7:52 ` cvs-commit at gcc dot gnu dot org
2005-01-02 7:54 ` rth at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: jh at suse dot cz @ 2005-01-01 23:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jh at suse dot cz 2005-01-01 23:27 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (6 preceding siblings ...)
2005-01-01 23:27 ` jh at suse dot cz
@ 2005-01-02 7:52 ` cvs-commit at gcc dot gnu dot org
2005-01-02 7:54 ` rth at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-01-02 7:52 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-02 07:52 -------
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
` (7 preceding siblings ...)
2005-01-02 7:52 ` cvs-commit at gcc dot gnu dot org
@ 2005-01-02 7:54 ` rth at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: rth at gcc dot gnu dot org @ 2005-01-02 7:54 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From rth at gcc dot gnu dot org 2005-01-02 07:54 -------
Fixed.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-01-02 7:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-16 10:43 [Bug c/19031] New: #pragma weak handling changes in 4.0.0 pth at suse dot de
2004-12-16 16:31 ` [Bug c/19031] [4.0 Regression] " pinskia at gcc dot gnu dot org
2004-12-17 10:30 ` aj at gcc dot gnu dot org
2004-12-17 10:37 ` joseph at codesourcery dot com
2004-12-19 0:41 ` philipp dot thomas at t-link dot de
2004-12-31 13:15 ` steven at gcc dot gnu dot org
2004-12-31 23:30 ` rth at gcc dot gnu dot org
2005-01-01 23:27 ` jh at suse dot cz
2005-01-02 7:52 ` cvs-commit at gcc dot gnu dot org
2005-01-02 7:54 ` rth at gcc dot gnu dot org
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).