[Bug rtl-optimization/63483] New: Scheduler performs Invalid move of aliased memory reference

[Bug rtl-optimization/63483] New: Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

            Bug ID: 63483
           Summary: Scheduler performs Invalid move of aliased memory
                    reference
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
                CC: rguenth at gcc dot gnu.org, rth at gcc dot gnu.org

The original problem is present in [1], and can be illustrated by following
test on alpha-linux-gnu:

--cut here--
static char *a;
static char *b;

void foo (void)
{
  a[1] = 1;
  b[2] = 1;
}

int bar (void)
{
  return a && b;
}
--cut here--

The compilation with -O2 produces:

$foo..ng:
        .prologue 1
        lda $1,1($31)
        lda $2,a
        ldq $3,0($2)   <-- load a
        lda $2,b
        lda $7,1($3)
        ldq_u $5,1($3)   <-- load a
        insbl $1,$7,$4
        ldq $2,0($2)   <-- load b
        mskbl $5,$7,$5
        lda $6,2($2)
        bis $4,$5,$4
        stq_u $4,1($3)  <-- store a
        insbl $1,$6,$1
        ldq_u $3,2($2)   <-- load b
        mskbl $3,$6,$3
        cpys $f31,$f31,$f31
        bis $1,$3,$1
        stq_u $1,2($2)   <-- store b
        ret $31,($26),1
        .end foo

if a and b alias to the same wide memory location, then "b"  RMW
sequence corrupts "a".

There is am early shortcut for MEM_READOLNY_P in true_dependence_1 in alias.c.
For the testcase above:

(insn 15 13 18 2 (set (reg/f:DI 78 [ b ])
        (mem/u/f/c:DI (reg/f:DI 79) [2 b+0 S8 A64])) rmw.c:7 226 {*movdi}
     (expr_list:REG_DEAD (reg/f:DI 79)
        (nil)))

is free to be scheduled before

(insn 13 12 15 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72 [ a ])
                    (const_int 1 [0x1]))
                (const_int -8 [0xfffffffffffffff8])) [0  S8 A64])
        (reg:DI 77)) rmw.c:6 226 {*movdi}
     (expr_list:REG_DEAD (reg:DI 77)
        (expr_list:REG_DEAD (reg/f:DI 72 [ a ])
            (nil))))

rth explained situation on alpha a bit:

--quote--
It's not the loads, per se, it's the stores that get in the way.

Early alpha can't store sub-4-byte quantities.  Altivec can't store anything
but 16 byte quantities.  In order to perform smaller stores, we have to do a
read-modify-write sequence on a larger aligned chunk of memory.  Two such RMW
sequences must conflict, lest we interleave and thus bork the operation.

I don't recall how much we ever did for this, exactly, but it's certainly
possible to know that some memory operations cannot conflict with these RMW
sequence.  E.g. through size + alignment of the other memory operation.  E.g.
on Alpha, a byte RMW store can't conflict with a normal DImode memory access.
--/quote--

And:

> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?

This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.

[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02251.html

[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
$foo..ng:
    .prologue 1
    lda $1,1($31)     # 7    *movqi/2    [length = 4]
    lda $2,a     # 27    *movdi/7    [length = 4]
    ldq $3,0($2)     # 6    *movdi/8    [length = 4]
    lda $2,b     # 26    *movdi/7    [length = 4]
    lda $7,1($3)     # 9    *adddi_internal/2    [length = 4]
    ldq_u $5,1($3)     # 8    *movdi/8    [length = 4]
    insbl $1,$7,$4     # 11    insbl    [length = 4]
    ldq $2,0($2)     # 15    *movdi/8    [length = 4]
    mskbl $5,$7,$5     # 10    mskxl    [length = 4]
    lda $6,2($2)     # 18    *adddi_internal/2    [length = 4]
    bis $4,$5,$4     # 12    iordi3/1    [length = 4]
    stq_u $4,1($3)     # 13    *movdi/9    [length = 4]
    insbl $1,$6,$1     # 20    insbl    [length = 4]
    ldq_u $3,2($2)     # 17    *movdi/8    [length = 4]
    mskbl $3,$6,$3     # 19    mskxl    [length = 4]
    cpys $f31,$f31,$f31     # 35    fnop    [length = 4]
    bis $1,$3,$1     # 21    iordi3/1    [length = 4]
    stq_u $1,2($2)     # 22    *movdi/9    [length = 4]
    ret $31,($26),1     # 34    *return_internal    [length = 4]
    .end foo

Before sched1 pass, we have:

    5: r73:DI=`a'
    6: r72:DI=[r73:DI]
      REG_DEAD r73:DI
    7: r74:QI=0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
    9: r75:DI=r72:DI+0x1
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_EQUAL 0x1<<r75:DI<<0x3
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   14: r79:DI=`b'
   15: r78:DI=[r79:DI]
      REG_DEAD r79:DI
   17: r82:DI=[r78:DI+0x2&0xfffffffffffffff8]
   18: r81:DI=r78:DI+0x2
   19: r82:DI=!0xff<<r81:DI<<0x3&r82:DI
   20: r83:DI=zero_extend(r74:QI)<<r81:DI<<0x3
      REG_DEAD r81:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r81:DI<<0x3
   21: r83:DI=r83:DI|r82:DI
      REG_DEAD r82:DI
   22: [r78:DI+0x2&0xfffffffffffffff8]=r83:DI
      REG_DEAD r83:DI
      REG_DEAD r78:DI

Please see (insn 15) going to the top in sched1 pass:

    5: r73:DI=`a'
    7: r74:QI=0x1
   14: r79:DI=`b'
    6: r72:DI=[r73:DI]
      REG_DEAD r73:DI
   15: r78:DI=[r79:DI]
      REG_DEAD r79:DI
    9: r75:DI=r72:DI+0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_EQUAL 0x1<<r75:DI<<0x3
   18: r81:DI=r78:DI+0x2
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   20: r83:DI=zero_extend(r74:QI)<<r81:DI<<0x3
      REG_DEAD r81:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r81:DI<<0x3
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   17: r82:DI=[r78:DI+0x2&0xfffffffffffffff8]
   19: r82:DI=!0xff<<r81:DI<<0x3&r82:DI
   21: r83:DI=r83:DI|r82:DI
      REG_DEAD r82:DI
   22: [r78:DI+0x2&0xfffffffffffffff8]=r83:DI
      REG_DEAD r83:DI
      REG_DEAD r78:DI
   25: NOTE_INSN_DELETED
>From gcc-bugs-return-463528-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 08:40:50 2014
Return-Path: <gcc-bugs-return-463528-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15914 invoked by alias); 8 Oct 2014 08:40:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15860 invoked by uid 48); 8 Oct 2014 08:40:46 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
Date: Wed, 08 Oct 2014 08:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63483-4-1MKrrpWnE1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00549.txt.bz2
Content-length: 516

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 33665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33665&action=edit
Proposed patch

