public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/55547] New: Alias analysis does not handle AND addresses correctly
@ 2012-11-30 13:13 ubizjak at gmail dot com
  2012-12-01  9:22 ` [Bug rtl-optimization/55547] " ubizjak at gmail dot com
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: ubizjak at gmail dot com @ 2012-11-30 13:13 UTC (permalink / raw)
  To: gcc-bugs


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

             Bug #: 55547
           Summary: Alias analysis does not handle AND addresses correctly
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ubizjak@gmail.com
            Target: alphaev68-unknown-linux-gnu


The patch that fixed alias analysis [1] triggered following testsuite failure
[2] on alphaev68-linux-gnu:

FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fomit-frame-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fbounds-check 

The testcase fails in the line where i is checked for 26. The value is 0:

      subroutine foo (b)
        logical b
        integer i, j
        character*24 s
        save
        if (b) then
          i = 26
          j = 131
          s = 'This is a test string'
        else
          if (i .ne. 26 .or. j .ne. 131) call abort
          if (s .ne. 'This is a test string') call abort
        end if
      end subroutine foo

This is a runtime failure, but the problem can be seen with a crosscompiler,
configured with --target=alpha-linux-gnu.

The testcase should be compiled with "-O2 -mcpu=ev67 -mexplicit-relocs".

Before _208r.sched1, we have:

   10: r77:DI=high(`i.843')
   11: r78:SI=0x1a
   12: [r77:DI+low(`i.843')]=r78:SI
      REG_DEADr78:SI
      REG_DEADr77:DI
...
   42: r102:DI=r81:DI+low(`s.845')
      REG_EQUAL`s.845'
   43: r106:DI=[r102:DI+0xf&0xfffffffffffffff8]
   44: r105:DI=[r81:DI+low(`s.845')&0xfffffffffffffff8]
      REG_EQUAL[`s.845'&0xfffffffffffffff8]
 ...
   57: [r81:DI+low(`s.845')&0xfffffffffffffff8]=r105:DI
      REG_DEADr105:DI
      REG_DEADr81:DI

(The last sequence is part of alpha_expand_block_move, specifically an
unaligned access to the head of string "s.845"). In the above sequence, load
and store to i.843 and s.845 are lined one after another.

The problematic sequence is shown in function "foo" in _.208r.sched1 RTL dump,
after scheduler reordered instructions:

   17: r82:DI=high(`*$LC0')
   16: r81:DI=high(`s.845')
   70: r115:QI=0x20
   10: r77:DI=high(`i.843')
   18: r86:DI=r82:DI+low(`*$LC0')
      REG_EQUAL`*$LC0'
   42: r102:DI=r81:DI+low(`s.845')
      REG_EQUAL`s.845'
   19: r83:DI=[r82:DI+low(`*$LC0')&0xfffffffffffffff8]
      REG_DEADr82:DI
      REG_EQUAL[`*$LC0'&0xfffffffffffffff8]
   44: r105:DI=[r81:DI+low(`s.845')&0xfffffffffffffff8]
      REG_EQUAL[`s.845'&0xfffffffffffffff8]
   21: r89:DI=[r86:DI+0xf&0xfffffffffffffff8]
   20: r84:DI=[r86:DI+0x8&0xfffffffffffffff8]
   23: r91:DI=r86:DI&0x7
   11: r78:SI=0x1a
   43: r106:DI=[r102:DI+0xf&0xfffffffffffffff8]
...
   12: [r77:DI+low(`i.843')]=r78:SI
      REG_DEADr78:SI
      REG_DEADr77:DI
...
   57: [r81:DI+low(`s.845')&0xfffffffffffffff8]=r105:DI
      REG_DEADr105:DI
      REG_DEADr81:DI

As it happens, i lives inside "aligned" s address range:

(gdb) p &i
$3 = (PTR TO -> ( integer(kind=4) )) 0x120012090 <i.853>
(gdb) p &s
$4 = (PTR TO -> ( character*24 )) 0x120012094 <s.855>

Due to the way unaligned stores are implemented on alpha, where an aligned
address is read first, the value is inserted and the combination is stored back
to aligned address, we rewrite location of "i" with previous value, 0 in this
case.

To illustrate this problem, let's put breakpoints at the store of i (b1) and
store of s (b2):

   0x0000000120000a8c <+204>:   cmoveq  t10,0,t9
   0x0000000120000a90 <+208>:   ldah    t10,0(gp)
b1 0x0000000120000a94 <+212>:   stl     a3,-32640(t10)
   0x0000000120000a98 <+216>:   lda     a3,131
   0x0000000120000a9c <+220>:   or      t2,t8,t2
   0x0000000120000aa0 <+224>:   or      t3,t9,t3
   0x0000000120000aa4 <+228>:   ldah    t10,0(gp)
   0x0000000120000aa8 <+232>:   stb     t6,23(t0)
   0x0000000120000aac <+236>:   insqh   t2,t0,t8
   0x0000000120000ab0 <+240>:   mskqh   t5,t0,t5
   0x0000000120000ab4 <+244>:   stl     a3,-32644(t10)
   0x0000000120000ab8 <+248>:   insqh   t3,t0,t1
   0x0000000120000abc <+252>:   insql   t2,t0,t2
   0x0000000120000ac0 <+256>:   or      t5,t8,t5
   0x0000000120000ac4 <+260>:   stq_u   t5,15(t0)
   0x0000000120000ac8 <+264>:   insql   t3,t0,t3
   0x0000000120000acc <+268>:   or      t1,t2,t1
   0x0000000120000ad0 <+272>:   stq_u   t1,8(t0)
   0x0000000120000ad4 <+276>:   stb     a4,16(t0)
   0x0000000120000ad8 <+280>:   or      t4,t3,t4
b2 0x0000000120000adc <+284>:   stq_u   t4,-32636(t7)
   0x0000000120000ae0 <+288>:   stb     a5,17(t0)

Breakpoint 1, 0x0000000120000a94 in foo (b=.TRUE.) at save_1.f90:7
7                 i = 26
(gdb) p i
$5 = 0
(gdb) s
8                 j = 131
(gdb) p i
$6 = 26
(gdb) c
Continuing.

Breakpoint 2, 0x0000000120000adc in foo (b=.TRUE.) at save_1.f90:9
9                 s = 'This is a test string'
(gdb) p i
$7 = 26
(gdb) s
14            end subroutine foo
(gdb) p i
$8 = 0
(gdb) 

When compiled with additional -fno-schedule-insns, the test runs OK.

[1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02225.html
[2] http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg02492.html


^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-01-18 11:06 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-30 13:13 [Bug rtl-optimization/55547] New: Alias analysis does not handle AND addresses correctly ubizjak at gmail dot com
2012-12-01  9:22 ` [Bug rtl-optimization/55547] " ubizjak at gmail dot com
2012-12-01  9:23 ` [Bug rtl-optimization/55547] [4.8 Regression] " ubizjak at gmail dot com
2012-12-07 13:59 ` rguenth at gcc dot gnu.org
2012-12-07 21:45 ` aoliva at gcc dot gnu.org
2012-12-07 23:30 ` aoliva at gcc dot gnu.org
2012-12-09 13:52 ` ubizjak at gmail dot com
2012-12-09 22:44 ` ubizjak at gmail dot com
2013-01-02  8:30 ` ubizjak at gmail dot com
2013-01-15 16:48 ` rth at gcc dot gnu.org
2013-01-16  4:32 ` aoliva at gcc dot gnu.org
2013-01-16  4:37 ` aoliva at gcc dot gnu.org
2013-01-16 15:20 ` jakub at gcc dot gnu.org
2013-01-16 16:31 ` jakub at gcc dot gnu.org
2013-01-18 11:01 ` aoliva at gcc dot gnu.org
2013-01-18 11:06 ` aoliva at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).