http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #19 from Jakub Jelinek 2012-02-20
08:37:09 UTC ---
Nice, so we want Paolo's patch. Out of interest, what are the 447.deal numbers
when comparing linking against old (pre-Benjamin's commit) libstdc++.a and
current libstdc++.a with Pao
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #18 from Vladimir Yakovlev 2012-02-20
05:37:32 UTC ---
I tested Paolo's patch and got acceleration on 447.dial
base: +7.36%
peak: +5.97%
Also I looked dumps: the new routine 'local_Rb_tree_increment' in inlined now
in both
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #17 from Jakub Jelinek 2012-02-19
19:24:05 UTC ---
libstdc++.so.6 obviously contained -fPIC code before and does now as well, and
people really should be using the shared library (almost) always.
See http://www.akkadia.org/drepper/no_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #16 from Igor Zamyatin 2012-02-19
18:58:41 UTC ---
Jakub, could you please clarify your statement - "But libstdc++.so.6's tree.cc
has been compiled with
-fPIC -DPIC before Benjamin's change and is compiled with those flags after
those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #15 from Paolo Carlini 2012-02-16
15:04:42 UTC ---
Note, if we decide to do this at the level of tree.cc, we should consistently
change _Rb_tree_decrement too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #11 from Jakub Jelinek 2012-02-16
13:48:59 UTC ---
libtool apparently creates convenience libraries only with -fPIC stuff in it,
instead of having two sets of objects for each source, one -fPIC and one
non-fPIC.
Not sure if it is poss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #14 from Paolo Carlini 2012-02-16
13:59:20 UTC ---
Created attachment 26676
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26676
Draft
Something like this. I suppose either static or inline should do the trick.
Maybe submitter c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #12 from Paolo Carlini 2012-02-16
13:50:46 UTC ---
... besides the trivial fact that then isn't exported anymore. For that we can
simply refactor the actual code and call it as-is or via the const_cast from
the two exported _Rb_tree_i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #13 from Paolo Carlini 2012-02-16
13:52:38 UTC ---
Thanks Jakub that's definitely possible, and my knowledge of libtool is very
weak anyway. My operative suggestion stands, I guess.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #10 from Paolo Carlini 2012-02-16
13:45:53 UTC ---
By the way, I don't see anything wrong with explicitly marking
_Rb_tree_increment(_Rb_tree_node_base*) inline if that helps in some special
circumstances.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #9 from Paolo Carlini 2012-02-16
13:39:21 UTC ---
(In reply to comment #5)
> (In reply to comment #2)
> > I don't understand what you mean by "inlining", since '_Rb_tree_node_base'
> > is a
> > *type* not a function.
>
> This is a c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #8 from Jakub Jelinek 2012-02-16
10:57:19 UTC ---
Note that if more inlining in tree.cc even in -fPIC code helps more than just a
single benchmark, we could consider compiling that file with -O3, or use some
attributes/pragmas to ensu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #7 from Richard Guenther 2012-02-16
10:37:34 UTC ---
It is desirable that libstdc++.a contains PIC code, otherwise you cannot
link it statically into shared libraries or into position independent
executables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #6 from Jakub Jelinek 2012-02-16
09:26:58 UTC ---
The fact that -fPIC code is often slower than -fno-pic code on many targets
isn't that surprising. But libstdc++.so.6's tree.cc has been compiled with
-fPIC -DPIC before Benjamin's ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #5 from Vladimir Yakovlev 2012-02-16
09:05:49 UTC ---
(In reply to comment #2)
> I don't understand what you mean by "inlining", since '_Rb_tree_node_base' is
> a
> *type* not a function.
This is a constructor
> Anyway, I don't see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #4 from Vladimir Yakovlev 2012-02-16
09:00:32 UTC ---
Created attachment 26675
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26675
Dump of good case (without -fPIC -DPIC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #3 from Vladimir Yakovlev 2012-02-16
08:58:45 UTC ---
Created attachment 26674
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26674
Dump of bad case (with -fPIC -DPIC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #2 from Paolo Carlini 2012-02-15
16:39:00 UTC ---
I don't understand what you mean by "inlining", since '_Rb_tree_node_base' is a
*type* not a function.
Anyway, I don't see how Benjamin's split could have caused inlining issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241
--- Comment #1 from Igor Zamyatin 2012-02-15
09:06:49 UTC ---
BTW, this is a 4.7 regression
20 matches
Mail list logo