Proposed patch prevents MEM_READONLY_P memory references to be moved over
possibly aliased memory (with alignment ANDs). The patch prevents early exit
for MEM_READONLY_P references when alignemt ANDs are involved. The aliasing is
determined in the code later in the function.
>From gcc-bugs-return-463529-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 08:44:33 2014
Return-Path: <gcc-bugs-return-463529-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20102 invoked by alias); 8 Oct 2014 08:44:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20051 invoked by uid 48); 8 Oct 2014 08:44:27 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
Date: Wed, 08 Oct 2014 08:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63483-4-i0rzbmzAb1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00550.txt.bz2
Content-length: 2471

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
The patched compiler creates prevents scheduler to move "unchanging" reference
over possibly aliasing memory:

    7: r74:QI=0x1
    5: r73:DI=`a'
   14: r79:DI=`b'
    6: r72:DI=[r73:DI]
      REG_DEAD r73:DI
    9: r75:DI=r72:DI+0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_EQUAL 0x1<<r75:DI<<0x3
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   15: r78:DI=[r79:DI]
      REG_DEAD r79:DI
   18: r81:DI=r78:DI+0x2
   17: r82:DI=[r78:DI+0x2&0xfffffffffffffff8]
   20: r83:DI=zero_extend(r74:QI)<<r81:DI<<0x3
      REG_DEAD r81:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r81:DI<<0x3
   19: r82:DI=!0xff<<r81:DI<<0x3&r82:DI
   21: r83:DI=r83:DI|r82:DI
      REG_DEAD r82:DI
   22: [r78:DI+0x2&0xfffffffffffffff8]=r83:DI
      REG_DEAD r83:DI
      REG_DEAD r78:DI
   25: NOTE_INSN_DELETED

which results in:

$foo..ng:
        .prologue 1
        lda $1,1($31)    # 7    *movqi/2        [length = 4]
        lda $2,a         # 5    *movdi/7        [length = 4]
        ldq $2,0($2)     # 6    *movdi/8        [length = 4]
        bis $31,$31,$31  # 34   nop     [length = 4]
        lda $5,1($2)     # 9    *adddi_internal/2       [length = 4]
        ldq_u $4,1($2)   # 8    *movdi/8        [length = 4]
        insbl $1,$5,$3   # 11   insbl   [length = 4]
        mskbl $4,$5,$4   # 10   mskxl   [length = 4]
        bis $3,$4,$3     # 12   iordi3/1        [length = 4]
        stq_u $3,1($2)   # 13   *movdi/9        [length = 4]
        lda $2,b         # 26   *movdi/7        [length = 4]
        ldq $2,0($2)     # 15   *movdi/8        [length = 4]
        lda $4,2($2)     # 18   *adddi_internal/2       [length = 4]
        ldq_u $3,2($2)   # 17   *movdi/8        [length = 4]
        insbl $1,$4,$1   # 20   insbl   [length = 4]
        mskbl $3,$4,$3   # 19   mskxl   [length = 4]
        bis $1,$3,$1     # 21   iordi3/1        [length = 4]
        stq_u $1,2($2)   # 22   *movdi/9        [length = 4]
        ret $31,($26),1  # 33   *return_internal        [length = 4]
        .end foo

e.g. (insn 15) stays after possibly aliasing (insn 13).
>From gcc-bugs-return-463530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:03:41 2014
Return-Path: <gcc-bugs-return-463530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15969 invoked by alias); 8 Oct 2014 09:03:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15838 invoked by uid 48); 8 Oct 2014 09:03:37 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
Date: Wed, 08 Oct 2014 09:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63445-4-nLkLNgb8QO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63445-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63445-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00551.txt.bz2
Content-length: 517

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc445

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The range of n_7 is suboptimal and the test on _6 can be eliminated.

The previous enhancement was apparently:

2010-04-06  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/43627
        * tree-vrp.c (extract_range_from_unary_expr): Widenings
        of [1, +INF(OVF)] go to [1, +INF(OVF)] of the wider type,
        not varying.

but it didn't go far enough for this case.

[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00625.html
>From gcc-bugs-return-463532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:05:34 2014
Return-Path: <gcc-bugs-return-463532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19024 invoked by alias); 8 Oct 2014 09:05:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18984 invoked by uid 48); 8 Oct 2014 09:05:30 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
Date: Wed, 08 Oct 2014 09:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-63483-4-n2UsLnKMJi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00553.txt.bz2
Content-length: 492

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-10-08
           Assignee|unassigned at gcc dot gnu.org      |ubizjak at gmail dot com
     Ever confirmed|0                           |1
