Bug 57131 - [4.8/4.9 Regression] Wrong register assignment?
Summary: [4.8/4.9 Regression] Wrong register assignment?
Status: RESOLVED DUPLICATE of bug 57097
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.8.1
: P3 normal
Target Milestone: 4.8.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-01 06:02 UTC by Ishiura Lab Compiler Team
Modified: 2013-05-02 19:26 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-05-01 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ishiura Lab Compiler Team 2013-05-01 06:02:28 UTC
This miscompile occurs only on 32bit x86 (i686) target of GCC 4.8.1 (prerelease).  
(There is no problem with x86_64 target or GCC 4.7.3.) 
A dubious option is "-foptimize-register-move."

  $ cat error.c

  int main (void)
  {
    volatile int x1 = 0;
    volatile long long x2 = 0;
    volatile int x3 = 0;
    volatile int x4 = 1;
    volatile int x5 = 1;
    volatile long long x6 = 1;

    long long t = ( ( x1 * ( x2 << x3 ) ) / (x4 * x5) ) + x6 ;

    return (t == 1); 
  }

  $ i686-pc-linux-gnu-gcc-4.8.1 error.c -O1 -fexpensive-optimizations -foptimize-register-move
  $ ./a.out
  Floating point exception (core dumped)

-----

$ i686-pc-linux-gnu-gcc-4.8.1 -v
Using built-in specs.
COLLECT_GCC=i686-pc-linux-gnu-gcc-4.8.1
COLLECT_LTO_WRAPPER=/usr/local/i686-tools/gcc-4.8.1/libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/hassy-i686-linux/gcc/configure
--prefix=/usr/local/i686-tools/gcc-4.8.1/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 4.8.1 20130428 (prerelease) (GCC)
Comment 1 Jakub Jelinek 2013-05-01 06:44:04 UTC
Started with http://gcc.gnu.org/PR196090
Comment 2 Jakub Jelinek 2013-05-01 07:39:41 UTC
Apparently went away with the http://gcc.gnu.org/r198432 fix, but it isn't clear whether that change was meant to fix this or just made the bug latent.
Anyway, still reproduceable on the 4.8 branch.
What I'm seeing before that change is that extendsidi2_1 pattern with MEM destination LRA chooses %ebx as (clobber (scratch:SI)) register, eventhough %ebx
is live across that instruction (there is
(insn 14 74 68 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
        (mem/v/c:SI (plus:SI (reg/f:SI 7 sp)
                (const_int 72 [0x48])) [0 x4+0 S4 A64])) pr57131.c:11 85 {*movsi_internal}
     (nil))
(insn 68 14 73 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
        (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
        (nil)))
some insns before it and:
(insn 65 24 26 2 (set (reg:SI 5 di [orig:83 D.1395 ] [83])
        (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
        (nil)))
some insns after it.  Not sure if the noop move with REG_DEAD has anything to do with that.  Vlad, can you please have a look?
Comment 3 Vladimir Makarov 2013-05-02 03:03:34 UTC
(In reply to comment #2)
> Apparently went away with the http://gcc.gnu.org/r198432 fix, but it isn't
> clear whether that change was meant to fix this or just made the bug latent.
> Anyway, still reproduceable on the 4.8 branch.
> What I'm seeing before that change is that extendsidi2_1 pattern with MEM
> destination LRA chooses %ebx as (clobber (scratch:SI)) register, eventhough
> %ebx
> is live across that instruction (there is
> (insn 14 74 68 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
>         (mem/v/c:SI (plus:SI (reg/f:SI 7 sp)
>                 (const_int 72 [0x48])) [0 x4+0 S4 A64])) pr57131.c:11 85
> {*movsi_internal}
>      (nil))
> (insn 68 14 73 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
>         (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
>      (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
>         (nil)))
> some insns before it and:
> (insn 65 24 26 2 (set (reg:SI 5 di [orig:83 D.1395 ] [83])
>         (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
>      (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
>         (nil)))
> some insns after it.  Not sure if the noop move with REG_DEAD has anything to
> do with that.  Vlad, can you please have a look?

http://gcc.gnu.org/r198432 was a right solution for this bug.  LRA don't pay attention to NO_REGS pseudos during assignment although ebx was assigned to NO_REGS r95 (which is reflected in reg_renumber).

At some points of LRA work reg notes can be invalid.  LRA makes them up to date after live subpass (lra-lives.c).  It needs only correct live info on bb borders.

So I'd close this PR.
Comment 4 Andrew Pinski 2013-05-02 03:16:35 UTC
(In reply to comment #3)
> So I'd close this PR.

Done as a dup of bug 57097.

*** This bug has been marked as a duplicate of bug 57097 ***
Comment 5 Jakub Jelinek 2013-05-02 19:26:38 UTC
Author: jakub
Date: Thu May  2 06:00:46 2013
New Revision: 198511

URL: http://gcc.gnu.org/viewcvs?rev=198511&root=gcc&view=rev
Log:
	PR rtl-optimization/57131
	* gcc.c-torture/execute/pr57131.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr57131.c
Modified:
    trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Thu May  2 19:25:34 2013
New Revision: 198560

URL: http://gcc.gnu.org/viewcvs?rev=198560&root=gcc&view=rev
Log:
	PR rtl-optimization/57131
	* gcc.c-torture/execute/pr57131.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57131.c
Modified:
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog