--- Comment #45 from jakub at gcc dot gnu dot org 2007-11-06 15:14 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #42 from hjl at lucon dot org 2007-11-05 14:18 ---
(In reply to comment #39)
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote:
- Won't this cause the global variable
--- Comment #43 from hjl at lucon dot org 2007-11-05 19:25 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00214.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #44 from hjl at gcc dot gnu dot org 2007-11-05 23:12 ---
Subject: Bug 33871
Author: hjl
Date: Mon Nov 5 23:11:57 2007
New Revision: 129911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129911
Log:
2007-11-05 H.J. Lu [EMAIL PROTECTED]
PR c++/33871
--- Comment #30 from geoffk at geoffk dot org 2007-11-04 07:50 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote:
Local symbols should only be referenced within the same comdat group
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 ---
(In reply to comment #30)
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote:
Local symbols should only be referenced
--- Comment #32 from geoffk at geoffk dot org 2007-11-05 00:14 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 6:40 AM, hjl at lucon dot org wrote:
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 ---
(In reply to comment #32)
What if you want to reference this string from somewhere that should
never be discarded, like a global variable?
Since the string is local, that global variable is defined in
the same file
--- Comment #34 from hjl at lucon dot org 2007-11-05 00:32 ---
(In reply to comment #33)
(In reply to comment #32)
What if you want to reference this string from somewhere that should
never be discarded, like a global variable?
Since the string is local, that global
--- Comment #35 from geoffk at geoffk dot org 2007-11-05 02:47 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 4:22 PM, hjl at lucon dot org wrote:
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22
--- Comment #36 from hjl at lucon dot org 2007-11-05 02:50 ---
The rules for the comdat group are
1. There should be no outside references to local symbols inside of the comdat
group.
2. All comdat groups with the same signature should have the identical set of
defined global symbols.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #37 from hjl at lucon dot org 2007-11-05 03:01 ---
(In reply to comment #35)
- What if the global variable references two or more strings?
All local strings referenced by the global variable should be
in the same comdat group.
- Won't this cause the global variable to
--- Comment #38 from hjl at lucon dot org 2007-11-05 03:03 ---
(In reply to comment #37)
(In reply to comment #35)
- What if the global variable references two or more strings?
All local strings referenced by the global variable should be
in the same comdat group.
It
--- Comment #39 from geoffk at geoffk dot org 2007-11-05 03:33 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote:
- Won't this cause the global variable to be discarded if anyone
--- Comment #41 from amodra at bigpond dot net dot au 2007-11-05 04:45
---
In reply to #27, I'm reasonably happy with the idea of ld treating a zero
offset into a discarded section as special. I'd also happily approve a patch
that allowed relocations with addends against any local
--- Comment #27 from geoffk at geoffk dot org 2007-11-03 07:21 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 9:03 PM, amodra at bigpond dot net dot au wrote:
--- Comment #26 from amodra at bigpond dot net dot au
--- Comment #28 from gcc at magfr dot user dot lysator dot liu dot se
2007-11-03 07:47 ---
That both files are named S1.C doesn't matter.
If one do
cp S1.C S2.C
g++ -c S1.C
g++ -c S2.C
g++ S1.o S2.o
one get the same behaviour and the same linker error.
--
--- Comment #29 from hjl at lucon dot org 2007-11-03 14:21 ---
(In reply to comment #27)
In this case, though, the contents of the linkonce section will never
actually differ; and I believe in this case the offset is zero, so
even if they did differ it would not matter. Perhaps
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-30 16:53 ---
I agree that the linker should not drop the typeinfo when it is needed.
I could just tell that I see the problem on Linux so it isn't Darwin-specific.
Should the typeinfo for an anonymous
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-30 18:07
---
Geoff, your patch changed the typeinfo symbols for anonymous namespaces from
having weak linkage to non-weak linkage. This caused the regression. Do you
argue this change was deliberate and is the right thing?
--- Comment #17 from geoffk at geoffk dot org 2007-10-30 18:31 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 9:53 AM, gcc at magfr dot user dot lysator dot liu
dot se wrote:
If that is the case, what should
--- Comment #19 from rguenther at suse dot de 2007-10-30 18:44 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in
... defined in discarded section
On Tue, 30 Oct 2007, geoffk at geoffk dot org wrote:
On 30/10/2007, at 11:07 AM, rguenth at gcc dot gnu dot org wrote:
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-10-30 18:50
---
I guess re-evaluating if this is a binutils bug then is required? Do we also
need
to bump the minimal binutils version requirement for 4.3 if so?
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #18 from geoffk at geoffk dot org 2007-10-30 18:35 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 11:07 AM, rguenth at gcc dot gnu dot org wrote:
--- Comment #16 from rguenth at gcc dot gnu dot org
--- Comment #21 from geoffk at geoffk dot org 2007-10-30 19:04 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 11:44 AM, rguenther at suse dot de wrote:
I see. So where is the bug here? We obviously see application
--- Comment #22 from hjl at lucon dot org 2007-10-30 19:12 ---
The problem is typeinfo for (anonymous namespace)::t in .rodata section
references typeinfo name for (anonymous namespace)::t in a comdat section.
When the comdat section is discarded, we got a problem. Can we put
typeinfo
--- Comment #23 from geoffk at geoffk dot org 2007-10-30 19:32 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote:
The problem is typeinfo for (anonymous namespace)::t in .rodata
--- Comment #24 from hjl at lucon dot org 2007-10-30 19:36 ---
(In reply to comment #23)
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote:
The problem is typeinfo for (anonymous
--- Comment #25 from hjl at lucon dot org 2007-10-30 19:37 ---
Basically, you can't have a non-comdat section references a local symbol
in a comdat section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #26 from amodra at bigpond dot net dot au 2007-10-31 04:03
---
I believe the linker is correct to reject relocations against local symbols in
discarded sections. The reason being that the linker allows linkonce (and
comdat group) section contents to differ between two
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI, wrong-code
Summary|typeinfo name referenced in |[4.3
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-29 12:36 ---
125653 works, 125829 is broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-29 13:17 ---
Reverting
r125721 | geoffk | 2007-06-14 22:56:25 +0200 (Thu, 14 Jun 2007) | 4 lines
PR 31093
* decl2.c (determine_visibility): Remove duplicate code for
handling type info.
fixes this.
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-10-29 13:22
---
The testcase that went in with this change still passes after reverting the
change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-10-29 17:12
---
The typeinfo for anonymous namespace classes should be local.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #13 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-29 18:52 ---
Should the typeinfo for an anonymous namespace class be local if it inherits
from a class that is outside the anonymous namespace?
If that is the case, what should typeid(reference to base of
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-10-30 03:44 ---
I don't fully understand the linker error message. It seems to me that if
there's a reference to the typeinfo name then that just means the linker
shouldn't be discarding it.
The original problem was encountered
38 matches
Mail list logo