>From gcc-bugs-return-463533-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:09:18 2014
Return-Path: <gcc-bugs-return-463533-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23356 invoked by alias); 8 Oct 2014 09:09:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23324 invoked by uid 48); 8 Oct 2014 09:09:14 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
Date: Wed, 08 Oct 2014 09:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords cc
Message-ID: <bug-63480-4-y0SpZOV09o@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63480-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63480-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00554.txt.bz2
Content-length: 595

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Wasn't this fixed for C++ recently? Perhaps the code could be shared... In any
case, they should behave similarly.
>From gcc-bugs-return-463534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:09:47 2014
Return-Path: <gcc-bugs-return-463534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24101 invoked by alias); 8 Oct 2014 09:09:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24071 invoked by uid 48); 8 Oct 2014 09:09:43 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
Date: Wed, 08 Oct 2014 09:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63480-4-h6hh8hjlBj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63480-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63480-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00555.txt.bz2
Content-length: 237

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc480

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think it makes sense just not to warn on { }, much as we intentionally don't
warn for { 0 }.
I'm testing a patch.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |alpha
          Component|rtl-optimization            |target

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The bug is clearly in

"
> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?

This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence."

and thus should be fixed there.  What is the "original" memory reference
here?  It seems for the read-modify-write you should use the target MEM
but somehow a source MEM gets used?  Or rather you should not use either
MEMs flags for _all_ MEMs in the sequence but properly distinguish between
MEMs generated for the load of the source and MEMs generated for the store
to the destination.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #5)
> The bug is clearly in
> 
> "
> > Btw, if the mem is MEM_READONLY_P how can it be part of
> > a {un}aligned_store sequence?
> 
> This flag is copied from the original memory operand of the store by
> alpha_set_memflags to all memory operands in the expanded sequence."
> 
> and thus should be fixed there.  What is the "original" memory reference
> here?  It seems for the read-modify-write you should use the target MEM
> but somehow a source MEM gets used?  Or rather you should not use either
> MEMs flags for _all_ MEMs in the sequence but properly distinguish between
> MEMs generated for the load of the source and MEMs generated for the store
> to the destination.

No, this is wrong conclusion. I have new insight into this problem.

Please consider following test:

--cut here--
static char *a;
static int *b;

void foo (void)
{
  a[1] = 1;
  b[2] = 1;
}

int bar (void)
{
  return a && b;
}
--cut here--

(e.g. changing "static char *b" to "static int *b". This way, the problematic
insn is generated as "native" read:

(insn 15 14 16 2 (set (reg/f:DI 78)
        (mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
                (symbol_ref:DI ("b") [flags 0x6]  <var_decl 0x2b1d67f5e090 b>))
[2 b+0 S8 A64])) rmw1.c:7 -1
     (nil))

and this is again moved over

(insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
                    (const_int 1 [0x1]))
                (const_int -8 [0xfffffffffffffff8])) [0  S8 A64])
        (reg:DI 77)) rmw1.c:6 -1
     (nil))

(note that there is no "/u" suffix on the *store* of "a".)

