https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107212
Bug ID: 107212
Summary: -O2 and -O3 optimizer bug
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Known to w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778
Mark Wieczorek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2019-09-16 00:00:00 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778
--- Comment #1 from Andrew Pinski ---
Are you using c bindings to bind to fftw functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778
Bug ID: 91778
Summary: gfortran GCC9 optimizer bug
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #10 from Daniel Richard G. ---
Okay. I'll accept that the code is dodgy. Thanks for looking into this.
I'll keep in mind -fsanitize=undefined as a way of tracking down these issues
in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #8 from Daniel Richard G. ---
The most I could tell via strategic printf() calls is that everything appears
to run correctly up until the binary search. I don't think any (unchecked)
overflow is at issue, but it seems I don't have a w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #7 from Andrew Pinski ---
(In reply to Daniel Richard G. from comment #6)
> Unfortunately, this GCC build does not have libsanitizer, as it is on an
> older (Linux) system without the necessary system headers.
>
> $ gcc -O2 -fsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #6 from Daniel Richard G. ---
Unfortunately, this GCC build does not have libsanitizer, as it is on an older
(Linux) system without the necessary system headers.
$ gcc -O2 -fsanitize=undefined gcc9-opt-bug.c -o bug
/usr/bin/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #5 from Andrew Pinski ---
Also does -fsanitize=undefined print anything at runtime? If so there is no
bug with GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
--- Comment #4 from Daniel Richard G. ---
Yes, that is the case:
$ gcc -O2 gcc9-opt-bug.c -o bug
$ ./bug
WRONG 13
result: t = 18446744073709551615 (wrong)
$ gcc -O2 -fwrapv gcc9-opt-bug.c -o bug
$ ./bug
result: t = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
Daniel Richard G. changed:
What|Removed |Added
Attachment #46761|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91555
Bug ID: 91555
Summary: [9.2 regression] Optimizer bug
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Markus Trippelsdorf changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #6 from Mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #5 from Casey Carter ---
I have verified that gcc-6-branch compiles the repro correctly, so yes, this is
a dup of PR78047.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #2 from Casey Carter ---
Created attachment 40371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40371&action=edit
compressed preprocessed repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Bug ID: 78841
Summary: [6 regression] optimizer bug (silent bad codegen)
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to janus from comment #4)
> > This seems to be a regression that started with version 4.9. In 4.7 and 4.8
> > I see the same results with all optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
--- Comment #7 from mecej4 at operamail dot com ---
(In reply to Andrew Pinski from comment #3)
> Try -fwrapv .
Thanks! Using that flag with -O2 does make the program give correct results,
but I am a little confused about what that flag does and
]
|Optimizer bug exposed by|Optimizer bug with
|program with many bit |-ftree-vrp exposed by
|operations |program with many bit
||operations
--- Comment #6 from janus at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||janus at gcc dot gnu.org
Known to work||4.7.4, 4.8.5
Summary|Optimizer bug exposed by|[5/6/7 Regression]
|program with many bit |Optimizer bug exposed by
|operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
--- Comment #3 from Andrew Pinski ---
Try -fwrapv .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
--- Comment #2 from mecej4 at operamail dot com ---
(In reply to Andrew Pinski from comment #1)
> This sounds like overflows are happening. Overflow in fortran is undefined.
Very much so, but integer overflow happens a lot in random number genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
--- Comment #1 from Andrew Pinski ---
This sounds like overflows are happening. Overflow in fortran is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676
Bug ID: 78676
Summary: Optimizer bug exposed by program with many bit
operations.
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
Richard Biener changed:
What|Removed |Added
Target Milestone|5.2 |5.3
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
--- Comment #3 from Martin Jambor ---
For the record, this PR can be bisected to r218024:
Author: hubicka
Date: Mon Nov 24 16:15:46 2014 +
PR ipa/63671
* ipa-inline-transform.c (can_remove_node_now_p_1): Handle alises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
--- Comment #2 from Richard Biener ---
-fno-devirtualize fixes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66738
Bug ID: 66738
Summary: [5/6 Regression] optimizer bug related to exceptions
and static symbols
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474
Bug ID: 63474
Summary: Optimizer bug causes crash on unaligned integer writes
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
--- Comment #3 from ubizjak at gmail dot com 2009-10-17 19:28 ---
(In reply to comment #2)
> I rebuilt from latest subversion and problem no longer occurs. We can close
> this bug!
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from mckelvey at maskull dot com 2009-10-17 18:59 ---
(In reply to comment #1)
> >I'm unsure how to proceed, as temp files
> will be very large
>
> Zip them up.
>
I rebuilt from latest subversion and problem no longer occurs. We can close
this
bug!
--
http://gcc.gn
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-14 04:05 ---
>I'm unsure how to proceed, as temp files
will be very large
Zip them up.
But please attach the preprocessed source that is able to reproduce this bug.
--
pinskia at gcc dot gnu dot org changed:
Wha
~1/Owner/LOCALS~1/Temp/cchrs5yb.s:77000: Warning: end of file
not at end of a line; newline inserted
/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp/cchrs5yb.s:77764: Error: bad register
name `%'
File cchrs5yb.s no longer exists.
--
Summary: Optimizer Bug: bad register name
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:04
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 12:03:08 2009
New Revision: 148604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148604
Log:
2009-06-17 Richard Guenther
PR middle-end/40389
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-06-17 10:34
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:33:31 2009
New Revision: 148601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148601
Log:
2009-06-17 Richard Guenther
PR middle-end/40389
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-06-17 10:29
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:29:22 2009
New Revision: 148597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148597
Log:
2009-06-17 Richard Guenther
PR tree-optimizatio
--- Comment #25 from rguenther at suse dot de 2009-06-14 15:41 ---
Subject: Re: optimizer bug (possibly)
On Sun, 14 Jun 2009, jason at redhat dot com wrote:
> --- Comment #23 from jason at redhat dot com 2009-06-14 15:39 ---
> Subject: Re: optimizer bug (possibly)
&
--- Comment #24 from jason at redhat dot com 2009-06-14 15:40 ---
Subject: Re: optimizer bug (possibly)
On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote:
> (handle_rhs_call): Use it to mark the return slot escaped if
> it is addressable and N
--- Comment #23 from jason at redhat dot com 2009-06-14 15:39 ---
Subject: Re: optimizer bug (possibly)
On 06/13/2009 06:58 PM, rguenth at gcc dot gnu dot org wrote:
> * gimple.c (walk_stmt_load_store_addr_ops): The LHS of a call
> has its address taken if N
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-06-13 22:58
---
Fixed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fai
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-06-13 22:58
---
Subject: Bug 40389
Author: rguenth
Date: Sat Jun 13 22:58:13 2009
New Revision: 148462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148462
Log:
2009-06-14 Richard Guenther
PR middle-end/40389
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-06-13 19:30
---
So, if I see correctly the issue only manifests itself if we elide the copy?
The C++ FE seems to unconditionally set TREE_ADDRESSABLE on the LHS.
Stripping down the fix to only apply if TREE_ADDRESSABLE is set sti
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-06-13 17:02
---
Subject: Bug 40389
Author: rguenth
Date: Sat Jun 13 17:02:17 2009
New Revision: 148458
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148458
Log:
2009-06-13 Richard Guenther
PR tree-optimizatio
--- Comment #18 from jakub at gcc dot gnu dot org 2009-06-12 18:58 ---
Often you don't see the constructor body, but still even if the constructor
isn't defined in the current CU this address can be taken there.
Also, even if the ctor doesn't remember the address of this, IMHO because of
--- Comment #17 from jason at redhat dot com 2009-06-12 17:30 ---
Subject: Re: optimizer bug (possibly)
On 06/10/2009 05:27 PM, jakub at gcc dot gnu dot org wrote:
> Yes, as I said earlier, I think we should handle
> D.2249 = baz (); [return slot optimization]
> as taking add
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-10 21:29
---
In which case the following will fix it (provided the C++ FE sets the
TREE_ADDRESSABLE flag)
Index: gimple.c
===
--- gimple.c(revision 148325)
++
--- Comment #15 from jakub at gcc dot gnu dot org 2009-06-10 21:28 ---
Shorter testcase:
template struct S
{
V *f, *l;
__attribute__ ((noinline)) S (void) { f = 0, l = 0; }
void foo (V *x)
{
if (x->p != 0)
x->p->n = x->n;
else
f = x->n;
if (x->n != 0)
--- Comment #14 from jakub at gcc dot gnu dot org 2009-06-10 21:27 ---
The gimplifier sees:
TARGET_EXPR >>
>;
and:
arg 0
addressable ignored BLK file pr40389.C line 67 col 12 size unit size
align 64 context >
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-10 20:58
---
Well. I see as final difference (no SRA vs. with SRA)
:
D.2249 = baz (); [return slot optimization]
- D.2417_8 = D.2249.a;
- g.a = D.2417_8;
- D.2415_10 = &D.2417_8->k;
+ SR.101_9 = D.2249.a;
+ SR.102_31
--- Comment #12 from jason at gcc dot gnu dot org 2009-06-10 20:58 ---
Incidentally, the testcase can be simplified by removing the body of the copy
constructor, i.e. reducing it to just the declaration
H (const H &h);
since it isn't actually called.
--
http://gcc.gnu.org/bugzil
--- Comment #11 from jason at gcc dot gnu dot org 2009-06-10 20:12 ---
I don't think it's possible to reproduce this in C because C doesn't have
constructors, so it's obvious when the address is taken. Here's what's
happening:
baz uses new to allocate an A with f=0,l=0, call it A'
baz
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-10 19:47
---
Can we have a less convoluted C-only testcase? I still don't see what is
going on ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
--- Comment #9 from jason at gcc dot gnu dot org 2009-06-10 19:40 ---
Actually, I'm not sure I'm the right person to work on this bug, as we might
want this analysis to happen more in the optimizer. That is, we see that
"this" escapes in one of the H constructors, so all H must be treat
--- Comment #8 from jason at gcc dot gnu dot org 2009-06-10 19:37 ---
As Jakub says, it's not a problem to take the address of a local variable as
long as that address is only used during the variable's lifetime; the
destructor for the temporary removes all references to its address, so
--- Comment #7 from jakub at gcc dot gnu dot org 2009-06-09 21:44 ---
CCing Jason on the validity of the testcase.
I don't see anything wrong with remembering this pointer for the duration of
the object, assuming the pointer is gone from the list in the destructor
(that's what the testca
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-09 21:31 ---
I think this code is undefined as there is an address of a local variable being
taken and stored (explicitly when doing:
__attribute__ ((noinline)) H (A *b) : a (b)
{
p = 0;
n = 0;
if (a != 0)
a
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-09 21:27 ---
I don't see why this is an issue at all - in fact the address does not
escape(?)
but instead the assignment is inside the callee. So
:
D.2275 = baz (); [return slot optimization]
SR.101_9 = D.2275.a;
SR.102_1
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-09 21:21 ---
IMHO either we need to handle gimple_call_return_slot_opt_p cals in the
middle-end as taking address of the call's lhs, or the frontend needs to expand
it not as
D.2275 = baz (); [return slot optimization]
but as
baz (
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-09 20:25 ---
Hm, I don't see how it should make the decl addressable. But I also don't
see what is wrong with what esra performs on trunk ...
I guess you refer to
@@ -1193,45 +374,45 @@
S::bar (D.2441_15, &g);
:
- D.2453
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-09 17:11 ---
Confirmed. Shorter testcase:
template struct S
{
V *f, *l;
__attribute__ ((noinline)) S (void) { f = 0, l = 0; }
void foo (V *x)
{
if (x->p != 0)
x->p->n = x->n;
else
f = x->n;
if (x->
--- Comment #1 from keesjan at cobalt dot et dot tudelft dot nl 2009-06-09
15:49 ---
Created an attachment (id=17971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17971&action=view)
The source code and compiler output, and a small script which reproduces the
bug.
Please see the
case.
--
Summary: optimizer bug (possibly)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: keesjan at co
Here is a 16 line program that works fine without the optimizer,
but prints the word "bug" with gcc -O
No other flags, no headers included.
Linux fedora 9.
gcc -v is:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-04-26 16:50
---
Subject: Bug 30567
Author: rguenth
Date: Thu Apr 26 16:50:32 2007
New Revision: 124191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124191
Log:
2007-04-26 Richard Guenther <[EMAIL PROTECTED]>
D
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-04-26 12:16
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #35 from rguenth at gcc dot gnu dot org 2007-04-26 12:15
---
Subject: Bug 30567
Author: rguenth
Date: Thu Apr 26 12:15:16 2007
New Revision: 124184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124184
Log:
2007-04-26 Richard Guenther <[EMAIL PROTECTED]>
D
--- Comment #34 from rguenth at gcc dot gnu dot org 2007-04-26 10:02
---
I'll bootstrap & regtest that thing and commit it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from dberlin at gcc dot gnu dot org 2007-04-25 19:45
---
I think richi said on IRC that the following backport from 4.3 will fix it (if
so, it's the correct fix here)
Index: tree-ssa-structalias.c
===
--- t
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-04-25 17:13
---
No idea. The only place I found was setup_pointers_and_addressables, but that
hits the path only if
/* Add pointer variables that have been dereferenced to the POINTERS
array and create a symbol me
--- Comment #31 from dberlin at gcc dot gnu dot org 2007-04-25 17:01
---
Subject: Re: [4.2 Regression] -O3 optimizer bug
On 25 Apr 2007 15:32:41 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #29 from rguenth at gcc dot gnu dot
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-04-25 16:42
---
Created an attachment (id=13441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13441&action=view)
a patch I like more
this one attached, bootstrap/testing in progress.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-04-25 16:32
---
Oh, btw. why the may_aliases bitmap for SMT.11 is empty on entry to the loops
computing the transitive closure (it tries to, right?) is that SFT.0 is not
considered stored to in the first nested loop over pointers
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-04-25 15:04
---
Created an attachment (id=13439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13439&action=view)
prototype patch
I'm testing this one. It'll make aliasing slower and more conservative, so I
bet it's not th
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-04-25 14:42
---
The workaround doesn't work. I'll test the patch in comment #26, otherwise
I'm out of ideas and clue on how it should work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-04-25 14:22
---
We fail to add the SFTs to the may_alias set of SMT.11, so add_virtual_operand
sees NULL may_aliases and doesn't add SFTs as clobbered.
I believe compute_flow_insensitive_aliasing is the culprit here as one can
ea
--- Comment #25 from dberlin at gcc dot gnu dot org 2007-04-25 03:14
---
(In reply to comment #23)
> This is a regression. Danny?
>
It actually should get assigned anything as a points-to set, so the "bad"
constraints are correct.
We should also always get correct aliasing even if e
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-04-21 18:38
---
Actually the handle_ptr_arith change made a difference as we (luckily?)
for D.2147_17 = D.2144_14 + D.2146_16
D.2144_14 = a_11->begin;
D.2145_15 = i_1 * 4;
D.2146_16 = (const int *) D.2145_15;
D.2147_17 =
CC||rguenth at gcc dot gnu dot
||org
Known to work||4.1.3 4.3.0
Summary|-O3 optimizer bug |[4.2 Regression] -O3
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-04-18 22:56
---
And this is the bug:
# SFT.0_29 = V_MAY_DEF ;
# SFT.1_30 = V_MAY_DEF ;
this_7->elems[0] = 1;
the following is supposed to read it.
# VUSE ;
D.2148_18 = *D.2147_17;
it's interesting that
Points-
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 22:47
---
Code in comment #19 is perfectly correct. I can reproduce the difference with
the attached testcase and -O -fstrict-aliasing -finline-functions.
-fno-strict-aliasing fixes it.
--
http://gcc.gnu.org/bugzilla/
|Added
CC||mark at codesourcery dot com
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Summary|-fPIC -O3 optimiz
1 - 100 of 147 matches
Mail list logo
