public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
@ 2014-07-30 20:46 su at cs dot ucdavis.edu
2014-07-31 10:35 ` [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu " rguenth at gcc dot gnu.org
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: su at cs dot ucdavis.edu @ 2014-07-30 20:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Bug ID: 61969
Summary: wrong code by LTO on x86_64-linux-gnu (affecting
trunk, 4.9.x, and 4.8.x)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Created attachment 33217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33217&action=edit
test files and compilation script
The current gcc trunk (as well as gcc 4.8.x and 4.9.x) miscompiles the attached
code when using LTO on x86_64-linux-gnu in 64-bit mode (but not in 32-bit
mode).
This is a regression from 4.7.x.
Sorry that the test case is still pretty complex. It seems very difficult to be
reduced further --- any small changes to the code seem to hide the bug.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140730 (experimental) [trunk revision 213231] (GCC)
$
$ compile.sh
Usage: ./compile.sh <cc> <mode> <lto: 1 | 0>
$ compile.sh gcc-trunk 64 0; t
-25246
$ compile.sh gcc-trunk 64 1; t
-25246
$ compile.sh gcc-trunk 32 0; t
-25246
$ compile.sh gcc-trunk 32 1; t
0
$ compile.sh gcc-4.9 32 1; t
0
$ compile.sh gcc-4.8 32 1; t
2052
$ compile.sh gcc-4.7 32 1; t
-25246
$
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
@ 2014-07-31 10:35 ` rguenth at gcc dot gnu.org
2014-08-01 6:34 ` su at cs dot ucdavis.edu
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-07-31 10:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |i?86-*-*
Target Milestone|--- |4.8.4
Summary|wrong code by LTO on |[4.8/4.9/4.10 Regression]
|x86_64-linux-gnu (affecting |wrong code by LTO on
|trunk, 4.9.x, and 4.8.x) |i?86-linux-gnu (affecting
| |trunk, 4.9.x, and 4.8.x)
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You mean in 32bit mode. I can't reproduce it with trunk or 4.9 but only
with 4.8:
rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1
rguenther@murzim:/tmp> ./t
2052
maybe it's sensitive to the linker used? it works with both GNU ld and gold
for me with 4.9 and trunk.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
2014-07-31 10:35 ` [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu " rguenth at gcc dot gnu.org
@ 2014-08-01 6:34 ` su at cs dot ucdavis.edu
2014-09-28 6:07 ` [Bug lto/61969] [4.8/4.9/5 " andi-gcc at firstfloor dot org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: su at cs dot ucdavis.edu @ 2014-08-01 6:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #2 from Zhendong Su <su at cs dot ucdavis.edu> ---
> You mean in 32bit mode.
Richard, yes, I meant 32-bit mode.
> I can't reproduce it with trunk or 4.9 but only
> with 4.8:
>
> rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1
> rguenther@murzim:/tmp> ./t
> 2052
>
> maybe it's sensitive to the linker used? it works with both GNU ld and gold
> for me with 4.9 and trunk.
I used the GNU gold linker:
$ ld -v
GNU gold (GNU Binutils for Ubuntu 2.22) 1.11
$
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
2014-07-31 10:35 ` [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu " rguenth at gcc dot gnu.org
2014-08-01 6:34 ` su at cs dot ucdavis.edu
@ 2014-09-28 6:07 ` andi-gcc at firstfloor dot org
2014-09-28 6:23 ` andi-gcc at firstfloor dot org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28 6:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Andi Kleen <andi-gcc at firstfloor dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andi-gcc at firstfloor dot org
--- Comment #3 from Andi Kleen <andi-gcc at firstfloor dot org> ---
I did some experiments. I can reproduce it with trunk for 32bit.
The interesting part is that the printed value seems to be uninitialized on the
stack and changes on every run. a valgrind run gives
=23130== Use of uninitialised value of size 4
==23130== at 0x40B102B: _itoa_word (in /lib/libc-2.18.so)
==23130== by 0x40B474A: vfprintf (in /lib/libc-2.18.so)
==23130== by 0x40BAFCE: printf (in /lib/libc-2.18.so)
==23130== by 0x40879D2: (below main) (in /lib/libc-2.18.so)
==23130== Uninitialised value was created by a stack allocation
==23130== at 0x80482F4: main (in /home/andi/Downloads/pr61969/t)
==23130==
... more warnings like this ...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (2 preceding siblings ...)
2014-09-28 6:07 ` [Bug lto/61969] [4.8/4.9/5 " andi-gcc at firstfloor dot org
@ 2014-09-28 6:23 ` andi-gcc at firstfloor dot org
2014-09-28 6:35 ` andi-gcc at firstfloor dot org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28 6:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #4 from Andi Kleen <andi-gcc at firstfloor dot org> ---
The problem is when returning a struct from func_52:
const struct S0 func_52 (uint32_t p_53)
{
const struct S0 l_55 = { 4, 40290, 10, 4 };
return l_55;
}
The main code stores the struct value from the stack into the global variable
and eventually prints it
80482f4: 83 ec 38 sub $0x38,%esp
80482f7: 0f b6 15 4c da 04 08 movzbl 0x804da4c,%edx
80482fe: 8b 1d 20 d1 04 08 mov 0x804d120,%ebx
8048304: 0f b6 35 70 da 04 08 movzbl 0x804da70,%esi
804830b: e8 b0 0c 00 00 call 8048fc0 <func_52>
8048310: 0f b7 45 d2 movzwl -0x2e(%ebp),%eax
8048314: ba 01 00 00 00 mov $0x1,%edx
8048319: c7 05 20 d1 04 08 48 movl $0x804da48,0x804d120
8048320: da 04 08
8048323: 66 a3 5c da 04 08 mov %ax,0x804da5c
But func_52 has been completely optimized away and puts nothing onto the stack:
08048fc0 <func_52>:
8048fc0: f3 c3 repz ret
8048fc2: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi
8048fc9: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi
So the value is random stack garbage.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (3 preceding siblings ...)
2014-09-28 6:23 ` andi-gcc at firstfloor dot org
@ 2014-09-28 6:35 ` andi-gcc at firstfloor dot org
2014-10-07 14:15 ` andi-gcc at firstfloor dot org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28 6:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #5 from Andi Kleen <andi-gcc at firstfloor dot org> ---
func_52 disappears during/after nrv:
in 173t.nrv:
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
func_52 (uint32_t p_53)
{
extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
<retval>];
<bb 2>:
return <retval>;
}
in 174t.optimized
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
func_52 (uint32_t p_53)
{
<bb 2>:
return <retval>;
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (4 preceding siblings ...)
2014-09-28 6:35 ` andi-gcc at firstfloor dot org
@ 2014-10-07 14:15 ` andi-gcc at firstfloor dot org
2014-10-07 14:35 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-10-07 14:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #6 from Andi Kleen <andi-gcc at firstfloor dot org> ---
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.
When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), but that didn't make a
difference.
It converts the local variable to be a value-expr.
It's still not exactly clear who deletes the variable declaration though.
There are two possibilities:
- nrv shouldn't convert the variable in the first place
- someone who messes with the variables forgets to check for value-exprs.
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
NRV Replaced: l_55 with: <retval>
func_52 (uint32_t p_53)
{
extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
<retval>];
<bb 2>:
return <retval>;
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (5 preceding siblings ...)
2014-10-07 14:15 ` andi-gcc at firstfloor dot org
@ 2014-10-07 14:35 ` rguenth at gcc dot gnu.org
2014-10-07 17:53 ` andi at firstfloor dot org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-07 14:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andi Kleen from comment #6)
> I looked at this a bit more. It's definitely the nrv pass that causes the
> problem.
>
> When I disable it in the source code the 32bit version compiles correctly.
> I also tried disabling the next pass (cfgcleanup), but that didn't make a
> difference.
>
> It converts the local variable to be a value-expr.
>
> It's still not exactly clear who deletes the variable declaration though.
>
> There are two possibilities:
> - nrv shouldn't convert the variable in the first place
> - someone who messes with the variables forgets to check for value-exprs.
>
> ;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
> symbol_order=1152)
>
> NRV Replaced: l_55 with: <retval>
> func_52 (uint32_t p_53)
> {
> extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4}
> [value-expr: <retval>];
only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
What does func_52 look like before the NRV pass? It must be sth like
<retval> = l_55;
?
Looks like a bug in nrv to me:
/* The returned value must be a local automatic variable of the
same type and alignment as the function's result. */
if (TREE_CODE (found) != VAR_DECL
|| TREE_THIS_VOLATILE (found)
|| DECL_CONTEXT (found) != current_function_decl
|| TREE_STATIC (found)
|| TREE_ADDRESSABLE (found)
|| DECL_ALIGN (found) > DECL_ALIGN (result)
|| !useless_type_conversion_p (result_type,
TREE_TYPE (found)))
return 0;
should probably use auto_var_in_fn_p which checks for !DECL_EXTERNAL as well.
Index: gcc/tree-nrv.c
===================================================================
--- gcc/tree-nrv.c (revision 215917)
+++ gcc/tree-nrv.c (working copy)
@@ -216,8 +216,7 @@ pass_nrv::execute (function *fun)
same type and alignment as the function's result. */
if (TREE_CODE (found) != VAR_DECL
|| TREE_THIS_VOLATILE (found)
- || DECL_CONTEXT (found) != current_function_decl
- || TREE_STATIC (found)
+ || !auto_var_in_fn_p (found, current_function_decl)
|| TREE_ADDRESSABLE (found)
|| DECL_ALIGN (found) > DECL_ALIGN (result)
|| !useless_type_conversion_p (result_type,
> <bb 2>:
> return <retval>;
>
> }
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (6 preceding siblings ...)
2014-10-07 14:35 ` rguenth at gcc dot gnu.org
@ 2014-10-07 17:53 ` andi at firstfloor dot org
2014-10-08 1:46 ` andi-gcc at firstfloor dot org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi at firstfloor dot org @ 2014-10-07 17:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #8 from andi at firstfloor dot org ---
> only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
It's an initializer for an automatic var in the source
func_52() {
struct S0 foo = { ... }
...
}
>
> What does func_52 look like before the NRV pass? It must be sth like
>
> <retval> = l_55;
>
> ?
Yes it looks like that.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (7 preceding siblings ...)
2014-10-07 17:53 ` andi at firstfloor dot org
@ 2014-10-08 1:46 ` andi-gcc at firstfloor dot org
2014-10-08 14:36 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-10-08 1:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #9 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Patch fixes the test case.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (8 preceding siblings ...)
2014-10-08 1:46 ` andi-gcc at firstfloor dot org
@ 2014-10-08 14:36 ` rguenth at gcc dot gnu.org
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9 " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-08 14:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-10-08
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testing it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (10 preceding siblings ...)
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9 " rguenth at gcc dot gnu.org
@ 2014-10-09 8:22 ` rguenth at gcc dot gnu.org
2014-11-26 13:15 ` [Bug lto/61969] [4.8 " rguenth at gcc dot gnu.org
2014-11-26 13:16 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-09 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Oct 9 08:21:46 2014
New Revision: 216029
URL: https://gcc.gnu.org/viewcvs?rev=216029&root=gcc&view=rev
Log:
2014-10-09 Richard Biener <rguenther@suse.de>
PR tree-optimization/61969
* tree-nrv.c (pass_nrv::execute): Properly test for automatic
variables.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-nrv.c
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8/4.9 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (9 preceding siblings ...)
2014-10-08 14:36 ` rguenth at gcc dot gnu.org
@ 2014-10-09 8:22 ` rguenth at gcc dot gnu.org
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9/5 " rguenth at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-09 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |5.0
Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] wrong
|wrong code by LTO on |code by LTO on
|i?86-linux-gnu (affecting |i?86-linux-gnu (affecting
|trunk, 4.9.x, and 4.8.x) |trunk, 4.9.x, and 4.8.x)
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (11 preceding siblings ...)
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9/5 " rguenth at gcc dot gnu.org
@ 2014-11-26 13:15 ` rguenth at gcc dot gnu.org
2014-11-26 13:16 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-11-26 13:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug lto/61969] [4.8 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
` (12 preceding siblings ...)
2014-11-26 13:15 ` [Bug lto/61969] [4.8 " rguenth at gcc dot gnu.org
@ 2014-11-26 13:16 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-11-26 13:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Nov 26 13:15:16 2014
New Revision: 218079
URL: https://gcc.gnu.org/viewcvs?rev=218079&root=gcc&view=rev
Log:
2014-11-26 Richard Biener <rguenther@suse.de>
Backport from mainline
2014-10-08 Richard Biener <rguenther@suse.de>
PR tree-optimization/61969
* tree-nrv.c (pass_nrv::execute): Properly test for automatic
variables.
2014-08-15 Richard Biener <rguenther@suse.de>
PR tree-optimization/62031
* tree-data-ref.c (dr_analyze_indices): Do not set
DR_UNCONSTRAINED_BASE.
(dr_may_alias_p): All indirect accesses have to go the
formerly DR_UNCONSTRAINED_BASE path.
* tree-data-ref.h (struct indices): Remove
unconstrained_base member.
(DR_UNCONSTRAINED_BASE): Remove.
* gcc.dg/torture/pr62031.c: New testcase.
2014-10-10 Richard Biener <rguenther@suse.de>
PR tree-optimization/63379
* tree-vect-slp.c (vect_get_constant_vectors): Do not compute
a neutral operand for min/max when it is not a reduction chain.
* gcc.dg/vect/pr63379.c: New testcase.
2014-11-07 Richard Biener <rguenther@suse.de>
PR tree-optimization/63605
* fold-const.c (fold_binary_loc): Properly use element_precision
for types that may not be scalar.
* gcc.dg/vect/pr63605.c: New testcase.
2014-10-28 Richard Biener <rguenther@suse.de>
PR middle-end/63665
* fold-const.c (fold_comparison): Properly guard simplifying
against INT_MAX/INT_MIN with !TYPE_OVERFLOW_WRAPS.
* gcc.dg/pr63665.c: New testcase.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63665.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr62031.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63379.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63605.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-data-ref.c
branches/gcc-4_8-branch/gcc/tree-data-ref.h
branches/gcc-4_8-branch/gcc/tree-nrv.c
branches/gcc-4_8-branch/gcc/tree-vect-slp.c
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-11-26 13:15 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 20:46 [Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) su at cs dot ucdavis.edu
2014-07-31 10:35 ` [Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu " rguenth at gcc dot gnu.org
2014-08-01 6:34 ` su at cs dot ucdavis.edu
2014-09-28 6:07 ` [Bug lto/61969] [4.8/4.9/5 " andi-gcc at firstfloor dot org
2014-09-28 6:23 ` andi-gcc at firstfloor dot org
2014-09-28 6:35 ` andi-gcc at firstfloor dot org
2014-10-07 14:15 ` andi-gcc at firstfloor dot org
2014-10-07 14:35 ` rguenth at gcc dot gnu.org
2014-10-07 17:53 ` andi at firstfloor dot org
2014-10-08 1:46 ` andi-gcc at firstfloor dot org
2014-10-08 14:36 ` rguenth at gcc dot gnu.org
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9 " rguenth at gcc dot gnu.org
2014-10-09 8:22 ` [Bug lto/61969] [4.8/4.9/5 " rguenth at gcc dot gnu.org
2014-11-26 13:15 ` [Bug lto/61969] [4.8 " rguenth at gcc dot gnu.org
2014-11-26 13:16 ` rguenth 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).