With this testcase, we have following sequence before sched1 pass:

    5: r73:DI=high(`a')
    6: r72:DI=[r73:DI+low(`a')]
      REG_DEAD r73:DI
    7: r74:QI=0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
    9: r75:DI=r72:DI+0x1
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r75:DI<<0x3
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   14: r79:DI=high(`b')
   15: r78:DI=[r79:DI+low(`b')]
      REG_DEAD r79:DI
   16: r80:SI=0x1
   17: [r78:DI+0x8]=r80:SI
      REG_DEAD r80:SI
      REG_DEAD r78:DI

and sched1 moves (insn 15) all the way up, past (insn 13):

    5: r73:DI=high(`a')
   14: r79:DI=high(`b')
    7: r74:QI=0x1
    6: r72:DI=[r73:DI+low(`a')]
      REG_DEAD r73:DI
   16: r80:SI=0x1
   15: r78:DI=[r79:DI+low(`b')]
      REG_DEAD r79:DI
    9: r75:DI=r72:DI+0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r75:DI<<0x3
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   17: [r78:DI+0x8]=r80:SI
      REG_DEAD r80:SI
      REG_DEAD r78:DI
   20: NOTE_INSN_DELETED

(this particular sequence won't end in a failure, but the insn shouldn't be
moved past possibly aliasing (insn 13) anyway.

Patched compiler results in:

    5: r73:DI=high(`a')
    7: r74:QI=0x1
   14: r79:DI=high(`b')
    6: r72:DI=[r73:DI+low(`a')]
      REG_DEAD r73:DI
   16: r80:SI=0x1
    9: r75:DI=r72:DI+0x1
    8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
   11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
      REG_DEAD r75:DI
      REG_DEAD r74:QI
      REG_EQUAL 0x1<<r75:DI<<0x3
   10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
   12: r77:DI=r77:DI|r76:DI
      REG_DEAD r76:DI
   13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
      REG_DEAD r77:DI
      REG_DEAD r72:DI
   15: r78:DI=[r79:DI+low(`b')]
      REG_DEAD r79:DI
   17: [r78:DI+0x8]=r80:SI
      REG_DEAD r80:SI
      REG_DEAD r78:DI

As shown, the code further down in true_dependence_1 function blocks the move,
since the read is detected as aliased with the preceding store involving AND
alignment.

There is nothing that can be done in target-dependant code, since the "native"
read from "b" gets marked as "unchanging" by the generic middle-end code.

Please reconsider the "component" setting. There is nothing that can be fixed
in target-dependent code.
>From gcc-bugs-return-463550-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 11:48:13 2014
Return-Path: <gcc-bugs-return-463550-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16668 invoked by alias); 8 Oct 2014 11:48:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16620 invoked by uid 48); 8 Oct 2014 11:48:09 -0000
From: "aivchenk at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
Date: Wed, 08 Oct 2014 11:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aivchenk at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62053-4-hMUTeG9PvC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62053-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62053-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00571.txt.bz2
Content-length: 273

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb053

--- Comment #5 from Alexander Ivchenko <aivchenk at gmail dot com> ---
Ping.. any updates? We cannot build Android since the beginning of Jul, and,
hence, cannot evaluate 5.0 candidate for it. I find it very unfortunate

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
How can I reproduce this?  Even with -mcpu=ev4 I get

$foo..ng:
foo:
        .frame $30,0,$26,0
$LFB0:
        .cfi_startproc
        .prologue 0
        mov $31,$2
        ldq_u $1,1($2)
        zapnot $1,253,$1
        stq_u $1,1($2)
        call_pal 0x81

I configured with --target=alphaev68-linux-gnu

And used -O2 -mcpu=ev4 (sounds "earliest").

Note that the pointers 'a' and 'b' are likely made constant by IPA reference
and thus loads of the pointers can validly get /u, but not loads from the
pointers (well, we may even figure out their value is always zero...).

Does it "fix" the testcase if you have a function writing to a and b or
making a and b not static?

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> How can I reproduce this?  Even with -mcpu=ev4 I get
> 
> $foo..ng:
> foo:
>         .frame $30,0,$26,0
> $LFB0:
>         .cfi_startproc
>         .prologue 0
>         mov $31,$2
>         ldq_u $1,1($2)
>         zapnot $1,253,$1
>         stq_u $1,1($2)
>         call_pal 0x81
> 
> I configured with --target=alphaev68-linux-gnu
> 
> And used -O2 -mcpu=ev4 (sounds "earliest").
> 
> Note that the pointers 'a' and 'b' are likely made constant by IPA reference
> and thus loads of the pointers can validly get /u, but not loads from the
> pointers (well, we may even figure out their value is always zero...).

Indeed.  From my .optimized dump:

foo ()
{
  <bb 2>:
  MEM[(char *)0B + 1B] ={v} 0;
  __builtin_trap ();


> Does it "fix" the testcase if you have a function writing to a and b or
> making a and b not static?

Then I get

$foo..ng:
        .prologue 1
        ldq $1,a($29)           !literal
        ldq $2,0($1)
        lda $1,1($31)
        cpys $f31,$f31,$f31
        lda $4,1($2)
        ldq_u $3,1($2)
        insbl $1,$4,$1
        mskbl $3,$4,$3
        bis $1,$3,$1
        stq_u $1,1($2)
        lda $2,1($31)
        ldq $1,b($29)           !literal
        ldq $1,0($1)
        stl $2,8($1)
        ret $31,($26),1

not sure if that's correct.  Adjusted testcase:

char *a;
int *b;

void foo (void)
{
  a[1] = 1;
  b[2] = 1;
}

int bar (void)
{
  return a && b;
}

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, I believe that even

char * const a;
int * const b;

void foo (void)
{
  a[1] = 1;
  b[2] = 1;
}

int bar (void)
{
  return a && b;
}

does not reproduces the issue.

$foo..ng:
        .prologue 1
        ldq $1,a($29)           !literal
        ldq $2,0($1)
        ldq $1,b($29)           !literal
        bis $31,$31,$31
        lda $4,1($2)
        ldq_u $3,1($2)
        ldq $5,0($1)
        lda $1,1($31)
        insbl $1,$4,$1
        mskbl $3,$4,$3
        bis $1,$3,$1
        stq_u $1,1($2)
        lda $1,1($31)
        stl $1,8($5)
        ret $31,($26),1

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #10)
> Ok, I believe that even
> 
> char * const a;
> int * const b;
> 
> void foo (void)
> {
>   a[1] = 1;
>   b[2] = 1;
> }
> 
> int bar (void)
> {
>   return a && b;
> }
> 
> does not reproduces the issue.
> 
> $foo..ng:
>         .prologue 1
>         ldq $1,a($29)           !literal
>         ldq $2,0($1)
>         ldq $1,b($29)           !literal
>         bis $31,$31,$31
>         lda $4,1($2)
>         ldq_u $3,1($2)
>         ldq $5,0($1)              <- this is (insn 15)
>         lda $1,1($31)
>         insbl $1,$4,$1
>         mskbl $3,$4,$3
>         bis $1,$3,$1
>         stq_u $1,1($2)            <- this is (insn 13)
>         lda $1,1($31)
>         stl $1,8($5)
>         ret $31,($26),1

$foo..ng:
        .prologue 1
        lda $1,a         # 5    *movdi/7        [length = 4]
        ldq $2,0($1)     # 6    *movdi/8        [length = 4]
        lda $1,b         # 23   *movdi/7        [length = 4]
        bis $31,$31,$31  # 31   nop     [length = 4]
        lda $4,1($2)     # 9    *adddi_internal/2       [length = 4]
        ldq_u $3,1($2)   # 8    *movdi/8        [length = 4]
        ldq $5,0($1)     # 15   *movdi/8        [length = 4]
        lda $1,1($31)    # 22   *movqi/2        [length = 4]
        insbl $1,$4,$1   # 11   insbl   [length = 4]
        mskbl $3,$4,$3   # 10   mskxl   [length = 4]
        bis $1,$3,$1     # 12   iordi3/1        [length = 4]
        stq_u $1,1($2)   # 13   *movdi/9        [length = 4]
        lda $1,1($31)    # 21   *movsi/2        [length = 4]
        stl $1,8($5)     # 17   *movsi/6        [length = 4]
        ret $31,($26),1  # 30   *return_internal        [length = 4]


    5: $1:DI=`a'
      REG_EQUIV `a'
    6: $2:DI=[$1:DI]
      REG_DEAD $1:DI
   23: $1:DI=`b'
      REG_EQUIV `b'
   31: 0
    9: $4:DI=$2:DI+0x1
    8: $3:DI=[$2:DI+0x1&0xfffffffffffffff8]
   15: $5:DI=[$1:DI]
      REG_DEAD $1:DI
   22: $1:QI=0x1
      REG_EQUIV 0x1
   11: $1:DI=zero_extend($1:QI)<<$4:DI<<0x3
      REG_EQUAL 0x1<<$4:DI<<0x3
   10: $3:DI=!0xff<<$4:DI<<0x3&$3:DI
      REG_DEAD $4:DI
   12: $1:DI=$1:DI|$3:DI
      REG_DEAD $3:DI
   13: [$2:DI+0x1&0xfffffffffffffff8]=$1:DI
      REG_DEAD $2:DI
      REG_DEAD $1:DI
   21: $1:SI=0x1
      REG_EQUIV 0x1
   17: [$5:DI+0x8]=$1:SI
      REG_DEAD $5:DI
      REG_DEAD $1:SI
   30: return
   29: barrier
   20: NOTE_INSN_DELETED
   24: NOTE_INSN_DELETED

My dumps were with -mexplicit-relocs for some reason, the above are with
-mno-explicit-relocs.
>From gcc-bugs-return-463581-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 15:34:16 2014
Return-Path: <gcc-bugs-return-463581-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17308 invoked by alias); 8 Oct 2014 15:34:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17286 invoked by uid 55); 8 Oct 2014 15:34:13 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libquadmath/63487] typo in documentation
Date: Wed, 08 Oct 2014 15:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libquadmath
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63487-4-2YjYerzqny@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63487-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63487-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00602.txt.bz2
Content-length: 421

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc487

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Wed Oct  8 15:33:41 2014
New Revision: 216006

URL: https://gcc.gnu.org/viewcvs?rev!6006&root=gcc&view=rev
Log:
    PR libquadmath/63487
    * libquadmath.texi (sincosq): Fix typo.

Modified:
    trunk/libquadmath/ChangeLog
    trunk/libquadmath/libquadmath.texi

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #12)
> I still don't get it.  What we end up doing is
> 
>   reg:DI 72 = /u load from 'a'  (insn 6)
>   reg:DI 78 = /u load from 'b'  (insn 15)
> ...
>   RMW sequence on (mem:DI (reg:DI 72 ...
>   store to (mem:SI (reg:DI 78 ...
> 
> thus completely fine (after sched1).  sched2 then moves the /u load from
> 'b' until after the R of the RMW sequence, but that's fine.

This is wrong. The move should not pass the W part of the RMW sequence.

> Now I think you seem to say that this isn't about /u or whatever but
> the common issue that for example for globals
> 
> char c, d;
> 
> two RMW sequences to store to c and d may not overlap if 'c' and 'd' are
> not padded out to DImode.
> 
> But this is an issue on all targets (ISTR a bug about this), and if
> that happens it introduces a store data race that is not allowed with
> the C++ memory model for example.  Bad luck for early alphas then I'd say.

Yes, this is the problem. For the original problem, "c" and "d" live in the
same 8-byte memory location. So memory access with 8-byte granularity aliases
both values. There is a code that prevents memory reads to be moved across
memory writes with alignment ANDs, but /u reads get treated specially and
bypass this code under "can't alias anything due to constness" assumption.

> At least I can see nothing wrong with the code generated for the two
> testcases
> you provided nor is the fix you propose any good (I see nothing else but
> the (and:DI ...) addressing that might possibly serve as "barrier" here,
> but even that would not be enough for, say
> 
> char c __attribute__((aligned(8)));
> char d;
> 
> because then we hopefully optimize that AND away for the load from c.

True, but there will be alignment ANDs in the access of "d". This is the reason
to check both operands for ANDs and in this case pass them down to the code
that handles operands with alignment ANDs to determine their aliasing.

> Can you clarify whether I miss anything with the code generated for the
> testcase?

If we can't guarantee that the value lives outside aliased location, then reads
of this value should not pass writes with alignment ANDs (that could possibly
alias the location of read), no matter if they are /u or not.

IMO, /u reads should be handled as non-/u reads and should not pass writes with
alignment ANDs. This is what my patch does.
>From gcc-bugs-return-463668-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 12:45:57 2014
Return-Path: <gcc-bugs-return-463668-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18413 invoked by alias); 9 Oct 2014 12:45:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18363 invoked by uid 48); 9 Oct 2014 12:45:53 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63380] [5 Regression] Wrong constant folding
Date: Thu, 09 Oct 2014 12:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63380-4-XoUorJNboh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63380-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63380-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00689.txt.bz2
Content-length: 428

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc380

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
> 
> --- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
> (In reply to Richard Biener from comment #12)
> > I still don't get it.  What we end up doing is
> > 
> >   reg:DI 72 = /u load from 'a'  (insn 6)
> >   reg:DI 78 = /u load from 'b'  (insn 15)
> > ...
> >   RMW sequence on (mem:DI (reg:DI 72 ...
> >   store to (mem:SI (reg:DI 78 ...
> > 
> > thus completely fine (after sched1).  sched2 then moves the /u load from
> > 'b' until after the R of the RMW sequence, but that's fine.
> 
> This is wrong. The move should not pass the W part of the RMW sequence.
> 
> > Now I think you seem to say that this isn't about /u or whatever but
> > the common issue that for example for globals
> > 
> > char c, d;
> > 
> > two RMW sequences to store to c and d may not overlap if 'c' and 'd' are
> > not padded out to DImode.
> > 
> > But this is an issue on all targets (ISTR a bug about this), and if
> > that happens it introduces a store data race that is not allowed with
> > the C++ memory model for example.  Bad luck for early alphas then I'd say.
> 
> Yes, this is the problem. For the original problem, "c" and "d" live in the
> same 8-byte memory location. So memory access with 8-byte granularity aliases
> both values. There is a code that prevents memory reads to be moved across
> memory writes with alignment ANDs, but /u reads get treated specially and
> bypass this code under "can't alias anything due to constness" assumption.
> 
> > At least I can see nothing wrong with the code generated for the two
> > testcases
> > you provided nor is the fix you propose any good (I see nothing else but
> > the (and:DI ...) addressing that might possibly serve as "barrier" here,
> > but even that would not be enough for, say
> > 
> > char c __attribute__((aligned(8)));
> > char d;
> > 
> > because then we hopefully optimize that AND away for the load from c.
> 
> True, but there will be alignment ANDs in the access of "d". This is the reason
> to check both operands for ANDs and in this case pass them down to the code
> that handles operands with alignment ANDs to determine their aliasing.
> 
> > Can you clarify whether I miss anything with the code generated for the
> > testcase?
> 
> If we can't guarantee that the value lives outside aliased location, then reads
> of this value should not pass writes with alignment ANDs (that could possibly
> alias the location of read), no matter if they are /u or not.
> 
> IMO, /u reads should be handled as non-/u reads and should not pass writes with
> alignment ANDs. This is what my patch does.

I see.  But you don't touch write_dependence which has a similar check.
And instead of making the check for AND disable the MEM_READONLY_P
early-out wouldn't it be more correct to treat MEMs with AND addresses
as true barriers?  That is,

 if (GET_CODE (x_addr) == AND
     || GET_CODE (mem_addr) == AND)
   return 1;

 if (MEM_READONLY_P (x))
   return 0;

instead?  I see we're trying to be clever with AND addresses even
though they are "barriers", why's that?

Note that all this should only ever be an issue with that very old Alpha
as other archs should implement the C++ memory model properly.

Richard.
>From gcc-bugs-return-463671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 13:10:38 2014
Return-Path: <gcc-bugs-return-463671-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2217 invoked by alias); 9 Oct 2014 13:10:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2167 invoked by uid 48); 9 Oct 2014 13:10:34 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63483] Scheduler performs Invalid move of aliased memory reference
Date: Thu, 09 Oct 2014 13:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63483-4-X4uvasUDpm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00692.txt.bz2
Content-length: 1601

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to rguenther@suse.de from comment #14)

> I see.  But you don't touch write_dependence which has a similar check.

I have in fact changed all these places (I will attach the patch momentarily),
but the attached test check one location only. After the approach is considered
OK, the others are trivial to add.

> And instead of making the check for AND disable the MEM_READONLY_P
> early-out wouldn't it be more correct to treat MEMs with AND addresses
> as true barriers?  That is,
> 
>  if (GET_CODE (x_addr) == AND
>      || GET_CODE (mem_addr) == AND)
>    return 1;
> 
>  if (MEM_READONLY_P (x))
>    return 0;
> 
> instead?  I see we're trying to be clever with AND addresses even
> though they are "barriers", why's that?

This was my first approach. But DImode (8-byte) reads, aligned to their natural
alignment, can't alias locations that are re-aligned to 8-bytes using alignment
ANDs. This is what the code downstream handles, so the approach, proposed above
would penalize DImode reads too much.

> Note that all this should only ever be an issue with that very old Alpha
> as other archs should implement the C++ memory model properly.

Unfortunately, I have to agree. The alternative would be a target-specific
change that would mark all memory in RMW sequence with some kind of barrier.
IMO, the generic change is preferable, since it doesn't affect other targets,
and makes aliasing more robust w.r.t. to target peculiarities.
>From gcc-bugs-return-463670-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 13:10:11 2014
Return-Path: <gcc-bugs-return-463670-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1308 invoked by alias); 9 Oct 2014 13:10:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1179 invoked by uid 48); 9 Oct 2014 13:10:04 -0000
From: "venkataramanan.kumar at amd dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62308] A bug with aarch64 big-endian
Date: Thu, 09 Oct 2014 13:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ABI
X-Bugzilla-Severity: major
X-Bugzilla-Who: venkataramanan.kumar at amd dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: venkataramanan.kumar at amd dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62308-4-hOj1Sx7jEF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62308-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62308-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00691.txt.bz2
Content-length: 1602

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb308

--- Comment #7 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
I tried to look at the RTL and assembly code generated after the patch comitted
in 215707.

The code generated looks good some unoptimal code but it is at -O0.

        sub     sp, sp, #16     // 15   *adddi3_aarch64/3       [length = 4]
        mov     x2, x0  // 2    *movdi_aarch64/1        [length = 4]
        mov     x0, x2  // 5    *movdi_aarch64/1        [length = 4]
        fmov    d0, x1  // 22   move_lo_quad_internal_be_v4si/2 [length = 4]
        ins     v0.d[1], x0     // 23   aarch64_simd_move_hi_quad_be_v4si/2
[length = 4]
        str     q0, [sp]        // 7    *aarch64_simd_movv4si/2 [length = 4]
        nop     // 13   nop     [length = 4]
        add     sp, sp, 16      // 18   *adddi3_aarch64/1       [length = 4]
        ret     // 20   *do_return      [length = 4]

The patch r215707 tries to fix situation where paradoxial subregister access
with register X0 results results in acessing register -1 in bigendian.

The same situation happens for this bug.

insn 3 2 4 2 (set (reg:DI 76)
        (reg:DI 1 x1 [ args+8 ])) test.c:3 35 {*movdi_aarch64}
     (expr_list:REG_DEAD (reg:DI 1 x1 [ args+8 ])
        (nil)))
(insn 4 3 5 2 (set (reg:TI 74)
        (subreg:TI (reg:DI 76) 0)) test.c:3 38 {*movti_aarch64}
     (expr_list:REG_DEAD (reg:DI 76)
        (nil)))

Where reload gets

(set (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ]))
(set (reg:TI 0 x0 [74]) (reg:TI -1 [+-8 ])

Looks same issue to me.

Vladimir can you please confirm.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33665|0                           |1
        is obsolete|                            |

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 33672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33672&action=edit
Updated patch.
>From gcc-bugs-return-463673-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 13:14:48 2014
Return-Path: <gcc-bugs-return-463673-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4463 invoked by alias); 9 Oct 2014 13:14:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4428 invoked by uid 48); 9 Oct 2014 13:14:44 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63483] Scheduler performs Invalid move of aliased memory reference
Date: Thu, 09 Oct 2014 13:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63483-4-mwlz1q8JAb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00694.txt.bz2
Content-length: 336

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #15)

> ... but the attached test check one location only.

I shoud say:

... but the test from the Description depends specifically on the code, touched
by the patch.
>From gcc-bugs-return-463674-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 13:26:28 2014
Return-Path: <gcc-bugs-return-463674-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10123 invoked by alias); 9 Oct 2014 13:26:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10086 invoked by uid 48); 9 Oct 2014 13:26:25 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
Date: Thu, 09 Oct 2014 13:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-57003-4-9VUDxXs8eL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57003-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57003-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00695.txt.bz2
Content-length: 502

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|5.0                         |4.8.4

--- Comment #32 from Uroš Bizjak <ubizjak at gmail dot com> ---
Again fixed everywhere.
>From gcc-bugs-return-463675-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 09 15:24:41 2014
Return-Path: <gcc-bugs-return-463675-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17120 invoked by alias); 9 Oct 2014 15:24:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17077 invoked by uid 55); 9 Oct 2014 15:24:37 -0000
From: "dave.anglin at bell dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
Date: Thu, 09 Oct 2014 15:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dave.anglin at bell dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63471-4-aF1mXdxxZq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63471-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63471-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00696.txt.bz2
Content-length: 1081

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc471

