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
