* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
@ 2014-11-24 11:26 ` rguenth at gcc dot gnu.org
2014-11-24 14:52 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-11-24 11:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Priority|P3 |P1
CC| |hubicka at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|Several testsuite execution |[5 Regression] Several
|failures with -O2 -flto |testsuite execution
|-fuse-linker-plugin |failures with -O2 -flto
|-fno-fat-lto-objects |-fuse-linker-plugin
| |-fno-fat-lto-objects
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
2014-11-24 11:26 ` [Bug lto/64025] [5 Regression] " rguenth at gcc dot gnu.org
@ 2014-11-24 14:52 ` hjl.tools at gmail dot com
2014-11-24 18:41 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2014-11-24 14:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-11-24
CC| |enkovich.gnu at gmail dot com,
| |jakub at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It was caused by r216540.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
2014-11-24 11:26 ` [Bug lto/64025] [5 Regression] " rguenth at gcc dot gnu.org
2014-11-24 14:52 ` hjl.tools at gmail dot com
@ 2014-11-24 18:41 ` jakub at gcc dot gnu.org
2014-11-24 18:48 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-24 18:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This breaks because find_base_term is confused by what ix86_find_base_term
(which calls ix86_delegitimize_address) returns, namely the
(something - symbol_ref ("_GLOBAL_OFFSET_TABLE_")) + (const ((symbol_ref ("p")
+ const_int))
as find_base_term considers only one symbol for its purposes.
So, either we change ix86_find_base_term, so that it hides the (something -
symbol_ref ("_GLOBAL_OFFSET_TABLE_")) part - often it stands for 0,
as something is often just VALUE of the pic register or say pic register plus
some variable offset and just returns the other part, or
swap the order of the PLUS operands, so that the (const ...) part comes first
and thus find_base_term first recurses on that, or move
ix86_delegitimize_address to ix86_delegitimize_address_1, call it from
ix86_delegitimize_address with some bool flag allowing what it does now, and
from ix86_find_base_term disallowing that. Or change find_base_term, so that
for PLUS/MINUS it always recurses into both arguments, and if both provide
different bases, returns NULL (though, this change might be too expensive).
Preferences?
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
` (2 preceding siblings ...)
2014-11-24 18:41 ` jakub at gcc dot gnu.org
@ 2014-11-24 18:48 ` jakub at gcc dot gnu.org
2014-11-24 19:00 ` ubizjak at gmail dot com
2014-11-27 11:02 ` jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-24 18:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just to explain more why the strcpy.c testcase breaks.
During postreload cse, we have:
(insn 63 61 70 5 (set (mem/c:QI (plus:SI (reg:SI 5 di [87])
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("p") [flags 0x2] <var_decl
0x7f4bb4427990 p>)
] UNSPEC_GOTOFF)
(const_int 1 [0x1])))) [0 MEM[(void *)&p + 1B]+0 S1
A8])
(const_int 0 [0]))
/usr/src/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strcpy.c:22 93
{*movqi_internal}
(nil))
...
(insn 111 109 113 7 (set (mem/c:SI (plus:SI (reg:SI 5 di [87])
(const:SI (unspec:SI [
(symbol_ref:SI ("p") [flags 0x2] <var_decl
0x7f4bb4427990 p>)
] UNSPEC_GOTOFF))) [0 MEM[(void *)&p]+0 S4 A8])
(const_int 1145258561 [0x44434241]))
/usr/src/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strcpy.c:26 90
{*movsi_internal}
(nil))
and when trying to invalidate memories because of the insn 111 store, we call
find_base_term on:
(plus:SI (value:SI 23:23 @0x2068db0/0x205e3f0)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("p") [flags 0x2] <var_decl 0x7ffff1865990
p>)
] UNSPEC_GOTOFF)
(const_int 1 [0x1]))))
(from the 63 instruction, stored in cselib stuff), and
ix86_delegitimize_address returns
(plus:SI (minus:SI (value:SI 23:23 @0x2068db0/0x205e3f0)
(symbol_ref:SI ("_GLOBAL_OFFSET_TABLE_")))
(const:SI (plus:SI (symbol_ref:SI ("p") [flags 0x2] <var_decl
0x7ffff1865990 p>)
(const_int 1 [0x1]))))
and finally find_base_term returns
(symbol_ref "_GLOBAL_OFFSET_TABLE_") (incorrectly), and then call
find_base_term on:
(plus:SI (reg:SI 5 di [87])
(const:SI (unspec:SI [
(symbol_ref:SI ("p") [flags 0x2] <var_decl 0x7ffff1865990 p>)
] UNSPEC_GOTOFF)))
(directly from the insn, so no VALUEs yet), and as ORIGINAL_REGNO of di is 87 -
the pic reg pseudo, we delegitimize that to
(symbol_ref:SI ("p") [flags 0x2] <var_decl 0x7ffff1865990 p>)
and find_base_term on that is that symbol, and thus we think those two memory
stores don't overlap.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
` (3 preceding siblings ...)
2014-11-24 18:48 ` jakub at gcc dot gnu.org
@ 2014-11-24 19:00 ` ubizjak at gmail dot com
2014-11-27 11:02 ` jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: ubizjak at gmail dot com @ 2014-11-24 19:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> This breaks because find_base_term is confused by what ix86_find_base_term
> (which calls ix86_delegitimize_address) returns, namely the
> (something - symbol_ref ("_GLOBAL_OFFSET_TABLE_")) + (const ((symbol_ref
> ("p") + const_int))
> as find_base_term considers only one symbol for its purposes.
> So, either we change ix86_find_base_term, so that it hides the (something -
> symbol_ref ("_GLOBAL_OFFSET_TABLE_")) part - often it stands for 0,
> as something is often just VALUE of the pic register or say pic register
> plus some variable offset and just returns the other part, or
> swap the order of the PLUS operands, so that the (const ...) part comes
> first and thus find_base_term first recurses on that, or move
> ix86_delegitimize_address to ix86_delegitimize_address_1, call it from
> ix86_delegitimize_address with some bool flag allowing what it does now, and
> from ix86_find_base_term disallowing that. Or change find_base_term, so
> that for PLUS/MINUS it always recurses into both arguments, and if both
> provide different bases, returns NULL (though, this change might be too
> expensive).
> Preferences?
I think that we should just swap the order of the PLUS operands and add some
comment on the expected form of the RTX.
>From gcc-bugs-return-468418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 24 19:01:38 2014
Return-Path: <gcc-bugs-return-468418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16007 invoked by alias); 24 Nov 2014 19:01:38 -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 15917 invoked by uid 48); 24 Nov 2014 19:01:34 -0000
From: "meissner at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63965] [5 Regression] ICE: in extract_constrain_insn, at recog.c:2230 on ppc64
Date: Mon, 24 Nov 2014 19:01: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: meissner at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: meissner at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-63965-4-3y1BEsUeY1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63965-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63965-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/msg02890.txt.bz2
Content-length: 634
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc965
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |ASSIGNED
--- Comment #12 from Michael Meissner <meissner at gcc dot gnu.org> ---
Whoops, I committed the wrong changes. I committed a change that I was working
on (but I had not gotten it to work yet), instead of the fix that was approved.
I have backed out those changes (subversion id 218027), and I will shortly
submit the correct patch.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug lto/64025] [5 Regression] Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
2014-11-22 12:12 [Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects ubizjak at gmail dot com
` (4 preceding siblings ...)
2014-11-24 19:00 ` ubizjak at gmail dot com
@ 2014-11-27 11:02 ` jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-11-27 11:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Nov 27 11:02:02 2014
New Revision: 218119
URL: https://gcc.gnu.org/viewcvs?rev=218119&root=gcc&view=rev
Log:
PR lto/64025
* alias.c (find_base_term): Use std::swap. Prefer tmp2
if it is CONSTANT_P other than CONST_INT.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
^ permalink raw reply [flat|nested] 7+ messages in thread