--- Comment #6 from dave.anglin at bell dot net ---
On 10/8/2014 11:07 PM, jb at gcc dot gnu.org wrote:
> That being said, googling this issue I stumbled upon
> https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html  where you fixed a
> similar issue for hp-ux 10, seemingly by making the driver always set
> _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as
> well? If there are no ill effects of always enabling _REENTRANT that would help
> other software than just libgfortran, as well as eliminating the risk that
> unconditionally enabling _REENTRANT in libgfortran might break on some other
> target?
It's certainly easy to make the same change to hp-ux 11.  I was
clearly wrong about the guards being removed.

I suspect HP introduced the _REENTRANT guard because they wanted to
remove the _r routines:
http://h21007.www2.hp.com/portal/download/files/unprot/stk/tru64_stk/impacts/i24.html

However, they are not gone so I think we should define _REENTRANT
if there are no ill effects.

Dave

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenther at suse dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3410 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
> 
> Uroš Bizjak <ubizjak at gmail dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>   Attachment #33665|0                           |1
>         is obsolete|                            |
> 
> --- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
> Created attachment 33672
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33672&action=edit
> Updated patch.

Looks ok with all the explanation.  I wonder when is the appropriate
time to retire support for architectures without byte granular
memory access.
>From gcc-bugs-return-463725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 10 07:12:01 2014
Return-Path: <gcc-bugs-return-463725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23201 invoked by alias); 10 Oct 2014 07:12:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23159 invoked by uid 48); 10 Oct 2014 07:11:56 -0000
From: "richard at netbsd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63352] problem with fmt_g0_1.f08  on i386-pc-solaris2.11
Date: Fri, 10 Oct 2014 07:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: richard at netbsd dot org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63352-4-GE1ZUf9Vaa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00746.txt.bz2
Content-length: 722

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc352

