https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #23 from Martin Liška ---
(In reply to Xi Ruoyao from comment #22)
> Created attachment 44126 [details]
> Patch to add symver attribute, highly experimental, C++ only
That's great you did the prototype. I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #22 from Xi Ruoyao ---
Created attachment 44126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44126&action=edit
Patch to add symver attribute, highly experimental, C++ only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #21 from Xi Ruoyao ---
I made up a (highly immature) patch in the days.
This "thing" works with simple source code files but I believe there are many
bugs in the patch.
And I suggest to make "weakref" attribute to output ".symver" d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #20 from Martin Lišk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #19 from Xi Ruoyao ---
I think the best result would be like FMV, for e.g.
int foo(void) __attribute__((symver("@1.1")))
{
return 0;
}
int foo(void) __attribute__((symver("@@1.2")))
{
return 1;
}
Would produce two symbols "foo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #18 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #17)
> I prefer
>
> int pci_fill_info(struct pci_dev *, int)
> __attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31")));
But then what should we do for
int pci_fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #17 from Xi Ruoyao ---
(In reply to Richard Biener from comment #16)
> We might want to add a function attribute to allow to specify symver, so like
>
> int pci_fill_info_v31(struct pci_dev *d, int flags)
> __attribute__((alias("pci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #16 from Richard Biener ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Jan Hubicka from comment #13)
> > Concerning comment #11, if you have toplevel asms you need to disable LTO
> > for that unit, as there is no way to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #15 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #13)
> Concerning comment #11, if you have toplevel asms you need to disable LTO
> for that unit, as there is no way to tell for gcc what the asm statement is
> doing. Perha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #14 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #13)
> What is status of this bug in general? I must admit I thought we have issues
> long solved here :(
It still exists in 8.1. Libstdc++ uses top level asm statement fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #13 from Jan Hubicka ---
Concerning comment #11, if you have toplevel asms you need to disable LTO for
that unit, as there is no way to tell for gcc what the asm statement is doing.
Perhaps attribute would be better way to do this?
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Xi Ruoyao changed:
What|Removed |Added
CC||ryxi at stu dot xidian.edu.cn
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #11 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Roman Khimov changed:
What|Removed |Added
CC||khimov at altell dot ru
--- Comment #10 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #9 from Jan Hubicka 2011-03-23 13:12:37 UTC
---
> Well ... I suppose this also heavily depends on your I/O speed. Nevetheless
> the number _looks_ awfully low compared to those others.
Well, totally minimizing compilation of small un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Richard Guenther changed:
What|Removed |Added
Keywords||lto
--- Comment #8 from Richard Guenth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #7 from Jan Hubicka 2011-03-22 23:04:08 UTC
---
Well, upping it only workarounds the problem and you loose parallelizm linking
small files. I did bit of tunning on this compiling one of spec2k benchmarks
(twolf?) to get smallest time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #6 from Richard Guenther 2011-03-22
10:13:49 UTC ---
Btw, the minimal partition size is quite small (1000), 10 times smaller
than our large-unit-insns inline limit and 2.7 times smaller than our
large function inline limit. Upping th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Richard Guenther changed:
What|Removed |Added
Status|WAITING |NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #4 from Zeev Tarantov 2011-03-21
22:40:12 UTC ---
I've constructed a trivial example, the bug did not reproduce in it.
I've tried -save-temps and -Wl,--verbose but those did not reveal anything.
I do not have a nicer testcase than com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #3 from Zeev Tarantov 2011-03-21
18:26:46 UTC ---
I am sorry but I don't know which parts are relevant. The source is GPL2, I
just ran "make SHARED=yes CFLAGS="-fPIC -O2 -flto" lib/libpci.so.3.1.7" and
then linked the SO a second time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #2 from Zeev Tarantov 2011-03-21
18:18:26 UTC ---
Created attachment 23740
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23740
sources, object files and two shared objects: one good, one bad (resulted from
linking with LTO)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
24 matches
Mail list logo
