http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52430
Bug #: 52430 Summary: [4.4 Regression] firefox miscompilation Classification: Unclassified Product: gcc Version: 4.4.6 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: hubi...@gcc.gnu.org, jamb...@gcc.gnu.org The following file is miscompiled on x86_64-linux with -quiet -fPIC -fno-rtti -pedantic -fno-exceptions -fstack-protector --param ssp-buffer-size=4 -m64 -mtune=generic -fpermissive -fno-exceptions -fno-strict-aliasing -fshort-wchar -ffunction-sections -fdata-sections -Os -freorder-blocks -fomit-frame-pointer -fpreprocessed dombindings.ii It was "fixed" or fixed for real, not clear, by a huge http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147852 commit which I think is unlikely backportable, at least not in full. The problem seems to be in IPA-CP/IPA-* decisions, the growStorageBy method is called in several places in this TU with constant 1, so IPA-CP decides to clone things, but in the end clones just calculateNewCapacity (with implied lengthInc=1), but doesn't clone growStorageBy, eventhough the call to calculateNewCapacity from it call the clone that assumes lengthInc is 1. For that TU this isn't a problem, but growStorageBy is public linkonce function, and when mixing it with other TUs that call growStorageBy with other parameters, if this one wins, they ignore their last parameter and grow just by 1 instead of the desired amount. but ends up actually cloning just