--- Comment #17 from Richard PALO <richard at netbsd dot org> ---
Created attachment 33675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3675&actioníit
c test program for snprintf

I tried the attached test program and post the following results from my system
demonstrating that the 'f' format does indeed seem erroneous, at least for the
particular case in hand involving '1/3':

$ /opt/local/gcc49/bin/gcc -stdÉ9 cflt.c
$ ./a.out
FLT_EVAL_METHOD = 2
(e) 1/3 => +3.33333333333333312e-01
(f) 1/3 => +0.33333333333333332
(e) 1/7 => +1.42857142857142848e-01
(f) 1/7 => +0.14285714285714284
(e) 1/9 => +1.11111111111111104e-01
(f) 1/9 => +0.11111111111111110

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4906 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #19 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to rguenther@suse.de from comment #18)

> Looks ok with all the explanation.  I wonder when is the appropriate
> time to retire support for architectures without byte granular
> memory access.

Thanks for your discussion! I will prepare a formal patch submission.
>From gcc-bugs-return-463739-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 10 10:30:19 2014
Return-Path: <gcc-bugs-return-463739-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13409 invoked by alias); 10 Oct 2014 10:30:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13097 invoked by uid 48); 10 Oct 2014 10:30:13 -0000
From: "fdumont at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
Date: Fri, 10 Oct 2014 10:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fdumont at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63500-4-vqBTKyQYmy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63500-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63500-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00760.txt.bz2
Content-length: 374

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500

