This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: optimization/7247: copy constructor missing when inliningenabled for i386


>>>>> "H" == H J Lu <hjl@lucon.org> writes:

> Jason, it looks like your patch doesn't catch this one.

No, as the bug isn't related to the NRVO; this testcase doesn't have any
returns which would be affected.  Rather, it seems to be a dependency
tracking bug.  I can reproduce the bug by adding 'inline' to the definition
of incidence_matrix and compiling with -O -fschedule-insns2.  Without
-fschedule-insns2, the code leading up to the dump_op calls looks like

        movl    -96(%ebp), %eax
        movl    -92(%ebp), %edx
        movl    %eax, -52(%ebp)
        movl    %edx, -48(%ebp)
        leal    -96(%ebp), %eax
        movl    %eax, (%esp)
        call    pm::dump_op(pm::double_zero const&)
        leal    -52(%ebp), %eax
        movl    %eax, (%esp)
        call    pm::dump_op(pm::double_zero const&)

so the epsilon value is properly copied before it is dumped.  But with
scheduling, it looks like

        movl    -96(%ebp), %eax
        movl    %eax, -52(%ebp)
        leal    -96(%ebp), %eax
        movl    %eax, (%esp)
        call    pm::dump_op(pm::double_zero const&)
        leal    -52(%ebp), %eax
        movl    %eax, (%esp)
        call    pm::dump_op(pm::double_zero const&)

Which suggests that the scheduler incorrectly decides that the second word
wasn't used by the call and optimizes away the copy.  This bug, or a
similar one, seems still to be present in the trunk, though to see it you
also need to move the definition of the double_zero constructor outside the
class, so it is not inlined.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]