[Bug tree-optimization/52430] New: [4.4 Regression] firefox miscompilation

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: hubicka@gcc.gnu.org, jamborm@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