--- Comment #5 from François Dumont <fdumont at gcc dot gnu.org> ---
I never understood why safe iterators operators are not simply calling
respective operator on the underlying iterator. All operators are respecting
this rule except the operator->. So I will try to use this rule and see if it
fixes this issue.
>From gcc-bugs-return-463740-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 10 10:47:36 2014
Return-Path: <gcc-bugs-return-463740-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 397 invoked by alias); 10 Oct 2014 10:47:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 362 invoked by uid 48); 10 Oct 2014 10:47:33 -0000
From: "richard at netbsd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63352] problem with fmt_g0_1.f08  on i386-pc-solaris2.11
Date: Fri, 10 Oct 2014 10:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: richard at netbsd dot org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-63352-4-FH0CHaa1xH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63352-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00761.txt.bz2
Content-length: 523

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc352

Richard PALO <richard at netbsd dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33676|0                           |1
        is obsolete|                            |

--- Comment #19 from Richard PALO <richard at netbsd dot org> ---
Created attachment 33680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3680&actioníit
-std= agnostic version

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Oct 10 17:36:21 2014
New Revision: 216100

URL: https://gcc.gnu.org/viewcvs?rev=216100&root=gcc&view=rev
Log:
    PR rtl-optimization/63483
    * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P
    references when alignment ANDs are involved.
    (write_dependence_p): Ditto.
    (may_alias_p): Ditto.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/alias.c

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov  5 12:02:17 2014
New Revision: 217119

