[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
--- Comment #10 from jamborm at gcc dot gnu dot org 2008-12-02 14:32 --- Subject: Bug 37861 Author: jamborm Date: Tue Dec 2 14:30:55 2008 New Revision: 142355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142355 Log: 2008-12-02 Martin Jambor <[EMAIL PROTECTED]> PR middle-end/37861 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check for INDIRECT_REFs. (forward_propagate_addr_into_variable_array_index): Check that the offset is not computed from a MULT_EXPR, use is_gimple_assign rather than the gimple code directly. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/38371] New: Fold check error during bootstrap
When I try to bootstrap gcc trunk configured with
configure --prefix=some_path --enable-checking=yes,fold
--enable-languages=c,c++
I get a fold check error: original tree changed by fold when compiling
libdecnumber/bid/host-ieee32.c.
The exact compile command line leading to this error (in the
libdecnumber subdirectory of the build directory) is:
source='/home/mjambor/svn/libdecnumber/bid/host-ieee32.c'
object='host-ieee32.o' libtool=no /home/mjambor/svn/obj/./prev-gcc/xgcc
-B/home/mjambor/svn/obj/./prev-gcc/
-B/home/mjambor/inst/svn//x86_64-unknown-linux-gnu/bin/
-I/home/mjambor/svn/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror
-I/home/mjambor/svn/libdecnumber -I. -c
/home/mjambor/svn/libdecnumber/bid/host-ieee32.c
The error output is:
/home/mjambor/svn/libdecnumber/bid/host-ieee32.c: In function
'__host_to_ieee_32':
/home/mjambor/svn/libdecnumber/bid/host-ieee32.c:50: internal compiler error:
fold check: original tree changed by fold
I will attach preprocessed source.
--
Summary: Fold check error during bootstrap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38371
[Bug middle-end/38371] Fold check error during bootstrap
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-12-02 10:27 --- Created an attachment (id=16808) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16808&action=view) Preprocessed source Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38371
[Bug tree-optimization/38645] [4.4 Regression] ICE with volatile
--- Comment #2 from jamborm at gcc dot gnu dot org 2008-12-30 13:08 --- Apparently, the problem is that when some expression arithmetics is folded to D.1241_18 = a[0], the statement volatile flag is not set which triggers the assert. The following simple patch makes the ICE go away, I'll test it and prepare a proper patch with a test case if I get an ACK from a gimple/middle-end maintainer. 2008-12-30 Martin Jambor * gimple.c (gimple_assign_set_rhs_from_tree): Set volatile statement flag if necessary. Index: gcc/gimple.c === --- gcc/gimple.c(revision 142962) +++ gcc/gimple.c(working copy) @@ -1985,6 +1985,10 @@ gimple_assign_set_rhs_from_tree (gimple_ extract_ops_from_tree (expr, &subcode, &op1, &op2); gimple_assign_set_rhs_with_ops (gsi, subcode, op1, op2); + + if (TREE_SIDE_EFFECTS (op1) || TREE_THIS_VOLATILE (op1) + || (op2 && (TREE_SIDE_EFFECTS (op2) || TREE_THIS_VOLATILE (op2 +gimple_set_has_volatile_ops (gsi_stmt (*gsi), true); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38645
[Bug tree-optimization/38645] [4.4 Regression] ICE with volatile
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-12-30 16:58 ---
I discussed this bug with Richi on IRC and was told that we should
avoid having the statement marked as volatile since it is not an
access through a volatile variable in the original source code.
Instead, we should try preventing the propagation of &a to uses of p.
The patch is below, it prevents ccp and dom1 from carrying out the
propagation. However, fwprop does this propagation, albeit using a
VIEW_CONVERT_EXP and, moreover, fold_stmt_inplace() it calls marks the
statement volatile anyway. This propagation is performed because
fwprop checks types (not decls) for volatility and apparently the type
of a is not volatile (as opposed to a[0] which probably is).
The declaration of a is volatile though. However, when I changed it
to check the declaration, nrv pass did the propagation, creating
invalid gimple along the way. Because the such change would possibly
be incorrect it is not included below. Anyway, the test case with
this patch compiles ans it is possibly slightly more correct, though
the final result is not all that different.
2008-12-30 Martin Jambor
* tree-ssa-dom.c (cprop_operand): Always check the return value of
may_propagate_copy.
* tree-ssa-copy.c (may_propagate_copy): Do not allow propagation
of addresses of volatile declarations.
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c (revision 142962)
+++ gcc/tree-ssa-dom.c (working copy)
@@ -2092,7 +2092,7 @@ cprop_operand (gimple stmt, use_operand_
/* Certain operands are not allowed to be copy propagated due
to their interaction with exception handling and some GCC
extensions. */
- else if (!may_propagate_copy (op, val))
+ if (!may_propagate_copy (op, val))
return false;
/* Do not propagate copies if the propagated value is at a deeper loop
Index: gcc/tree-ssa-copy.c
===
--- gcc/tree-ssa-copy.c (revision 142962)
+++ gcc/tree-ssa-copy.c (working copy)
@@ -73,6 +73,15 @@ may_propagate_copy (tree dest, tree orig
&& SSA_NAME_OCCURS_IN_ABNORMAL_PHI (dest))
return false;
+ if (TREE_CODE (orig) == ADDR_EXPR)
+ {
+tree base = TREE_OPERAND (orig, 0);
+while (handled_component_p (base))
+ base = TREE_OPERAND (base, 0);
+if (TREE_THIS_VOLATILE (base))
+ return false;
+ }
+
/* For memory partitions, copies are OK as long as the memory symbol
belongs to the partition. */
if (TREE_CODE (dest) == SSA_NAME
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38645
[Bug tree-optimization/38645] [4.4 Regression] ICE with volatile
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-27 23:33:29 |2008-12-30 17:01:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38645
[Bug tree-optimization/40081] verify_stmts failed with -O2
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-05-10 10:29 --- New SRA handles this fine by not scalarizing anything that has volatile fields in it. There is already a fortran testcase with a union with a volatile field that made me aware of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40081
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-05-21 16:02 ---
With he new SRA, the optimized dump looks like:
D.6886_10 = {1, 1, 1, 1};
D.6887_11 = VIEW_CONVERT_EXPR(D.6886_10);
D.6893_12 = VIEW_CONVERT_EXPR(D.6887_11);
D.6891_14 = __builtin_ia32_pcmpeqd128 (D.6893_12, D.6893_12);
D.6890_15 = VIEW_CONVERT_EXPR(D.6891_14);
D.6897_16 = VIEW_CONVERT_EXPR(D.6890_15);
D.6896_17 = __builtin_ia32_pmovmskb128 (D.6897_16);
D.6933_21 = D.6896_17 != 65535;
return D.6933_21;
x is completely gone.
The (relevant) assembly output is
main:
movdqa .LC0, %xmm0
pcmpeqd %xmm0, %xmm0
pmovmskb%xmm0, %eax
cmpl$65535, %eax
pushl %ebp
setne %al
movl%esp, %ebp
movzbl %al, %eax
popl%ebp
ret
So even though I don't really understand the SSE instructions I
believe the new SRA does indeed help. I'll add a testcase checking
that x vanishes to the patch series as I am finalizing the final patch
set now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-05-25 15:20 --- ...hm, when I wanted to make such a testcase I realized that the SSE code is not very portable. So I changed my mind and won't use it. I'll be adding different union scalarization checks, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug tree-optimization/40323] [4.5 Regression] compiling just takes forever and doesn't really process
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-02 10:51 --- Apparently I was not careful enough when turning an if branch to a while loop. I'll prepare and test a patch straight away. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-02 10:45:24 |2009-06-02 10:51:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug tree-optimization/40323] [4.5 Regression] compiling just takes forever and doesn't really process
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-02 17:06 --- Created an attachment (id=17946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17946&action=view) Fix Ok, creating a simple testcase was not easy for me but here is a patch that includes one (and fixes the original issue too). It still needs testing but I am quite confident it will pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug tree-optimization/40323] [4.5 Regression] compiling just takes forever and doesn't really process
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-03 11:56 --- Subject: Bug 40323 Author: jamborm Date: Wed Jun 3 11:56:05 2009 New Revision: 148126 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148126 Log: 2009-06-03 Martin Jambor PR tree-optimization/40323 * ipa-prop.c (get_ssa_def_if_simple_copy): Break if not single assignment. * testsuite/g++.dg/torture/pr40323.C: New file. Added: trunk/gcc/testsuite/g++.dg/torture/pr40323.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug tree-optimization/40323] [4.5 Regression] compiling just takes forever and doesn't really process
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-03 12:54 --- I have just verified this is fixed on the current trunk. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-05 11:49 --- Mine. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-05 11:40:57 |2009-06-05 11:49:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-05 15:48 --- Created an attachment (id=17955) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17955&action=view) Fix This patch fixes this problem. I'll post it to the mailing list once I get to bootstrap it which may take a while now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-07 14:41 --- (In reply to comment #11) > It is caused by revision 147980: > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html > Revision 147978 also does not work if you compile the testcase with the -fno-tree-sra switch. New SRA uncovers this problem because it sees the structure containing only a single field always accessed as a structure and never as a scalar and so does not scalarize it. Something goes wrong later on, probably when expanding to RTL. Unfortunately, I cannot help fixing that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug c/40378] ICE starting with revision 147980
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-08 13:27 --- This is obviously mine. Will look into it shortly. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-08 13:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-06-08 17:49 --- (In reply to comment #16) > Wait, (In reply to comment #15) > > (In reply to comment #11) > > > It is caused by revision 147980: > > > > > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html > > > > > > > Revision 147978 also does not work if you compile the testcase with > > the -fno-tree-sra switch. > > > > New SRA uncovers this problem because it sees the structure containing > > only a single field always accessed as a structure and never as a > > scalar and so does not scalarize it. Something goes wrong later on, > > probably when expanding to RTL. Unfortunately, I cannot help fixing > > that. > > I think that should always scalarize as it is a single field as it is always > better to scalarize single field structs (except maybe bitfield ones). Well, Richi seems to disagree: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00637.html I am not sure myself, I believe that there are not so many cases in which this would prove beneficial. When there are no operations performed on the scalars, the only situation I can think of would be some extensive copy propagation. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-09 16:53 --- Subject: Bug 40351 Author: jamborm Date: Tue Jun 9 16:52:57 2009 New Revision: 148315 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148315 Log: 2009-06-09 Martin Jambor PR tree-optimization/40351 * tree-sra.c (propagate_subacesses_accross_link): Check that a refrence to a potential artifical subaccess can be constructed. * testsuite/gcc.c-torture/compile/pr40351.c: New file. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40351.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-09 20:59 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-14 01:30 --- Mine, will look into it shortly. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-12 05:20:52 |2009-06-14 01:30:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #94 from jamborm at gcc dot gnu dot org 2009-06-14 04:43 --- (In reply to comment #92) > In the meanwhile something caused "tree incremental SSA" to jump up from 10s > to > 26s. Sob. > (In reply to comment #93) > I would say that was the new SRA. > OK, I'll try to investigate. Which of the various attachments to this bug is the one to look at? Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-14 04:55 --- (In reply to comment #1) > I want to say the SRA changes caused this ... > Yes it did. I can reproduce it and it should not be difficult to fix. However, I'll have a look at why SRA constructs such a statement in the first place. The code that does it currently things it's either appending ".eh" to the LHS or the VCE to the RHS, not both. But maybe it's just an oversight, I'll check in the morning. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-14 04:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-15 09:07 --- Created an attachment (id=18001) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18001&action=view) Fix This was quite a serious oversight on my part, I wonder how it went for so long unnoticed. I am about to bootstrap and regression test this patch and will submit it if both succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-15 09:09 --- Created an attachment (id=18002) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18002&action=view) Fix OK, the statement is fine except that it is not gimple ;-). Fixed with this patch, I will submit it if it passes bootstrap and testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-06-16 09:54 --- Bootstrap and testing passed, submitted in http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01179.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-16 09:57 --- Bootstrapped, tested, submitted in http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01182.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-06-16 10:12 --- Subject: Bug 40413 Author: jamborm Date: Tue Jun 16 10:11:55 2009 New Revision: 148520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148520 Log: 2009-06-16 Martin Jambor PR tree-optimization/40413 * tree-sra.c (load_assign_lhs_subreplacements): Pass offset to build_ref_for_offset. (propagate_subacesses_accross_link): Fix a typo in a comment. * testsuite/gfortran.fortran-torture/compile/pr40413.f90: New file. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr40413.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-16 10:16 --- Subject: Bug 40432 Author: jamborm Date: Tue Jun 16 10:16:40 2009 New Revision: 148522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148522 Log: 2009-06-16 Martin Jambor PR tree-optimization/40432 * tree-sra.c (sra_modify_assign): When creating VIEW_CONVERT_EXPR, check whether we need to force gimple register operand. * testsuite/gcc.c-torture/compile/pr40432.c: New file. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40432.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug tree-optimization/40432] [4.5 Regression] verify_stmts failed with -O2: non-register as LHS of unary operation
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-16 10:24 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40432
[Bug tree-optimization/40413] [4.5 Regression] Internal error in connection with optimization and allocatable objects
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-06-16 10:24 --- Fixed -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40413
[Bug c++/40492] [4.5 Regression] ice in create_tmp_var
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-19 13:14 --- (In reply to comment #2) > Confirmed. Caused by new SRA - we are creating a temporary with > TREE_ADDRESSABLE > type. > Again? Well, let me see where... -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-19 12:37:49 |2009-06-19 13:14:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40492
[Bug c++/40492] [4.5 Regression] ice in create_tmp_var
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-19 17:27 --- Created an attachment (id=18025) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18025&action=view) Fix The offset we pass to build_ref_for_offset in sra_modify_assign does not make any sense. I am about to bootstrap and test the attached patch which fixes this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40492
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-06-19 18:09 --- I will look into this next week. However, I have never compiled binutils before, so unless it is obvious, please describe how to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug c++/40492] [4.5 Regression] ice in create_tmp_var
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-22 10:54 --- Subject: Bug 40492 Author: jamborm Date: Mon Jun 22 10:54:16 2009 New Revision: 148787 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148787 Log: 2009-06-22 Martin Jambor PR tree-optimization/40492 * tree-sra.c (sra_modify_assign): Pass zero offsets to build_ref_for_offset. * testsuite/g++.dg/torture/pr40492.C: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40492
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-22 18:57 --- Right, now I can reproduce the problem and it indeed is introduced by the new SRA commit. None of the fixes I have done so far deals with this one either. I am investigating this further (but don't hold your breath, it is going to take me a while). -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-22 18:57:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-06-23 13:21 --- The miscompiled file seems to be gas/tc-i386.o. Early SRA is enough to trigger the problem. Digging deeper... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug c++/40492] [4.5 Regression] ice in create_tmp_var
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-23 14:12 --- Fixed -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40492
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-06-23 16:45
---
Reduced testcase:
extern void abort (void);
typedef union i386_operand_type
{
struct
{
unsigned int reg8:1;
unsigned int reg16:1;
unsigned int reg32:1;
unsigned int reg64:1;
unsigned int floatreg:1;
unsigned int regmmx:1;
unsigned int regxmm:1;
unsigned int regymm:1;
unsigned int control:1;
unsigned int debug:1;
unsigned int test:1;
unsigned int sreg2:1;
unsigned int sreg3:1;
unsigned int imm1:1;
unsigned int imm8:1;
unsigned int imm8s:1;
unsigned int imm16:1;
unsigned int imm32:1;
unsigned int imm32s:1;
unsigned int imm64:1;
unsigned int disp8:1;
unsigned int disp16:1;
unsigned int disp32:1;
unsigned int disp32s:1;
unsigned int disp64:1;
unsigned int acc:1;
unsigned int floatacc:1;
unsigned int baseindex:1;
unsigned int inoutportreg:1;
unsigned int shiftcount:1;
unsigned int jumpabsolute:1;
unsigned int esseg:1;
unsigned int regmem:1;
unsigned int mem:1;
unsigned int byte:1;
unsigned int word:1;
unsigned int dword:1;
unsigned int fword:1;
unsigned int qword:1;
unsigned int tbyte:1;
unsigned int xmmword:1;
unsigned int ymmword:1;
unsigned int unspecified:1;
unsigned int anysize:1;
} bitfield;
unsigned int array[2];
} i386_operand_type;
unsigned int x00, x01, y00, y01;
int main (int argc, char *argv[])
{
i386_operand_type a,b,c,d;
a.bitfield.reg16 = 1;
a.bitfield.imm16 = 0;
a.array[1] = 22;
b = a;
x00 = b.array[0];
x01 = b.array[1];
c = b;
y00 = c.array[0];
y01 = c.array[1];
d = c;
if (d.bitfield.reg16 != 1)
abort();
if (d.bitfield.imm16 != 0)
abort();
if (d.array[1] != 22)
abort();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-06-24 16:38 --- Fix submitted to the mailing list, pending maintainer approval: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01918.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #14 from jamborm at gcc dot gnu dot org 2009-06-25 10:38 --- Subject: Bug 40493 Author: jamborm Date: Thu Jun 25 10:38:13 2009 New Revision: 148941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148941 Log: 2009-06-25 Martin Jambor PR tree-optimization/40493 * tree-sra.c (sra_modify_expr): Correct BIT_FIELD_REF argument numbers. (enum unscalarized_data_handling): New type. (handle_unscalarized_data_in_subtree): Return what has been done. (load_assign_lhs_subreplacements): Handle left flushes differently. (sra_modify_assign): Use unscalarized_data_handling, simplified condition determining whether to remove the statement. * testsuite/gcc.c-torture/execute/pr40493.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr40493.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-25 14:21 --- I have checked out trunk 148941, compiled binutils with it (configured with --disable-werror), ran the testsuite and there were no failures. Thus I consider this fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug tree-optimization/40556] [4.5 Regression] ICE in IPA-CP with recursion
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-06-26 13:53 --- This is some sort of cgraph consistency check. Honza added it and he also said he will look into this :-) -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-06-26 14:59 --- OK, I have finally managed to reproduce this and the patch does indeed result into a segfault. I will keep looking into this, even though probably won't be able to do much until Monday. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot | |org AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-26 14:59:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-06-26 15:08 --- The miscompiled file seems to be derivative_approximation.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-27 23:41 ---
I believe the following (but yet untested) patch fixes this issue.
I will bootstrap and test it once I have a testcase that is simple
enough to be put into the testsuite. I hope to do all of this on
Monday.
Index: mine/gcc/tree-sra.c
===
--- mine.orig/gcc/tree-sra.c2009-06-28 00:58:23.0 +0200
+++ mine/gcc/tree-sra.c 2009-06-28 01:00:34.0 +0200
@@ -1908,7 +1908,8 @@ sra_modify_expr (tree *expr, gimple_stmt
&& host_integerp (TREE_OPERAND (bfr, 2), 1))
{
chunk_size = tree_low_cst (TREE_OPERAND (bfr, 1), 1);
- start_offset = tree_low_cst (TREE_OPERAND (bfr, 2), 1);
+ start_offset = access->offset
+ + tree_low_cst (TREE_OPERAND (bfr, 2), 1);
}
else
start_offset = chunk_size = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-29 11:16 --- OK, I'll have a look at it after I am done with PR 40554. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-29 11:10:17 |2009-06-29 11:16:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-29 11:22 --- I'm quite confident this is a cgraph bug => CCing honza. (I'll try to keep this on my radar but there are other issues for which I am certainly responsible now). -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-29 17:11 --- Created an attachment (id=18094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18094&action=view) Fix It turns out that build_ref_for_offset apparently needs to check for full type compatibility and node just for useless_conversions. It is used more generally but also in much stricter same-type conditions than I have originally intended to. I will test this fix (alongside with another one) overnight and submit it tomorrow if everything goes fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-30 09:34 --- http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02214.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 09:35 --- http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02215.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-30 10:03 --- Subject: Bug 40554 Author: jamborm Date: Tue Jun 30 10:03:26 2009 New Revision: 149087 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149087 Log: 2009-06-30 Martin Jambor PR middle-end/40554 * tree-sra.c (sra_modify_expr): Add access->offset to start_offset. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-30 10:10 --- Subject: Bug 40582 Author: jamborm Date: Tue Jun 30 10:10:29 2009 New Revision: 149088 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149088 Log: 2009-06-30 Martin Jambor PR tree-optimization/40582 * tree-sra.c (build_ref_for_offset_1): Use types_compatible_p rather than useless_type_conversion_p. (generate_subtree_copies): Increment sra_stats.subtree_copies at a proper place. * testsuite/gcc.c-torture/compile/pr40582.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40582.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-30 11:39 --- As you may have noticed, I changed the testcase a little bit so that it ICEs as my i386 desktop too. A freshly checked out trunk no longer does. So I believe this is indeed fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 11:44 --- When compiled with a freshly checked-out trunk the testcase no longer segfaults and gives exactly the same output as if compiled with trunk revision 147978 (i.e. just before my new SRA got in). So I consider this fixed and hope that various automated testers will agree. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32 --- OK, I have now added this to my todo list. The simple tweaks would be simple. On the other hand, if DCE is clever, it still might figure out a structure is dead at some code paths while I don't even attempt to and still remove some statements. > only loads from a structure or only stores to a structure > probably should be simply skipped. I've been thinking about not scalarizing accesses that occur only once too. Thinking about it more, I wonder whether requiring at least one load and a store or at least two loads is a good idea. (Load and store for the case where we store something to an aggregate first and then load it and two loads for the case when we can finally get away with one.) I'll try to come up with something this simple quickly and hopefully we can benchmark it over the weekend or so... -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot | |org AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-14 16:32:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-28 13:28 --- Honza, unless there are any new problems, can you commit the patch? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-28 20:14 --- When I move "e->inline_failed = CIF_OK" in cgraph_mark_inline_edge() until after call to cgraph_clone_inlined_nodes(), the endless recursion goes away. However, I now get an assert in cgraph_estimate_size_after_inlining because the calculated size overflows... thus I'm looking at where the sizes grow so grossly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 ---
Ha, please disregard the previous message, obviously I had to make a
fool out of myself before realizing that loops in the inlining plan
are the bug, not how we handle them.
The reason there are such loops is that ipa-cp has made a portion of
the graph effectively dead but strongly connected via single uses
which ipa-inline handles specially and wants to inline them whenever
it seems possible. But it sis not check for loops.
So, I belive the patch below fixes this issue and I am going to
bootstrap it overnight. Honza, can you please confirm this is indeed
a correct fix? Thanks.
2009-07-28 Martin Jambor
* ipa-inline.c (cgraph_decide_inlining): Watch out for dead single
use inlining loops.
* testsuite/gcc.c-torture/compile/pr40570.c: New test.
Index: icln/gcc/ipa-inline.c
===
--- icln.orig/gcc/ipa-inline.c
+++ icln/gcc/ipa-inline.c
@@ -1227,6 +1227,7 @@ cgraph_decide_inlining (void)
&& !node->needed
&& node->local.inlinable
&& node->callers->inline_failed
+ && node->callers->caller->global.inlined_to != node
&& !gimple_call_cannot_inline_p (node->callers->call_stmt)
&& !DECL_EXTERNAL (node->decl)
&& !DECL_COMDAT (node->decl))
Index: icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
===
--- /dev/null
+++ icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
@@ -0,0 +1,19 @@
+static int foo(int i);
+
+static int bar(int i) { foo(i); }
+
+static int foo(int i)
+{
+ int j;
+ if (j)
+FOO(j);
+ return bar(i);
+}
+
+int baz()
+{
+ foo(0);
+ if (baz())
+return 1;
+ return 0;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 --- I can confirm that if we schedule pass_ccp right after pass_sra_early, g gets inlined. Moreover, if we schedule one more pass_forwprop right afterwards, even the testcase for PR 3713, comment #12 gets optimized as it should :-) So, like with PR 3713, we either have to schedule ccp or add some specific pattern matching to the inlining preparation phase. I guess that people will find running one more ccp and fwprop unacceptable and so some pattern matching will have to be done anyway for the other PR (and we already do some awkward stuff like that for indirect member pointer calls). Perhaps we can match both, this one would be very easy. (Or is scheduling the two extra passes an option?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-07-29 09:27 --- Can you please try this with -fno-tree-sra? If you have a revision earlier than 147980 (new SRA) at hand, can you try that with -fno-tree-sra? Thanks. I'll try to reproduce this on gcc61 at the compile farm but it's gonna take time to build (and I will be only able to help you if the bug is indeed caused by SRA - there have been already cases where the old SRA merely hid some bugs elsewhere). -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-07-29 09:51 --- (In reply to comment #8) > > --- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 > > --- > > So, I belive the patch below fixes this issue and I am going to > > bootstrap it overnight. Honza, can you please confirm this is indeed > > a correct fix? Thanks. > > > + && node->callers->caller->global.inlined_to != node > > That only detects direct loops, does it? I don't understand. This loop consisted of nodes that are going to be inlined, they have only one caller and the incoming edge is marked for inlining. There cannot be any indirect calls or complex cycles or anything. In fact, looking at the inlined edges, the inlined nodes should only form a tree. > IMHO ipa-inline should have computed callgraph SCCs anyway for a > long time now ... we just seem to keep accumulating interesting > workarounds for cycles ;) Well, I don't see how this would help, at least in this particular case. There are cycles in the call graph, we just must not create cycles consisting of edges with inline_failed == NULL. I do not think that explicit tests like this are somehow bad, we would have to test the property one way or another. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-29 10:16 --- (In reply to comment #12) > ... at least scheduling FRE is still on the list of possible things > todo (can you check if that fixes 3713 as well?) > No, it doesn't (unlike the testcase above, for which FRE is enough). We have to remove the if-statement in (foo is a function): p$__pfn_25 = foo; D.1739_3 = (int) p$__pfn_25; D.1740_4 = D.1739_3 & 1; if (D.1740_4 != 0) goto ; else goto ; Not even FRE combined with a subsequent fwprop (in their current form) can make this happen :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-07-29 10:33 --- Bootstrap and testing finished fine, I submitted the patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01642.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-07-29 13:40
---
(In reply to comment #8)
> That only detects direct loops, does it?
Actually, now I may understand but no, it is exactly the other way
round. The patch above only detects indirect loops, when there are at
least two nodes involved. But that is not necessarily true, as I have
just discovered the hard way when testing my ipa-cp stuff... The
updated patch which I am going to test now therefore is:
2009-07-30 Martin Jambor
* ipa-inline.c (cgraph_decide_inlining): Watch out for dead single
use inlining loops.
* testsuite/gcc.c-torture/compile/pr40570.c: New test.
Index: icln/gcc/ipa-inline.c
===
--- icln.orig/gcc/ipa-inline.c
+++ icln/gcc/ipa-inline.c
@@ -1227,6 +1227,8 @@ cgraph_decide_inlining (void)
&& !node->needed
&& node->local.inlinable
&& node->callers->inline_failed
+ && node->callers->caller != node
+ && node->callers->caller->global.inlined_to != node
&& !gimple_call_cannot_inline_p (node->callers->call_stmt)
&& !DECL_EXTERNAL (node->decl)
&& !DECL_COMDAT (node->decl))
Index: icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
===
--- /dev/null
+++ icln/gcc/testsuite/gcc.c-torture/compile/pr40570.c
@@ -0,0 +1,19 @@
+static int foo(int i);
+
+static int bar(int i) { foo(i); }
+
+static int foo(int i)
+{
+ int j;
+ if (j)
+FOO(j);
+ return bar(i);
+}
+
+int baz()
+{
+ foo(0);
+ if (baz())
+return 1;
+ return 0;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18 --- Richi, not scalarizing things like the second foo() in the original bug description will inevitably lead to warning failures in g++.dg/warn/unit-1.C and gcc.dg/uninit-I.c. Is that OK? Should I remove or XFAIl them? (Structure copy-prop is being checked on gcc.dg/tree-ssa/sra-6, so that is safe.) Hopefully I will attach a patch here soon. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-07-30 16:26 --- Subject: Bug 40570 Author: jamborm Date: Thu Jul 30 16:26:09 2009 New Revision: 150263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150263 Log: 2009-07-30 Martin Jambor PR tree-optimization/40570 * ipa-inline.c (cgraph_decide_inlining): Watch out for dead single use inlining loops. * testsuite/gcc.c-torture/compile/pr40570.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40570.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-30 16:43 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-30 17:07 --- Created an attachment (id=18273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18273&action=view) Proposed patch The attached patch does turn SRA down a bit. Specifically, in order to create a replacement, the corresponding access (group) must either: - be read individually multiple times or - be read individually and also written to (either individually or through its parent) or - somehow accessed individually and be on the RHS of structure copy-prop link or - be read individually and be on the LHS of structure copy-prop link. (The bottom line is to avoid scalarizing accesses with only stores or just one read - and no stores. Another thing to be noted is that with this patch we also insist the access must be at least once read individually, not as a part of its parent to be scalarized.) I'm bootstrapping and testing this at the moment but only to find out that the testcase changes are OK, the last bootstrap with exactly these changes to tree-sra.c finished fine. I want to have benchmarks run on this, however, to make sure I do not do any harm. I expect to be benchmarking ipa-cp cloning the next couple of days and do this right afterwards, I guess early next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-30 17:10 --- Created an attachment (id=18274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18274&action=view) Proposed patch Well, apparently I forgot to run quilt refresh, this is the current patch with the testcase changes. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Attachment #18273|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-08-04 16:54 --- Right. The number in identifiers I see are different, of course, but what happens is this. Early SRA replaces structure b.3 with SR.4_25. In BB2, it is assigned into from parameter b: SR.4_25 = b._M_value; This assignment survives until complex lowering which expands it into: SR.4$real_7 = REALPART_EXPR ; SR.4$imag_1 = IMAGPART_EXPR ; SR.4_25 = COMPLEX_EXPR ; Note that the b.3 is back, although it should have died long time ago and that leads to the varasm ICE. What is even more weird however, is how tree-complex.c comes upon that variable. In extract_component() it correctly builds rhs REALPART_EXPR but then it feeds it into force_gimple_operand_gsi() which in turns inserts the bogus statements into the stream. So that is where to look now, I suppose. I wonder how come the behavior is target specific, though. Well, let me see. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-04 16:54:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-08-05 20:51 --- The long-dead declaration is brought back to life by the following line in gimplify_var_or_parm_decl() in gimplify.c: tree value_expr = DECL_VALUE_EXPR (decl); I don't know why that happens yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug middle-end/32964] [4.3/4.4/4.5 Regression] union cause inefficient code inside loops
--- Comment #16 from jamborm at gcc dot gnu dot org 2009-08-06 11:55 --- Subject: Bug 32964 Author: jamborm Date: Thu Aug 6 11:55:30 2009 New Revision: 150523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150523 Log: 2009-08-06 Martin Jambor PR middle-end/32964 * testsuite/gcc.dg/tree-ssa/pr32964.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32964.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug middle-end/32964] [4.3/4.4 Regression] union cause inefficient code inside loops
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-08-06 12:09
---
New SRA scalarizes the unions in this testcase and so this is no
longer a 4.5 regression. I have committed a testcase for reference
and am updating relevant bugzilla tags/summary now.
As I won't be backporting new SRA to any of the regressing versions, I
am no longer really interested in this bug and will remove myself from
the CC list too. Feel free to re-add me if anything I should know
about arises.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
CC|mjambor at suse dot cz, |
|jamborm at gcc dot gnu dot |
|org |
Known to work|4.2.2 |4.2.2 4.5.0
Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] union
|union cause inefficient code|cause inefficient code
|inside loops|inside loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-08-06 12:22 --- Note to self: PR 40874 is related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-08-06 17:31 --- Created an attachment (id=18311) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18311&action=view) workaround patch I still believe that the gimplifier should not do this substitution this late in the compilation. However, since I do not have time nor am I brave enough to attempt to fix it there, I at least tried to make sure that SRA does not create situations which lead to this error and the attached patch is the result of that effort. I am currently bootstrapping it on an x86_64. However, it should be noted that it comes at a slight cost, both in run time as this leads to less structure copy propagation (and at least java uses DECL_VALUE_EXPR even on x86_64, I believe) and compile time, as we have to check for it everywhere. Moreover, every single user of force_gimple_operand is still at risk of running into a problem like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug tree-optimization/40464] [4.5 Regression] FAIL: g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and above
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-08-06 17:55 --- Patch posted to mailing list: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00367.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40464
[Bug middle-end/37046] New: Inlining produces calls which gimple_call_fndecl cannot handle correctly
In the following example, the fucntion hooray() does not get inlined,
even though it could.
#include
#include
static __attribute__((always_inline)) void hooray ()
{
printf ("hooray\n");
}
static __attribute__((always_inline)) void hiphip (void (*f)())
{
printf ("hip hip\n");
f ();
}
int main (int argc, int *argv[])
{
hiphip (hooray);
return 0;
}
int d()
{
hiphip (hooray);
return 86;
}
The reasons are I believe a bit more grave than the fact that this
(mis)use of anlways_inline does not work. When tree-inline.c produces
an inlined copy of hiphip() it remaps the destination of the call to f
in remap_gimple_stmt() to call hooray. However, the new call
statement has this form:
call>
which is a form that gimple_call_fndecl() cannot cope with. The
consequence is that rebuild_cgraph_edges() sees a call with an
unretrievable declaration and does not build a call graph edge for it.
Therefore, when early inlining inlines hiphip into its callers, there
is no call graph edge for main->hooray (or d->hooray) and so these
call sites are not even considered when doing regular inlining, let
alone always_inlining.
--
Summary: Inlining produces calls which gimple_call_fndecl cannot
handle correctly
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jamborm at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-08-07 10:11 --- I am testing the patch below which should fix the problem: 2008-08-07 Martin Jambor <[EMAIL PROTECTED]> * tree-inline.c (remap_gimple_stmt): Remove extraneous addr_expr from call statements. Index: iinln/gcc/tree-inline.c === --- iinln.orig/gcc/tree-inline.c +++ iinln/gcc/tree-inline.c @@ -1209,6 +1209,14 @@ remap_gimple_stmt (gimple stmt, copy_bod wi.info = id; walk_gimple_op (copy, remap_gimple_op_r, &wi); + /* When a parameter is propagated into a call destination, it is in the form + of call> which gimple_call_fndecl does not understand. + Therefore we need to take the extra addr_expr out here. */ + if (is_gimple_call (copy) + && TREE_CODE (gimple_call_fn (copy)) == ADDR_EXPR + && TREE_CODE (TREE_OPERAND (gimple_call_fn (copy), 0)) == FUNCTION_DECL) +gimple_call_set_fn (copy, TREE_OPERAND (gimple_call_fn (copy), 0)); + /* We have to handle EH region remapping of GIMPLE_RESX specially because the region number is not an operand. */ if (gimple_code (stmt) == GIMPLE_RESX && id->eh_region_offset) -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-07 10:11:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-08-07 15:49 --- Unfortunately, I got a fortran regression: /abuild/mjambor/iinln/gcc/testsuite/gfortran.dg/char_cast_1.f90:24: internal com piler error: in expand_call_inline, at tree-inline.c:3117 The assert is gcc_assert (dest->needed); so I think I might have uncovered some unrelated hidden problem. We will see. I will try to investigate but may not be able to go all the way because I'm, leaving for vacation tomorrow. Richi, that applies, to your question too. I will try but I may not make it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug middle-end/37046] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-08-08 07:50 --- (In reply to comment #4) > Interesting. I may have a look into the CCP problem. > Well, I think that we have pass_rebuild_cgraph_edges precisely because passes like CCP are not trusted to update call graph correctly. It is not an elegant solution but might just work. However, in order for it to work, gimple_call_fndecl() must be able to find the declarations (and this might also be problem for CCP generated calls too). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug middle-end/37046] [4.4 Regression] Inlining produces calls which gimple_call_fndecl cannot handle correctly
--- Comment #9 from jamborm at gcc dot gnu dot org 2008-09-10 10:11 --- I've been away from computer for a rather long time so I could not check earlier. However, the problem is indeed gone. Thanks Richi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37046
[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-09-11 11:42 --- I guess this is mine. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 11:42:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881
[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers
--- Comment #20 from jamborm at gcc dot gnu dot org 2008-10-22 15:09
---
OK, here is the status regarding the trunk (4.4) and the test cases
posted here:
1. The test case in the bug description now works in the sense that
funk is inlined even when not performing early inlining because
both indirect inlining and copy propagation can help the inliner do
this.
2. When compiling the code from comment #10 with indirect inlining
turned on (default on -O2) we end up with (taken from the
"optimized" tree dump):
a (int x)
{
:
if (x != 0)
goto ;
else
goto ;
:
f (); [tail call]
goto ;
:
f (); [tail call]
:
return;
}
Which obviously might be optimized even further but this is no
longer an inlining issue.
3. Finally, let's look at code from comment #11. The function main
still retains one call to foo(), specifically the one that came
from function call(). The reason is that early cpp does not see
the index being constant and thus does not replace the array_ref
directly with the constant. Arguments could be made that cpp
should be run few more times at various places (after ipa-cp, for
example) but IMHO pass ordering would need bigger justification
than this artificial example and this would be very difficult to
implement while also retaining the three phase division of ipa
passes for lto.
Because we are done with all three examples as far as inlining is
concerned, I think this is fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9079
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-10-30 17:43 ---
Well, yes, we do generate that code. However, the loop is unrolled
later on and the IR code on which the vrp complains later on actually is:
main ()
{
unsigned int ivtmp.27;
unsigned int pretmp.17;
int pretmp.16;
unsigned int pretmp.15;
unsigned int anz.0;
unsigned int D.1258;
char * D.1259;
int anz;
# BLOCK 2 freq:909
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1259_28 = &formatstr[0][0];
printf (&"%d %s\n"[0], 0, D.1259_28);
D.1259_39 = &formatstr[0][100];
printf (&"%d %s\n"[0], 1, D.1259_39);
D.1259_50 = &formatstr[0][200];
printf (&"%d %s\n"[0], 2, D.1259_50);
D.1259_61 = &formatstr[0][300];
printf (&"%d %s\n"[0], 3, D.1259_61);
D.1259_72 = &formatstr[0][400];
printf (&"%d %s\n"[0], 4, D.1259_72);
D.1259_83 = &formatstr[0][500];
printf (&"%d %s\n"[0], 5, D.1259_83);
D.1259_94 = &formatstr[0][600];
printf (&"%d %s\n"[0], 6, D.1259_94);
D.1259_105 = &formatstr[0][700];
printf (&"%d %s\n"[0], 7, D.1259_105);
D.1259_116 = &formatstr[0][800];
printf (&"%d %s\n"[0], 8, D.1259_116);
D.1259_7 = &formatstr[0][900];
printf (&"%d %s\n"[0], 9, D.1259_7);
printf (&" %d\n"[0], 10);
return 0;
# SUCC: EXIT [100.0%]
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-10-31 17:52 ---
The test-case in the bug description leads to bogus warnings in the
second run of the VRP pass. Yesterday me and Richi discussed the
possibility of simply not-giving out any warnings in the second runs
(as opposed to the first which would still generate the warnings it
does).
However, I have managed to modify the test case so that bogus warnings
are spitted out in the first run and so this workaround would not
really solve the problem:
extern int printf (__const char *__restrict __format, ...);
static int f3(int v)
{
int i,j = 0;
for (i = 0; i <= v; i++)
j++;
return j;
}
static int f2(char formatstr[10][100]) {
printf( "%d %s\n", 0, formatstr[f3(0)] );
printf( "%d %s\n", 1, formatstr[f3(1)] );
printf( "%d %s\n", 2, formatstr[f3(2)] );
printf( "%d %s\n", 3, formatstr[f3(3)] );
return 3;
}
static char formatstr[10][100];
int main( void ) {
int anz;
anz = f2(formatstr);
printf( " %d\n",anz);
return 0;
}
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
----
CC| |jamborm at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #4 from jamborm at gcc dot gnu dot org 2008-10-31 18:01 --- (In reply to comment #2) > So what is this? Is the warning logic wrong or is the IR wrong? It seems to me > that IR is valid. > Well, it probabaly isn't. I guess the second index should not ever exceed its upper bound (100 in these test cases) and it blatantly does. The proper solution (again, as suggested by Richi today) therefore most probabaly is "not to re-create ARRAY_REF for multi-dimensional arrays" at some place in folding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-11-04 15:51 --- Right, so this is the most simple (albeit not yet tested) patch I've been able to come up with. I am not sure what overall impact this is going to have. I'll briefly try to come up with something more sophisticated... Index: gcc/tree-ssa-forwprop.c === --- gcc/tree-ssa-forwprop.c (revision 141546) +++ gcc/tree-ssa-forwprop.c (working copy) @@ -812,6 +812,7 @@ forward_propagate_addr_expr_1 (tree name array_ref = TREE_OPERAND (def_rhs, 0); if (TREE_CODE (array_ref) != ARRAY_REF || TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE + || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF || !integer_zerop (TREE_OPERAND (array_ref, 1))) return false; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] [4.3/4.4 Regression] Bogus array bounds warning
--- Comment #6 from jamborm at gcc dot gnu dot org 2008-11-05 16:08 --- Subject: Bug 37861 Author: jamborm Date: Wed Nov 5 16:06:38 2008 New Revision: 141613 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141613 Log: 2008-11-05 Martin Jambor <[EMAIL PROTECTED]> PR middle-end/37861 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't turn pointer arithmetics into array_ref if the array is accessed through an indirect_ref. * testsuite/gcc.dg/Warray-bounds-5.c: New file. * testsuite/gcc.dg/Warray-bounds-6.c: New file. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-5.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
--- Comment #8 from jamborm at gcc dot gnu dot org 2008-11-10 10:06 ---
The previous patch resulted into a regression on m32c-unknown-elf and
thus I prepared a less intrusive one below. See also:
* http://gcc.gnu.org/ml/gcc/2008-11/msg00058.html and
* http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00353.html
The patch is pending approval in the mailing list.
2008-11-07 Martin Jambor <[EMAIL PROTECTED]>
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check
for INDIRECT_REFs.
(forward_propagate_addr_into_variable_array_index): Check that the
offset is not computed from a MULT_EXPR, use is_gimple_assign rather
than the gimple code directly.
Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 141673)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -613,19 +613,27 @@ forward_propagate_addr_into_variable_arr
tree index;
gimple offset_def, use_stmt = gsi_stmt (*use_stmt_gsi);
- /* Try to find an expression for a proper index. This is either
- a multiplication expression by the element size or just the
- ssa name we came along in case the element size is one. */
+ /* Get the offset's defining statement. */
+ offset_def = SSA_NAME_DEF_STMT (offset);
+
+ /* Try to find an expression for a proper index. This is either a
+ multiplication expression by the element size or just the ssa name we
came
+ along in case the element size is one. In that case, however, we do not
+ allow multiplications because they can be computing index to a higher
+ level dimension (PR 37861). */
if (integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (def_rhs)
-index = offset;
- else
{
- /* Get the offset's defining statement. */
- offset_def = SSA_NAME_DEF_STMT (offset);
+ if (is_gimple_assign (offset_def)
+ && gimple_assign_rhs_code (offset_def) == MULT_EXPR)
+ return false;
+ index = offset;
+}
+ else
+{
/* The statement which defines OFFSET before type conversion
must be a simple GIMPLE_ASSIGN. */
- if (gimple_code (offset_def) != GIMPLE_ASSIGN)
+ if (!is_gimple_assign (offset_def))
return false;
/* The RHS of the statement which defines OFFSET must be a
@@ -802,9 +810,6 @@ forward_propagate_addr_expr_1 (tree name
array_ref = TREE_OPERAND (def_rhs, 0);
if (TREE_CODE (array_ref) != ARRAY_REF
|| TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE
- /* Avoid accessing hidden multidimensional arrays in this way or VRP
-might give out bogus warnings (see PR 37861) */
- || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF
|| !integer_zerop (TREE_OPERAND (array_ref, 1)))
return false;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-30 18:43:24 |2008-11-10 18:39:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers
--- Comment #18 from jamborm at gcc dot gnu dot org 2008-04-01 14:50 --- I'm now working on a proper fix. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot | |org AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-01 02:53:11 |2008-04-01 14:50:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9079
[Bug debug/39086] New: Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
When compiling test 27_io/basic_istream/requirements/explicit_instantiation.cc
from the libstc++ testsuite and adding the -fno-tree-sra flag, I get
the following error:
--
u...@host:~/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/testsuite$
$HOME/gcc/svn/obj/./gcc/g++ -shared-libgcc -B$HOME/gcc/svn/obj/./gcc
-nostdinc++ -L$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/src
-L$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B$HOME/gcc/inst/svn//i686-pc-linux-gnu/bin/
-B$HOME/gcc/inst/svn//i686-pc-linux-gnu/lib/ -isystem
$HOME/gcc/inst/svn//i686-pc-linux-gnu/include -isystem
$HOME/gcc/inst/svn//i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT
-fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g
-O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include
-I$HOME/gcc/svn/libstdc++-v3/libsupc++
-I$HOME/gcc/svn/libstdc++-v3/include/backward
-I$HOME/gcc/svn/libstdc++-v3/testsuite/util
$HOME/gcc/svn/libstdc++-v3/testsuite/27_io/basic_istream/requirements/explicit_instantiation.cc
-include bits/stdc++.h -S -o explicit_instantiation.s -fno-tree-sra
In file included from
$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/istream:833,
from
$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/sstream:44,
from
$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/complex:52,
from
$HOME/gcc/svn/libstdc++-v3/include/precompiled/stdc++.h:69:
$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/istream.tcc: In
member function 'typename std::basic_istream<_CharT, _Traits>::int_type
std::basic_istream<_CharT, _Traits>::get() [with _CharT =
__gnu_cxx::character, _Traits =
std::char_traits<__gnu_cxx::character >]':
$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/istream.tcc:222:
internal compiler error: in decl_ultimate_origin, at dwarf2out.c:5770
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
This is with trunk revision 143890, compiled on i686-pc-linux without
bootstrap. I will attach preprocessed source shortly.
--
Summary: Failing assert in dwarf2out.c:5770 when compiling with -
fno-tree-sra
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamborm at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug debug/39086] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-02-03 15:09 --- Created an attachment (id=17232) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17232&action=view) Preprocessed source Enough to compile with -O2 -g -fno-tree-sra explicit_instantiation.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug debug/39086] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-02-03 16:56 --- Created an attachment (id=17236) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17236&action=view) Preprocessed source OK, this one is hopefully without any precompiled headers. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Attachment #17232|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug middle-end/32964] [4.3/4.4 Regression] union cause inefficient code inside loops
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-02-06 21:45 --- Indeed, this testcase is fully scalarized by the new SRA even as it is today. (If you don't know what new SRA I mean, I hope I'll post it to the list as an RFC next week). -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC| |jamborm at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-02-23 14:09 ---
I don't understand the comment above the assert at all (Honza probably
does) and so this might not be the correct approach but the following
patch should just obviously work. At least it does for this testcase
and I am about to bootstrap and regression test it:
2009-02-23 Martin Jambor
* tree-inline.c (tree_versionable_function_p): Return false for
functions calling setjmp or alloca.
Index: tree-inline.c
===
--- tree-inline.c (revision 144380)
+++ tree-inline.c (working copy)
@@ -4174,12 +4174,17 @@ copy_static_chain (tree static_chain, co
bool
tree_versionable_function_p (tree fndecl)
{
+ struct function *fn_cfun;
if (fndecl == NULL_TREE)
return false;
/* ??? There are cases where a function is
uninlinable but can be versioned. */
if (!tree_inlinable_function_p (fndecl))
return false;
+
+ fn_cfun = DECL_STRUCT_FUNCTION (fndecl);
+ if (fn_cfun->calls_setjmp || fn_cfun->calls_alloca)
+return false;
return true;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-02-24 13:44 --- After discussion with Honza, I have tried a more complex approach, the patch is at: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01118.html -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-02-21 17:56:56 |2009-02-24 13:44:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
[Bug tree-optimization/39259] [4.4 Regression] internal compiler error: in initialize_cfun, at tree-inline.c:1749
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-02-25 18:19 --- Fixed with: Author: jamborm Date: Wed Feb 25 17:34:40 2009 New Revision: 144428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144428 Log: 2009-02-25 Martin Jambor * tree-inline.c (initialize_cfun): Remove asserts for calls_setjmp and alls_alloca function flags. (copy_bb): Set calls_setjmp and alls_alloca function flags if such calls are detected. Added: trunk/gcc/testsuite/g++.dg/torture/pr39259.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-02-28 00:30 --- I have just posted a patch to fix this issue on the 4.3 branch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01245.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
