https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #21 from Iain Sandoe ---
Author: iains
Date: Mon Dec 24 13:17:28 2018
New Revision: 267409
URL: https://gcc.gnu.org/viewcvs?rev=267409&root=gcc&view=rev
Log:
Fix PR c++/87380 (ABI breakage) for Darwin.
2018-12-24 Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #20 from Iain Sandoe ---
Author: iains
Date: Sun Dec 23 20:55:39 2018
New Revision: 267386
URL: https://gcc.gnu.org/viewcvs?rev=267386&root=gcc&view=rev
Log:
darwin, fix c++/87380 by backproting r266866.
This was [intentionally] bro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #19 from Iain Sandoe ---
Author: iains
Date: Thu Dec 6 20:09:26 2018
New Revision: 266866
URL: https://gcc.gnu.org/viewcvs?rev=266866&root=gcc&view=rev
Log:
Darwin - fix PR c++/87380
This is [intentionally] broken C++ ABI, that was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #18 from mrs at gcc dot gnu.org ---
So, didn't you just say that it works on darwin8 and later and is broken on
darwin7? If so, then darwin8.h needs the #define (since it is the first
version where ar has been fixed). ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #17 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #16)
> (In reply to Iain Sandoe from comment #15)
>
> > Will try on a ppc-darwin8 system at some point.
>
> external weak definitions appear in archive __SYMTABS for cct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #16 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #15)
> Will try on a ppc-darwin8 system at some point.
external weak definitions appear in archive __SYMTABS for cctools 622 on
powerpc-darwin8.11 (maybe some chance to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #15 from Iain Sandoe ---
(In reply to m...@gcc.gnu.org from comment #14)
> You can test it if you can dump the ar symbol table, with a assembled .s
> file. Nothing needs to work except the assembler and ar and the tool to
> dump the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #14 from mrs at gcc dot gnu.org ---
You can test it if you can dump the ar symbol table, with a assembled .s file.
Nothing needs to work except the assembler and ar and the tool to dump the
symbol table. In the olden days, there was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #13 from mrs at gcc dot gnu.org ---
Ah, yes, likely it would be ar that has changed. Anyway, the ld version is a
cheap indirect proxy for bugs in ar. We're likely to get new ar versions with
new ld versions. A real config test is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #12 from mrs at gcc dot gnu.org ---
I changed the test case around, and the linker seems to be able to resolve from
a .a now:
$ ar -q liblib.a lib.o
$ nm -m liblib.a
liblib.a(lib.o):
0020 (__TEXT,__eh_frame) non-external
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #11 from Iain Sandoe ---
(In reply to m...@gcc.gnu.org from comment #10)
> I've related 15428 which has some details for why this is the way it is.
>
> Unless the underlying bug has been fixed in the linker, changing this will
> mere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > it's been broken a long time - even apple-gcc-4.2.1 is broken
>
> actually, that's not true; it puts the symbol in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> it's been broken a long time - even apple-gcc-4.2.1 is broken
actually, that's not true; it puts the symbol in common to merge this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #7 from Iain Sandoe ---
it's been broken a long time - even apple-gcc-4.2.1 is broken, I don't have
3.3 anywhere without booting an old machine.
clang produces:
.section__DATA,__data
.globl __ZN1AIiE6membe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #6 from Iain Sandoe ---
hmm...
Linux:
$ more lib.s
.file "lib.cc"
.text
.weak _ZN1AIiE6memberE
.section
.bss._ZN1AIiE6memberE,"awG",@nobits,_ZN1AIiE6memberE,comdat
.align 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #5 from Iain Sandoe ---
fudging the static member to be weak, and rebuilding the lib - the test
completes w/out throwing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #3 from Jonathan Wakely ---
On GNU/Linux the symbol in the shared library is a global unique symbol:
$ nm --defined-only -g liblib.so | grep member
0020101c u _ZN1AIiE6memberE
It seems that we need to make it weak to ensure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #2 from Jonathan Wakely ---
The following should run and exit successfully:
$ cat lib.h
template
struct A {
static T member;
};
template
T A::member;
bool match(int*);
$ cat lib.cc
#include "lib.h"
template class A;
bool matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The response from Apple quoted in 82172 comment 26 says that explicit
That should have said Bug 82172 comment 26.
The problem only arises when a template mi
22 matches
Mail list logo