URL: https://gcc.gnu.org/viewcvs?rev=217119&root=gcc&view=rev
Log:
    Backport from mainline:
    2014-10-20  Uros Bizjak  <ubizjak@gmail.com>

    * varasm.c (const_alias_set): Remove.
    (init_varasm_once): Remove initialization of const_alias_set.
    (build_constant_desc): Do not set alias set to const_alias_set.

    Backport from mainline:
    2014-10-14  Uros Bizjak  <ubizjak@gmail.com>

    PR rtl-optimization/63475
    * alias.c (true_dependence_1): Always use get_addr to extract
    true address operands from x_addr and mem_addr.  Use extracted
    address operands to check for references with alignment ANDs.
    Use extracted address operands with find_base_term and
    base_alias_check. For noncanonicalized operands call canon_rtx with
    extracted address operand.
    (write_dependence_1): Ditto.
    (may_alias_p): Ditto.  Remove unused calls to canon_rtx.

    Backport from mainline:
    2014-10-10  Uros Bizjak  <ubizjak@gmail.com>

    PR rtl-optimization/63483
    * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P
    references when alignment ANDs are involved.
    (write_dependence_p): Ditto.
    (may_alias_p): Ditto.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/alias.c
    branches/gcc-4_9-branch/gcc/varasm.c

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.3

--- Comment #22 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed for 4.9+.
>From gcc-bugs-return-465788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 05 12:17:30 2014
Return-Path: <gcc-bugs-return-465788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31804 invoked by alias); 5 Nov 2014 12:17:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31730 invoked by uid 48); 5 Nov 2014 12:17:22 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
Date: Wed, 05 Nov 2014 12:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-63475-4-tseY3xlQ0x@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63475-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63475-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00260.txt.bz2
Content-length: 495

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|5.0                         |4.9.3

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed for 4.9.3+.
>From gcc-bugs-return-465789-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 05 12:29:57 2014
Return-Path: <gcc-bugs-return-465789-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10567 invoked by alias); 5 Nov 2014 12:29:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10289 invoked by uid 48); 5 Nov 2014 12:29:52 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
Date: Wed, 05 Nov 2014 12:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget cf_gcchost target_milestone cf_gccbuild
Message-ID: <bug-63747-4-GKiGfCzs5l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63747-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63747-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00261.txt.bz2
Content-length: 451

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc747

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm
               Host|                            |arm
   Target Milestone|---                         |5.0
              Build|                            |arm

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Feb 20 12:04:21 2015
New Revision: 220854

URL: https://gcc.gnu.org/viewcvs?rev=220854&root=gcc&view=rev
Log:
    Backport from mainline
    2015-01-22 Wei Mi <wmi@google.com>

    PR rtl-optimization/64557
    * dse.c (record_store): Call get_addr for mem_addr.
    (check_mem_read_rtx): Likewise.

    Backport from mainline
    2014-10-20  Uros Bizjak  <ubizjak@gmail.com>

    * varasm.c (const_alias_set): Remove.
    (init_varasm_once): Remove initialization of const_alias_set.
    (build_constant_desc): Do not set alias set to const_alias_set.

    Backport from mainline
    2014-10-14  Uros Bizjak  <ubizjak@gmail.com>

    PR rtl-optimization/63475
    * alias.c (true_dependence_1): Always use get_addr to extract
    true address operands from x_addr and mem_addr.  Use extracted
    address operands to check for references with alignment ANDs.
    Use extracted address operands with find_base_term and
    base_alias_check. For noncanonicalized operands call canon_rtx with
    extracted address operand.
    (write_dependence_1): Ditto.
    (may_alias_p): Ditto.  Remove unused calls to canon_rtx.

    Backport from mainline
    2014-10-10  Uros Bizjak  <ubizjak@gmail.com>

    PR rtl-optimization/63483
    * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P
    references when alignment ANDs are involved.
    (write_dependence_p): Ditto.
    (may_alias_p): Ditto.

    Backport from mainline
    2013-03-26  Richard Biener  <rguenther@suse.de>

    * alias.c (find_base_term): Avoid redundant and not used recursion.
    (base_alias_check): Get the initial base term from the caller.
    (true_dependence_1): Compute and pass base terms to base_alias_check.
    (write_dependence_p): Likewise.
    (may_alias_p): Likewise.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/alias.c
    branches/gcc-4_8-branch/gcc/dse.c
    branches/gcc-4_8-branch/gcc/varasm.c