http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #93 from Taras Glek 2012-04-18 04:48:18
UTC ---
(In reply to comment #92)
> As I said in comment #47 and elsewhere, you should not confuse the order in
> which entries appear in .ctors or .init_array sections with the order in which
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #91 from Taras Glek 2012-04-18 01:27:58
UTC ---
(In reply to comment #90)
>
> Or that you kept the link command fixed, but switching to init_array gave
> you significant speed up, which you don't want to lose?
This.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #89 from Taras Glek 2012-04-17 23:58:00
UTC ---
(In reply to comment #87)
> > Just as a quick reminder, the reversed ctor execution order is big
> > performance
> > problem for C++ Apps inlcuding Mozilla and Chrome ;)
> > So whatever
--- Comment #7 from tglek at mozilla dot com 2010-09-10 02:37 ---
-fno-strict-aliasing makes no difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
ek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
ds! Fixing this would
also likely have allowed combining the stmib/str in the epilogue.
--
Summary: Suboptimal code generation on arm
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
IRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44638
: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44236
--- Comment #3 from tglek at mozilla dot com 2010-04-22 22:01 ---
-fprofile-correction corrects this
--
tglek at mozilla dot com changed:
What|Removed |Added
--- Comment #9 from tglek at mozilla dot com 2010-04-21 17:48 ---
(In reply to comment #8)
> Taras, to avoid triggering the problem from firefox you can search for the
> file
> (as I remember there is only one in xulrunner) with #pragma pack(1) and does
> not reset it, and
--- Comment #6 from tglek at mozilla dot com 2010-04-21 00:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> > > executabl
--- Comment #4 from tglek at mozilla dot com 2010-04-21 00:15 ---
(In reply to comment #3)
> I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
> executable and leave libraries alone?
>
I'm not sure what you mean.
--
http://gcc.gnu.org/bugzill
--- Comment #2 from tglek at mozilla dot com 2010-04-21 00:05 ---
(In reply to comment #1)
> Do you have a small testcase?
>
I wish. A minimal testcase works, but mozilla doesn't. Any suggestions on how
to reduce this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
y: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
--- Comment #2 from tglek at mozilla dot com 2010-04-19 17:56 ---
(In reply to comment #1)
> -Wcoverage-mismatch isn't designed to cover this kind of errors. Are there
> source changes for the profile-use stage compared to the profile-generate
> stage?
>
No changes.
O mozilla
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43773
--- Comment #5 from tglek at mozilla dot com 2010-03-23 02:07 ---
(In reply to comment #4)
> I suppose we could wrap rvalue uses in NOP_EXPR and lvalue uses in
> VIEW_CONVERT_EXPR.
>
> Taras: You aren't actually trying to do this sort of analysis after lowering
>
--- Comment #2 from tglek at mozilla dot com 2010-03-22 22:42 ---
(In reply to comment #1)
> Which location do you want? For function calls, it will be part of the call
> expression (or rather the call statement). For variables, it is harder to
> keep
> track of that
gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
Summary: Preserve variable-use locations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot
--- Comment #18 from tglek at mozilla dot com 2010-03-22 18:40 ---
Perhaps someone could turn this into a landable patch
https://bugzilla.mozilla.org/attachment.cgi?id=352646&action=edit
This seemed to fix the problem for us
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757
22 matches
Mail list logo
