[Bug rtl-optimization/56129] New: Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[Bug rtl-optimization/56129] New: Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56129

             Bug #: 56129
           Summary: Seg fault on 256.bzip2 from spec2000 with -lto and
                    pre-reload scheduler for x86 Atom
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ysrumyan@gmail.com


In a process of testing Atom with lto and pre-reload scheduler we got Seg Fault
on 256:

./bzip2 input.graphic 58                                                        
spec_init
Loading Input Data
Duplicating 6656364 bytes
Duplicating 13312728 bytes
Duplicating 26625456 bytes
Duplicating 7566496 bytes
Input data 60817408 bytes in length
Compressing Input Data, level 7
Compressed data 44249975 bytes in length
Uncompressing Data
Segmentation fault

If we turn off LRA test is passed.

We did the following investigation:

1. Both -lto and pre-reload scheduler (-fschedule-insns --param
sched-pressure-algorithm=1 -fsched-pressure) are required to exhibit the
failure.
2. We also used Atom specific options to compile:
-msse2 -mfpmath=sse -ffast-math -march=atom
and peak optset - -O3 -funroll loops
3. We found out that if we turn off pre-reload scheduler for 'main' the failure
disappears.
4. We also determined that if we turn off pre-reload shceduler in main for
regions > 575 test is passed but it failed if we increase upper threshold on 1,
i.e. if we skip scheduling all regions in main starting from 577.
5. Comparing good and bad objdumps (I don't know how to get assembly file with
-lto) we found out that possible reason of fail is non-correct offset for one
of spill:

in good case

fill:   804c205:    8b 84 24 c0 00 00 00     mov    0xc0(%esp),%eax 
spill:  804d1ed:    89 84 24 c0 00 00 00     mov    %eax,0xc0(%esp)

in bad case with restricted scheduling

fill:   804c205:    8b 84 24 c0 00 00 00     mov    0xc0(%esp),%eax
spill:  804d1ed:    89 44 24 6c              mov    %eax,0x6c(%esp)

in bzip2 built with standard pre-reload shceduler and lto

fill:   804c272:       8b 44 24 7c             mov    0x7c(%esp),%eax
spill:  804d1a9:       89 44 24 78             mov    %eax,0x78(%esp)

i.e. we see the different offset for spill/fill of virtual register.

To reproduce the failure is is sufficient to run spec on any corei7 machine
with the pointed out options.
Please, let me know if we are needed any additional info.

[Bug rtl-optimization/56129] Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56129

--- Comment #1 from Uros Bizjak <ubizjak at gmail dot com> 2013-01-29 07:14:37 UTC ---
(In reply to comment #0)

> Please, let me know if we are needed any additional info.

Yes, we need all relevant files to recreate the failure. If possible, please
create a minimal executable testcase that exposes the problem.

Please follow the instructions in http://gcc.gnu.org/bugs/#report. Hopefully
someone will add a section on how to handle LTO compiles.

[Bug rtl-optimization/56129] Seg fault on 256.bzip2 from spec2000 with -lto and pre-reload scheduler for x86 Atom

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56129

Yuri Rumyantsev <ysrumyan at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
The issue is not reproducible with 4.9 compiler, so I closed it.