[Bug other/41757] New: Add PLUGIN_FINISH_DECL
The GCC plugin API has a PLUGIN_FINISH_TYPE callback which provides an easy way for plugins to enumerate instantiated types in GCC. Unfortunately no such equivalent exists for decls. Would be great to get a way to get notified when global variable, struct member and static method DECLs are completed in the parser. -- Summary: Add PLUGIN_FINISH_DECL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tglek at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
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 we do, I would preffer to not have it by default. > > If the issue is the iteration over the contents of the final > .init_array section, this solution won't have that problem -- the > loader will still execute .init_array entries in forward order (we'll > be reversing them at link time). Your solution will reverse order of reference of .init_array entries with regards to the linker commandline. Linking translation units A B C, will result in C B A execution order. Unless you also change the linker to combine the translation units backwards(vs sequentially as is normal), this will ruin startup speed of chrome/firefox and every other large c++ program. > > If the issue is the code layout of the ctors themselves, that sounds > like something that could be fixed through code layout optimizations > (e.g., gold's --section-ordering-file option). Every single app would have to add this flag for good perf so some legacy build system can avoid reordering the .init_array section using a non-default flag.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
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.
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
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 > they appear in the binary. If you want better layout in the binary, then tell > the linker to change the layout in the binary. The order in the .ctors or > .init_array sections is irrelevant. The fact that reversing the order of > constructors happens to give you faster startup for firefox is just a > coincidence. Don't let that coincidence drive you toward choices that make no > sense. I am not confusing the order in which entries appear. My concerns is the order in which code gets paged in from disk. Right now that's driven entirely by translation unit "concatenation" and how that relates to the order of ctor invocation. Currently the right thing(tm) happens, achieving the same by other means is considerably more complicated. There are 2 problems with using section ordering to solve this a) there is no way to do this kind of section ordering transparently(especially not by default) with current infrastructure. b) it doesn't work without lto because initializers pull in other code... I'll expand on b: We(C++ code like Firefox/Chrome/etc) have one initializer per TU. The initializer is often not self-contained and calls other code within the unit(and rarely in other units...this you can't solve without LTO) So if you pass a list of init sections to the linker...that list needs to be transitive and include all of the sections called from inits in order to achieve a useful level of locality post-reorder. Or you can keep TUs without any reordering, have decent locality(because related init code is generally nearby) and a sane page-in pattern if the order of init executions matches TU layout.
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- 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
[Bug c++/43486] New: Preserve variable-use locations
Static analysis needs good location info in order to present useful errors. Unfortunately in GIMPLE when you have a statement like func( x ); There is no way to get a location for x and often it's hard to get a location for func(ie if func takes form of some_namespace::func ( x )). In Mozilla, we work around this by walking the expression stack backwards and hope that an expression containing a reference to a variable has a location that's sufficiently close to the variable. Other C/C++ frontends indicate the coordinates of variable uses, not just declarations. -- 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 com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug c++/43487] New: method locations are incorrect
Following up on bug https://bugzilla.mozilla.org/show_bug.cgi?id=497972 Function locations do not make sense at the moment 1176 nsresult 1177 RDFServiceImpl::GetBlobLiteral(const PRUint8 *aBytes, PRInt32 aLength, 1178nsIRDFBlob **aResult) Here the location of the FUNCTION_DECL ends up being 1178. Not 1176 -- Summary: method locations are incorrect 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 com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
[Bug c++/43486] Preserve variable-use locations
--- 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 usage. But most statements have a line/column info already. > Ideally I would want the beginning and ending of every expression in the AST, but I'd settle for ability to know the beginning of variables. For example somenamespace::foo->call( x, y); Right now there is no way to get locations for x, y or "call". CALL_EXPR just gives one a vague location, given that there can be a large number of other decls referenced within the CALL_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug c++/43486] Preserve variable-use locations
--- 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 > to > GIMPLE, are you? Ideally this would work in gimple too, but just having this in C++ fe would be enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug middle-end/43773] New: GCC 4.5.0 fails to PGO mozilla
-Wcoverage-mismatch doesn't seem to work. GCC 4.4.3 compiles pgo mozilla successfully. c++ -o nsStringObsolete.o -c -I../../../dist/system_wrappers -include /home/taras/work/mozilla-central/config/gcc_hidden.h -I../../../dist/stl_wrappers -DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux2.6.18-164.15.1\" -DOSARCH=Linux -D_IMPL_NS_COM -I/home/taras/work/mozilla-central/xpcom/string/src -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/home/taras/builds/minefield.pgo/dist/include/nspr -I/home/taras/builds/minefield.pgo/dist/include/nss -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -pedantic -Wcoverage-mismatch -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -Os -freorder-blocks -freorder-blocks-and-partition -fomit-frame-pointer-DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsStringObsolete.pp /home/taras/work/mozilla-central/xpcom/string/src/nsStringObsolete.cpp # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp: In function PRBool IsUTF8(const nsACString_internal&): # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:577:38: warning: suggest parentheses around && within || # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:578:50: warning: suggest parentheses around && within || # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:581:62: warning: suggest parentheses around && within || # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:582:42: warning: suggest parentheses around && within || # /home/taras/work/mozilla-central/xpcom/string/src/nsReadableUtils.cpp:582:59: warning: suggest parentheses around && within || # /home/taras/work/mozilla-central/xpcom/string/src/nsSubstring.cpp: In member function void nsACString_internal::Assign(const nsACString_internal::char_type*, nsACString_internal::size_type): # /home/taras/work/mozilla-central/xpcom/string/src/nsSubstring.cpp:317:72: error: corrupted profile info: profile data is not flow-consistent # /home/taras/work/mozilla-central/xpcom/string/src/nsSubstring.cpp:317:72: error: corrupted profile info: number of executions for edge 15-16 thought to be 28335 # /home/taras/work/mozilla-central/xpcom/string/src/nsSubstring.cpp:317:72: error: corrupted profile info: number of executions for edge 15-17 thought to be -1 -- Summary: GCC 4.5.0 fails to PGO 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
[Bug middle-end/43773] GCC 4.5.0 fails to PGO mozilla
--- 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. Here is the line that's making it unhappy. extern void pr_static_assert(int arg[(sizeof(nsStringContainer_base) == sizeof(nsSubstring)) ? 1 : -1]); where -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43773
[Bug gcov-profile/43825] New: gcov is initialized wrong on x86_64
Building Mozilla with pgo results in a binary that can't even start to generate
profiling data. Turns out that even CXX="g++ --coverage" and CC="gcc
--coverage" resulting a binary that segfaults on start.
The crash looks like
#0 0x740807c1 in strlen () from /lib/libc.so.6
#1 0x76823a92 in __gcov_init () from /tmp/xulrunner/dist/bin/libxul.so
#2 0x76824f56 in __do_global_ctors_aux () from
/tmp/xulrunner/dist/bin/libxul.so
#3 0x751888ab in _init () from /tmp/xulrunner/dist/bin/libxul.so
#4 0x7fffe908 in ?? ()
#5 0x77dee429 in ?? () from /lib64/ld-linux-x86-64.so.2
#6 0x77dee5af in ?? () from /lib64/ld-linux-x86-64.so.2
#7 0x77de1b2a in ?? () from /lib64/ld-linux-x86-64.so.2
#8 0x0001 in ?? ()
#9 0x7fffeb8c in ?? ()
#10 0x in ?? ()
Looks like the info parameter passed to __gcov_init is buggered. This broken in
gcc 4.4-trunk, didn't test on prior releases.
--
Summary: gcov is initialized wrong on x86_64
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: 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
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- 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
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- 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/bugzilla/show_bug.cgi?id=43825
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- 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 > > > executable and leave libraries alone? > > > > > > > I'm not sure what you mean. > > > > Fedora comes with Firefox. If I recompile /usr/lib64/firefox-3.5/firefox > with --coverage, will I see the problem? > I presume you'd recompile the whole firefox rpm. I think you should be able to reproduce the problem there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- 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 add #pragma pack() in the end of that file. > This wouldn't have even crossed my mind. Works great, thanks for debugging this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
[Bug middle-end/43773] GCC 4.5.0 fails to PGO mozilla
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43773
[Bug tree-optimization/45622] New: Suboptimal code generation on arm
ates twice (including the alignment
test), and only if we iterate three times (the maximum) and happened to have
the correct alignment (1 in 4 chance) does it break even.
cmp r0, r1
What is actually put in r7? Why, one of _two_ copies of r1. r1 really contains
the value of ip, which we uselessly copied to it above, and using it here means
we needed to add _another_ useless copy of ip to r1 in the other path to this
label.
mov r7, r1
add r2, r2, #8
This is the one that really takes the cake: just in case we branch here, we'll
copy r1 back into ip (note that ip already contains r1), and then if we don't
branch we immediately clobber it. It does this every time.
mov ip, r1
bls .L437
ldrbip, [r7], #1@ zero_extendqisi2
subsr6, r4, #8
orr r3, r3, ip, asl r4
mov r8, r2
mov ip, r7
This one is also pretty fantastic. So, this time we're going to do the load
using r1, instead of r7 like we did above (why do we have two copies? I still
don't know! actually three if you count ip). That means we need to increment r7
manually instead of doing it as part of the load. And just for giggles, we do
that _before_ the branch here, which goes to an instruction that immediately
clobbers r7.
add r7, r7, #1
bmi .L436
ldrbip, [r1, #1]@ zero_extendqisi2
subssl, r6, #8
orr r3, r3, ip, asl r6
add r2, r2, #8
mov ip, r7
bmi .L436
ldrbr6, [r7, #0]@ zero_extendqisi2
subsr7, r4, #24
add ip, r1, #3
add r2, r8, #16
orr r3, r3, r6, asl sl
bmi .L436
ldrbip, [r1, #3]@ zero_extendqisi2
subsr4, r4, #32
add r1, r1, #4
orr r3, r3, ip, asl r7
add r2, r8, #24
Yeah, better copy r1 into ip again so we can... copy r1 into ip again after the
jump. Fortunately the iteration limit means we can never actually get here.
mov ip, r1
bpl .L415
.L436:
mov r7, r9
.L414:
rsb r1, r5, #32
add r1, r7, r3, lsr r1
add r7, fp, r1, asl #1
ldrsh r7, [r7, #2]
cmp r7, #0
Again, the fast path takes this branch.
ble .L417
.L438:
mov r3, r3, asl r5
rsb r2, r5, r2
b .L418
.L437:
mov r7, r9
.L419:
rsb r1, r5, #32
add r1, r7, r3, lsr r1
add r7, fp, r1, asl #1
ldrsh r7, [r7, #2]
mov r2, #1073741824
cmp r7, #0
bgt .L438
.L417:
rsb r7, r7, #0
mov r0, r7, asr #8
mov r3, r3, asl r0
Yeah! We can finally load back that value we stashed on the stack! Maybe if we
hadn't made three or four copies of ptr, we might have been able to keep it in
a register.
ldr r1, [sp, #4]
rsb r2, r0, r2
str ip, [r1, #4]
and r0, r7, #255
str r3, [r1, #8]
str r2, [r1, #12]
add sp, sp, #8
ldmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp}
bx lr
Things are a little better without -funroll-loops, mostly because the function
is much shorter, but there are still obvious problems, e.g., in the epilogue:
and r8, r8, #255
stmib r0, {r3, ip}@ phole stm
str r2, [r0, #12]
mov r0, r8
If the and was re-ordered, it could take the place of the mov (the
-funroll-loops version gets this right). Or the prologue:
ldmib r0, {r3, ip}@ phole ldm
ldr r4, [r0, #0]
ldr r2, [r0, #12]
It isn't clear to me why it picked registers that were out of order, when it
could have loaded all four with one ldm. But hey, at least that's better than
the -funroll-loops versions, which did four individual loads! 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
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tglek at mozilla dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45622
[Bug regression/45623] New: GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
See https://bugzilla.mozilla.org/show_bug.cgi?id=594611 and https://bugzilla.mozilla.org/show_bug.cgi?id=590683 for more details. This breaks users of Firefox Sync on GCC 4.5. The bug isn't present in gcc 4.4 or trunk. What would it take to cherry-pick a fix for 4.5.x? -- Summary: GCC 4.5.[01] breaks our ffi on Linux64. ABI break? Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tglek at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- 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
[Bug c++/44236] New: Output initializers in .text.init section
In mozilla there are a lot of page faults caused by paging in C++ global initializers. About 1/3rd of firefox faults are globals. ie the first part of a prelinked firefox startup is a bunch of faults caused by _GLOBAL__I_nsFtpConnectionThread.cpp, _GLOBAL__I_nsCookieService.cpp, etc. If these were grouped together large C++ apps would load much faster. Once the initializers are easily identifiable by the linker, the linker needs to lay these out in a continuous chunk in the ordered that they are called. -- Summary: Output initializers in .text.init section Product: 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
[Bug c++/44638] New: Inline constructors into static initializers
struct Derived {
Derived(int i):i(i){}
int i;
};
Derived d(3);
Generates a constructor function to call Derived() constructor. Would be nice
if this was inlined into a static initializer, ie the declaration would become
Derived d = {3}.
This is useful where Derived has a vtable, so one can't use POD-initialization.
When Derived d is a global variable, this causes a .ctors entry for it which
slows down app startup.
--
Summary: Inline constructors into static initializers
Product: 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=44638
