[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-01 08:32 --- Fix committed, PR can be closed. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- Comment #12 from dorit at gcc dot gnu dot org 2007-07-01 08:35 --- A fix was committed, looks like the patch can be closed. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
[Bug tree-optimization/30795] [4.3 Regression] ice for legal code with -ftree-vectorize -O2
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-01 08:38 --- This fix was committed with the wrong PR number (sorry about that): 2007-02-19 Dorit Nuzman <[EMAIL PROTECTED]> PR tree-optimization/30975 * tree-vect-trasnform.c (vect_get_vec_def_for_stmt_copy): Remove wrong assert. Looks like this PR can be closed. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
[Bug tree-optimization/31333] ICE with -fno-tree-dominator-opts -ftree-vectorize -msse
--- Comment #2 from dorit at gcc dot gnu dot org 2007-07-01 08:42 --- (oops - wrong keyword) -- dorit at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
[Bug testsuite/32569] Use of different numbers in logfile test output makes diff output baloon
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-01 08:43 --- This is not how you are supposed to compare testsuite log files. Use contrib/compare_tests to compare the .sum files. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32569
[Bug tree-optimization/31966] Miscompiles valid code with -ftree-vectorize and -march=nocona
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-01 08:47 --- I was able to reproduce the behavior on a Pentinum4 with a recent 4.3 snapshot. It doesn't look like it's the vectorizer's fault - nothing gets vectorized. However, if I disable the tree-level if-conversion (which is automatically enabled by -ftree-vectorize) - the result of '-ftree-vectorize -O2 -march=nocona divop.c -o divop' becomes '3CBA83'. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug tree-optimization/32533] [4.1/4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-01 08:51 --- PR31966 is also wrong code which seems to be a result of the tree-level if-conversion (nothing gets vectorized these, and if tree-if-conversion is disabled everything works ok). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug tree-optimization/31966] Miscompiles valid code with -ftree-vectorize and -march=nocona
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 08:52 --- This may be related to PR32533 (also wrong-code due to tree-if-conversion). -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-01 08:52:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug c/32570] Compiling GCC 4.3.0 with CIL instead of using GCC 4.2 or 4.3 finds many warnings that GCC does not report
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-01 08:52 --- >/root/downloads/gcc-4_3-trunk/gcc/toplev.c:558: Error: There is a definition already for floor_log2 This is because floor_log2 uses the GNU C "extern inline". >/gcc-4_3-trunk/gcc/config/i386/i386.c:4121: warning: unused parameter 'named' > /gcc-4_3-trunk/gcc/config/i386/i386.c:4402: warning: unused parameter > 'valtype' This is a bug in the cilly because they are used, just not used if TARGET_64BIT_MS_ABI is always false which is the reason why GCC does not warn (this is not a preprocessed conditional but instead a compile time conditional). >/gcc-4_3-trunk/gcc/builtins.c:9410: warning: ISO C forbids casting nonscalar >to the same type > /gcc-4_3-trunk/gcc/builtins.c:9416: warning: ISO C forbids casting nonscalar > to the same type There is no cast there. So this obviously a bug in cilly. So all the warnings you pointed out are really bugs in cilly and not bugs in GCC sources. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32570
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-01 09:13 --- >The test runs differently when compiled with g++-3.4.6 (GCC) 3.4.6 (Gentoo >3.4.6-r2, ssp-3.4.6-1.0, > pie-8.7.10) and g++-4.1.2 (GCC) 4.1.2 (Gentoo 4.1.2) versions of the GCC Yes and 4.1.x result is the correct according to the standard. "We are in default template function" should be printed because the overloaded set for visit_each in visit_each (with two arguments) is the only one because the types are not in the namespace of bugsrus. I have not looked into the original testcase yet but the new one is correct for 4.1 (see gcc-4.1/changes.html for more info). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug tree-optimization/32568] [4.3 Regression] internal compiler error: in vn_lookup, at tree-vn.c:290
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-01 09:21 --- >I did the svn this morning (PDT). Do I need to do another svn? Yes, it was modified at "2007-06-30 19:20:06 -0700". So 7:20 pm PDT :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32568
[Bug tree-optimization/32568] [4.3 Regression] internal compiler error: in vn_lookup, at tree-vn.c:290
--- Comment #4 from trog24 at comcast dot net 2007-07-01 09:22 --- Subject: Re: [4.3 Regression] internal compiler error: in vn_lookup, at tree-vn.c:290 Thank you. Frank On Jul 1, 2007, at 2:21 AM, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-01 > 09:21 --- >>I did the svn this morning (PDT). Do I need to do another >> svn? > Yes, it was modified at "2007-06-30 19:20:06 -0700". So 7:20 pm > PDT :). > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32568 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32568
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #12 from dorit at il dot ibm dot com 2007-07-01 09:30 --- > Subject: Re: -ftree-vectorize results in internal compiler error on AMD64 > Zdenek's patch for cleaning the dataref analysis is also fixing this bug. > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html So now that Zdenek's patch went in, can someone confirm if this problem doesn't occur anymore on x86_64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug tree-optimization/31966] [4.1/4.2/4.3 Regression] Miscompiles valid code with -ftree-vectorize
--- Comment #5 from ubizjak at gmail dot com 2007-07-01 09:33 ---
Confirmed. This is the same bug as PR32533, but this one comes with the c
testcase. The problem is in ifcvt pass.
In -march=nocona case (-march=nocona -O2 -ftree-vectorize), we have following
code before ifcvt pass:
if (high_top_bit_11 != 0)
goto ;
else
goto ;
:
if (d_7(D) <= high_19)
goto ;
else
goto ;
:
high_21 = high_19 - d_7(D);
quotient_22 = quotient_20 | 1;
:
# quotient_3 = PHI
# high_1 = PHI
j_23 = j_32 + 1;
This code is converted by ifcvt pass to:
quotient_20 = quotient_31 << 1; [+]
D.2068_5 = high_top_bit_11 == 0;
D.2069_4 = d_7(D) <= high_19;
_ifc_.29_2 = D.2068_5 && D.2069_4;
D.2071_29 = high_top_bit_11 == 0;
D.2072_33 = d_7(D) > high_19;
_ifc_.30_34 = D.2071_29 && D.2072_33;
high_21 = high_19 - d_7(D);
quotient_22 = quotient_20 | 1; [++]
quotient_3 = high_top_bit_11 == 0 ? quotient_20 : quotient_22; <<< here!
high_1 = high_top_bit_11 == 0 ? high_19 : high_21; <<< here!
j_23 = j_32 + 1;
The condition for quotient_3 [and high_1], produced by ifcvt pass is wrong, and
should be:
quotient_3 = _ifc_.3034 ? quotient_20 : quotient_22;
This is evident from the inner loop of the testcase:
--cut here--
{
word high_top_bit = (high & MP_WORD_TOP_BIT);
high <<= 1;
high |= (n0 >> (MP_WORD_BITS-1-j)) & 1;
quotient <<= 1;[+]
if(high_top_bit || high >= d) _the_condition_
{
high -= d;
quotient |= 1; [++]
}
}
--cut here--
Due to slighlty different gimple generation for -march=core2 (please look into
_.004t.gimple) where only if branch is created, ifcvt is able to create correct
code:
quotient_20 = quotient_34 << 1; [+]
D.2065_21 = high_top_bit_11 != 0;
D.2066_22 = high_19 >= d_7(D);
D.2067_23 = D.2065_21 || D.2066_22;
high_24 = high_19 - d_7(D);
quotient_25 = quotient_20 | 1;[++]
quotient_3 = D.2067_23 ? quotient_25 : quotient_20; here
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Priority|P3 |P1
Summary|Miscompiles valid code with |[4.1/4.2/4.3 Regression]
|-ftree-vectorize and - |Miscompiles valid code with
|march=nocona|-ftree-vectorize
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug target/32558] v850: unrecognizable insn compiling libgcc2 on 64-bit CPU
--- Comment #1 from rask at sygehus dot dk 2007-07-01 09:37 --- Additionally, the asm output has problems around the edges (seen in _pack_df): mov 9218868437227405312,r14 # 395 *movdi_internal/1 [length = 4] mov 0,r15 -- rask at sygehus dot dk changed: What|Removed |Added CC||nickc at redhat dot com Summary|unrecognizable insn |v850: unrecognizable insn |compiling libgcc2 on 64-bit |compiling libgcc2 on 64-bit |CPU |CPU http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
[Bug tree-optimization/32533] [4.1/4.2 regression] miscompilation at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #8 from ubizjak at gmail dot com 2007-07-01 09:40 --- (In reply to comment #6) > Hm, in the dump (gcc-4.1.3), preceeding ifcvt, we have: > Isn't marked statement unreachable? The problem is in ifcvt pass, as confirmed by a c testcase in PR31966. This problem is also present in 4.3 branch, but (as explained in Comment #1), not triggered by the fortran testcase in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32533
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #13 from ubizjak at gmail dot com 2007-07-01 09:52 --- (In reply to comment #12) > > Subject: Re: -ftree-vectorize results in internal compiler error on AMD64 > > Zdenek's patch for cleaning the dataref analysis is also fixing this bug. > > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html > > So now that Zdenek's patch went in, can someone confirm if this problem > doesn't > occur anymore on x86_64? Compiles OK for original and reduced testcase (-O2 -ftree-vectorize) with: Target: x86_64-unknown-linux-gnu gcc version 4.3.0 20070622 (experimental) Also works OK when (-m32 -msse3) is added to activate 32bit compilation. BTW: I plan to add the testcase from Comment #11 to vectorizer testsuite. Also note that this PR is not marked as a regression on 4.0/4.1/4.2 so it should be either marked as a regression or should be closed as the testcase compiles OK. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-01 09:59 ---
I'm testing the following patch (seems to fix the two testcases in this PR on
Pentium4. still need to bootstrap etc, and check the powerpc bits)
Index: gcc/targhooks.c
===
*** gcc/targhooks.c (revision 126162)
--- gcc/targhooks.c (working copy)
*** tree default_mangle_decl_assembler_name
*** 634,637
--- 634,653
return id;
}
+ bool
+ default_builtin_vector_alignment_reachable (tree type, bool is_packed)
+ {
+ if (is_packed)
+ return false;
+
+ /* Assuming that types whose size is > pointer-size are not guaranteed to
be
+ naturally aligned. */
+ if (tree_int_cst_compare (TYPE_SIZE (type), bitsize_int (POINTER_SIZE)) >
0)
+ return false;
+
+ /* Assuming that types whose size is <= pointer-size
+ are naturally aligned. */
+ return true;
+ }
+
#include "gt-targhooks.h"
Index: gcc/targhooks.h
===
*** gcc/targhooks.h (revision 126162)
--- gcc/targhooks.h (working copy)
*** extern tree default_builtin_vectorized_c
*** 62,67
--- 62,69
extern tree default_builtin_reciprocal (enum built_in_function, bool, bool);
+ extern bool default_builtin_vector_alignment_reachable (tree, bool);
+
/* These are here, and not in hooks.[ch], because not all users of
hooks.h include tm.h, and thus we don't have CUMULATIVE_ARGS. */
Index: gcc/tree.h
===
*** gcc/tree.h (revision 126162)
--- gcc/tree.h (working copy)
*** extern tree get_inner_reference (tree, H
*** 4327,4332
--- 4327,4338
tree *, enum machine_mode *, int *, int *,
bool);
+ /* Given an expression EXP that may be a COMPONENT_REF or an ARRAY_REF,
+look for whether EXP or any nested component-refs within EXP is marked
+as PACKED. */
+
+ extern bool contains_packed_reference (tree exp);
+
/* Return 1 if T is an expression that get_inner_reference handles. */
extern int handled_component_p (tree);
Index: gcc/target.h
===
*** gcc/target.h(revision 126162)
--- gcc/target.h(working copy)
*** struct gcc_target
*** 413,418
--- 413,422
element-by-element products for the odd elements. */
tree (* builtin_mul_widen_even) (tree);
tree (* builtin_mul_widen_odd) (tree);
+
+ /* Return true if vector alignment is reachable (by peeling N
+interations) for the given type. */
+ bool (* vector_alignment_reachable) (tree, bool);
} vectorize;
/* The initial value of target_flags. */
Index: gcc/testsuite/gcc.dg/vect/vect-align-1.c
===
*** gcc/testsuite/gcc.dg/vect/vect-align-1.c(revision 0)
--- gcc/testsuite/gcc.dg/vect/vect-align-1.c(revision 0)
***
*** 0
--- 1,50
+ /* { dg-require-effective-target vect_int } */
+
+ #include
+ #include
+ #include "tree-vect.h"
+
+ /* Compile time known misalignment. Cannot use loop peeling to align
+the store. */
+
+ #define N 16
+
+ struct foo {
+ char x;
+ int y[N];
+ } __attribute__((packed));
+
+ int
+ main1 (struct foo * __restrict__ p)
+ {
+ int i;
+ int x[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
+
+ for (i = 0; i < N; i++)
+ {
+ p->y[i] = x[i];
+ }
+
+ /* check results: */
+ for (i = 0; i < N; i++)
+ {
+ if (p->y[i] != x[i])
+ abort ();
+ }
+ return 0;
+ }
+
+
+ int main (void)
+ {
+ int i;
+ struct foo *p = malloc (2*sizeof (struct foo));
+ check_vect ();
+
+ main1 (p);
+ return 0;
+ }
+
+ /* { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning" 1 "vect" } } */
+ /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
+ /* { dg-final { cleanup-tree-dump "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/pr25413a.c
===
*** gcc/testsuite/gcc.dg/vect/pr25413a.c(revision 0)
--- gcc/testsuite/gcc.dg/vect/pr25413a.c(revision 0)
***
*** 0
--- 1,129
+ /* { dg-require-effective-target vect_double } */
+
+ #include
+ #include "tree-vect.h"
+
+ #define N 8
+
+ typedef unsigned int size_t;
+
+ extern void *malloc (size_t __size) __attribute__ ((__nothrow__))
__attribute__ ((__malloc__));
+
+ typedef double num_t;
+ static const num_t num__infty = ((num_t)1.0)/((num_t)0.0);
+
+ struct oct_tt;
+ typedef struct oct_tt oct_t;
+
+ typedef unsigned int var_t;
+ typedef enum {
+ OCT_EMPTY = 0,
+ OCT_NORMAL = 1,
+ OCT_CLOSED = 2
+ } oct_state;
+
+ struct oct_tt {
+ var_t n;
+
+ int ref;
+
+ oct_state sta
[Bug target/32558] v850: unrecognizable insn compiling libgcc2 on 64-bit CPU
--- Comment #2 from rask at sygehus dot dk 2007-07-01 10:01 --- Created an attachment (id=13810) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13810&action=view) First attempt at a patch The attached patch makes the v850 build on x86_64. There are a few regressions (when run on i686-pc-linux-gnu): +FAIL: gcc.c-torture/compile/pr23233-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) +FAIL: gcc.c-torture/compile/pr23233-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) +FAIL: gcc.c-torture/compile/pr29250.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) +FAIL: gcc.c-torture/compile/pr29250.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) +FAIL: gcc.c-torture/compile/pr29250.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) +FAIL: gcc.c-torture/compile/pr29250.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) +FAIL: gcc.dg/setjmp-1.c spurious clobbered warning (test for bogus messages, line 16) +FAIL: g++.dg/opt/asm1.C double sized union element should be addressible (test for bogus messages, line 8) +FAIL: g++.dg/opt/pr15551.C execution test >From the logs: Executing on host: /home/rask/build/gcc-v850-unknown-elf/gcc/xgcc -B/home/rask/build/gcc-v850-unknown-elf/gcc/ -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -w -fno-show-column -c -isystem /home/rask/build/gcc-v850-unknown-elf/v850-unknown-elf/./newlib/targ-include -isystem /n/08/rask/src/all/newlib/libc/include -o pr23233-1.o /n/08/rask/src/all/gcc/testsuite/gcc.c-torture/compile/pr23233-1.c(timeout = 300) /n/08/rask/src/all/gcc/testsuite/gcc.c-torture/compile/pr23233-1.c: In function 'foo': /n/08/rask/src/all/gcc/testsuite/gcc.c-torture/compile/pr23233-1.c:8: error: unrecognizable insn: (jump_insn 147 142 144 12 (return) -1 (nil)) /n/08/rask/src/all/gcc/testsuite/gcc.c-torture/compile/pr23233-1.c:8: internal compiler error: in extract_insn, at recog.c:1991 (Same thing with gcc.c-torture/compile/pr29250.c.) Executing on host: /home/rask/build/gcc-v850-unknown-elf/gcc/xgcc -B/home/rask/build/gcc-v850-unknown-elf/gcc/ /n/08/rask/src/all/gcc/testsuite/gcc.dg/setjmp-1.c -O -Wclobbered -Wextra -Wall -fno-show-column -S -isystem /home/rask/build/gcc-v850-unknown-elf/v850-unknown-elf/./newlib/targ-include -isystem /n/08/rask/src/all/newlib/libc/include -o setjmp-1.s(timeout = 300) /n/08/rask/src/all/gcc/testsuite/gcc.dg/setjmp-1.c: In function 'compare_float': /n/08/rask/src/all/gcc/testsuite/gcc.dg/setjmp-1.c:16: warning: argument 'b' might be clobbered by 'longjmp' or 'vfork' Executing on host: /home/rask/build/gcc-v850-unknown-elf/gcc/testsuite/g++/../../g++ -B/home/rask/build/gcc-v850-unknown-elf/gcc/testsuite/g++/../../ /n/08/rask/src/all/gcc/testsuite/g++.dg/opt/asm1.C -nostdinc++ -I/home/rask/build/gcc-v850-unknown-elf/v850-unknown-elf/libstdc++-v3/include/v850-unknown-elf -I/home/rask/build/gcc-v850-unknown-elf/v850-unknown-elf/libstdc++-v3/include -I/n/08/rask/src/all/libstdc++-v3/libsupc++ -I/n/08/rask/src/all/libstdc++-v3/include/backward -I/n/08/rask/src/all/libstdc++-v3/testsuite/util -fmessage-length=0 -O -S -isystem /home/rask/build/gcc-v850-unknown-elf/v850-unknown-elf/./newlib/targ-include -isystem /n/08/rask/src/all/newlib/libc/include -o asm1.s(timeout = 300) /n/08/rask/src/all/gcc/testsuite/g++.dg/opt/asm1.C: In function 'void foo()': /n/08/rask/src/all/gcc/testsuite/g++.dg/opt/asm1.C:8: error: output number 0 not directly addressable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
[Bug tree-optimization/26362] ICE on the autovect-branch (gfortran example)
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 10:05 --- Closed based on Ira's comment. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26362
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #14 from dorit at gcc dot gnu dot org 2007-07-01 10:12 --- > > So now that Zdenek's patch went in, can someone confirm if this problem > > doesn't > > occur anymore on x86_64? > Compiles OK for original and reduced testcase (-O2 -ftree-vectorize) with: > Target: x86_64-unknown-linux-gnu > gcc version 4.3.0 20070622 (experimental) > Also works OK when (-m32 -msse3) is added to activate 32bit compilation. thanks for checking! > BTW: I plan to add the testcase from Comment #11 to vectorizer testsuite. good idea > Also note that this PR is not marked as a regression on 4.0/4.1/4.2 so it > should be either marked as a regression or should be closed as the testcase > compiles OK. > > I vote for closing it... maybe you can close it after committing the testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug tree-optimization/27659] ICE on autovect-branch
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 10:16 --- Can anyone still see this failure, or can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27659
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #15 from uros at gcc dot gnu dot org 2007-07-01 10:30 --- Subject: Bug 25371 Author: uros Date: Sun Jul 1 10:30:31 2007 New Revision: 126163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126163 Log: PR tree-optimization/25371 * gcc.dg/vect/pr25371.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr25371.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #16 from ubizjak at gmail dot com 2007-07-01 10:32 --- Closed, not marked as a regression. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #7 from cavedon at sssup dot it 2007-07-01 10:37 --- Created an attachment (id=13811) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13811&action=view) Patch to test.cpp, working with gcc 4.1 Adding the declaration of "our template function" before the "default template function without 3rd arg" makes gcc 4.1 behave the same way as 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug middle-end/32559] [4.3 regression] ICE with vector arithmetic
--- Comment #2 from uros at gcc dot gnu dot org 2007-07-01 10:38 --- Subject: Bug 32559 Author: uros Date: Sun Jul 1 10:38:03 2007 New Revision: 126164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126164 Log: PR middle-end/32559 * fold-const.c (fold-binary) [PLUS_EXPR]: Convert ~X + X to 1 or X + ~X to 1 only for INTEGRAL_TYPE_P type. testsuite/ChangeLog: PR middle-end/32559 * gcc.dg/pr32559.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32559.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32559
[Bug middle-end/32559] [4.3 regression] ICE with vector arithmetic
--- Comment #3 from ubizjak at gmail dot com 2007-07-01 10:40 --- Fixed in mainline SVN. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32559
[Bug tree-optimization/31333] ICE with -fno-tree-dominator-opts -ftree-vectorize -msse
--- Comment #3 from ubizjak at gmail dot com 2007-07-01 10:44 --- This works for me on x86_64 host, producing correct code (with the flags above, also with and without -m32, for all optimization levels. Also, this testcase doesn't fail for x86 targets for a long time... -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #11 from patchapp at dberlin dot org 2007-07-01 11:15 --- Subject: Bug number PR 32230 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00018.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32571] New: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
Hello, there seems to be a problem compiling the attached source file with i686-pc-linux-gnu-gcc: gcc -m32 -Wp,-MD,drivers/infiniband/hw/mthca/.mthca_provider.o.d -nostdinc -isystem /home/mstein/host-gcc/trunk-2007-07-01/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(mthca_provider)" -D"KBUILD_MODNAME=KBUILD_STR(ib_mthca)" -c -o drivers/infiniband/hw/mthca/.tmp_mthca_provider.o drivers/infiniband/hw/mthca/mthca_provider.c gcc: warning: -pipe ignored because -save-temps specified drivers/infiniband/hw/mthca/mthca_provider.c: In function 'mthca_unmap_fmr': drivers/infiniband/hw/mthca/mthca_provider.c:1133: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. host gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/mstein/svn/trunk/configure --enable-languages=c --disable-nls --prefix=/n/07/mstein/host-gcc/trunk-2007-07-01 Thread model: posix gcc version 4.3.0 20070630 (experimental) Tested revion: 126157 Last succesfull build revision: 126095 -- Summary: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-01 11:23 --- (In reply to comment #0) > I'm getting the following segfault on IA-64 with current 4.2 and 4.3. > This goes back at least to 20060721 - I don't have anything older to > test here at the moment. I don't see this segfault on x86_64. > Unfortunately I don't have a working gdb on ia-64 at the moment so > I cannot supply a backtrace. Can someone with access to ia64 provide more detail? gdb backtrace? vectorizer dump file (with -fdump-tree-vect-details)? (can't reproduce it on powerpc and i386) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #2 from tbm at cyrius dot com 2007-07-01 11:32 --- (In reply to comment #1) > Can someone with access to ia64 provide more detail? gdb backtrace? vectorizer > dump file (with -fdump-tree-vect-details)? (can't reproduce it on powerpc and > i386) I'm afraid I still don't have a working gdb, but I'll attach the dump file. Steve, can you post a backtrace? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #3 from tbm at cyrius dot com 2007-07-01 11:33 --- Created an attachment (id=13812) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13812&action=view) dump file of -fdump-tree-vect-details -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug tree-optimization/32571] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-01 11:34 --- Created an attachment (id=13813) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13813&action=view) preprocessed source file from linux-2.6.20, delta-reduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-01 12:43 ---
Dependence analysis now fails with a different message:
(compute_affine_dependence
(stmt_a =
D.1373_43 = (*a_42(D))[D.1372_41])
(stmt_b =
(*a_42(D))[D.1370_44] = D.1375_47)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {pretmp.50_1 + 1, +, 1}_1)
(chrec_b = {0, +, 1}_1)
(analyze_siv_subscript
siv test failed: unimplemented.
)
(overlap_iterations_a = not known
)
(overlap_iterations_b = not known
)
)
(dependence classified: scev_not_known)
)
)
Sebastian - any thughts/plans?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug tree-optimization/32482] [i386] ICE verify_ssa failed
--- Comment #2 from mstein at phenix dot rootshell dot be 2007-07-01 12:45 --- Created an attachment (id=13814) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13814&action=view) preprocessed source file from linux-2.6.20, delta-reduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32482
[Bug tree-optimization/32375] not vectorized: can't determine dependence (array sections)
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-01 12:46 ---
Looks like a similar problem to PR32378:
(compute_affine_dependence
(stmt_a =
D.1398_74 = (*aa_73(D))[D.1397_72])
(stmt_b =
(*aa_73(D))[D.1393_68] = D.1408_88)
(subscript_dependence_tester
(analyze_overlapping_iterations
(chrec_a = {D.1396_71 + 1, +, 1}_2)
(chrec_b = {D.1392_67 + 1, +, 1}_2)
(analyze_siv_subscript
siv test failed: unimplemented.
)
(overlap_iterations_a = not known
)
(overlap_iterations_b = not known
)
)
(dependence classified: scev_not_known)
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 12:48 --- Looks like the data-dependence analysis is doing it's job (it figures out that the dependence distance is 1), but the vectorizer is still not willing to vectorize. Need to look into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug tree-optimization/32477] ice for legal code with -O2 -ftree-vectorize
--- Comment #3 from irar at il dot ibm dot com 2007-07-01 13:21 --- A fix to PR 32230 http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00018.html fixes this one too. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32477
[Bug debug/32445] no debug information for loop counters
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-01 13:28 --- (In reply to comment #1) > On the mainline, we have ivtmp.33 going from 1 to 101 so it does not equal the > same as what i is. ... and ivopts do this transformation because of my favourite hack -- md of i386 claims that more complex addressing modes are cheaper, so ivopts prefer to introduce unnecessary offsets. I guess it is time to check again whether removing this nonsense still causes performance regressions. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-01 13:28:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32445
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Comment #11 from ubizjak at gmail dot com 2007-07-01 13:40 --- (In reply to comment #9) >PR tree-optimization/23115 >* tree-if-conv.c (find_phi_replacement_condition): Check domninated_by >relation. This fix is not enough to solve problems described in Comment #8. Actually, the condition, introduced by attached patch: + || dominated_by_p (CDI_DOMINATORS, second_bb, first_bb)) doesn't even trigger anymore for the testcase in this PR, and at least gcc 4.3.0 passes mentioned testcase _only_ due to slightly different CFG. However, the same problem (wrong handling of non perfect diamond) is the root cause of PR 31966. It is up to bugmaster to reopen this PR, as the fix is not effective. -- ubizjak at gmail dot com changed: What|Removed |Added OtherBugsDependingO||31966 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug tree-optimization/31966] [4.1/4.2/4.3 Regression] Miscompiles valid code with -ftree-vectorize
--- Comment #6 from ubizjak at gmail dot com 2007-07-01 14:20 --- In the tree-if-conv.c, there is a comment with the reference to PR23115, where similar problems were addressed: 4) If pred B is dominated by pred A then use pred B's condition. See PR23115. */ For attached testcase, we have following CFG: bb3 / \ / \ / \ V V bb5 < bb4 \ / \ / \ / V V bb6 with the conditions: bb3: C3 = (high_top_bit_11 != 0) bb4: C4 = (d_7(D) <= high_19) predicates for blocks are then: bb4: !C3 bb5: C3 || !C3 & C4 [ = C3 || C4 ] In bb6, we have: # quotient_3 = PHI For some reason domiated_by_p() failed to detect that bb5 is dominated by bb4 and if-conversion simply assigns bb4 predicate (!C3) as the phi node condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #24 from zadeck at naturalbridge dot com 2007-07-01 14:45 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c ian at airs dot com wrote: > --- Comment #23 from ian at airs dot com 2007-06-30 17:57 --- > The patch in comment #19 of PR 32437 looks clearly correct. That > patch should not be reverted, at least not by itself. I'm not clear > on whether that was the patch that was reverted, but, if it was, I > don't think it should have been. We are not in a time critical > situation here. Let's take the time to figure out the right fix even > if Richard doesn't have time to work on it. > > This is DCE, not DSE. In DSE we can not eliminate frame related > instructions, because the stores into the frame are used by code which > dataflow doesn't see: the exception unwinder. That does not apply to > DCE. In DCE, we should be able to eliminate changes to the stack > pointer when the stack pointer is not used, even though those changes > are frame related. > > So I think this patch should be unreverted, and I don't think you should add a > test for frame relatedness. Then we should fix PR 32475. Further comments > over there. > > > 2007-07-01 Richard Sandiford <[EMAIL PROTECTED]> Unreverting Richard's Revert of: 2007-06-27 Richard Sandiford <[EMAIL PROTECTED]> * dce.c (deletable_insn_p_1): New function, split out from... (deletable_insn_p): ...here. Only treat bare USEs and CLOBBERs specially, not those inside PARALLELs. Remove BODY argument and adjust recursive call accordingly. (prescan_insns_for_dce): Update call to delete_insn_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug tree-optimization/31966] [4.1/4.2/4.3 Regression] Miscompiles valid code with -ftree-vectorize
--- Comment #7 from ubizjak at gmail dot com 2007-07-01 15:46 --- Well, the problem is, that we "forgot" to take into account false branch from bb4 to bb6. In notation form the Comment #6, this branch has the condition !C4, so the total condition for branch from bb4 leading to bb6 would be: !C3 && !C4. The conditions for both branches leading to phi node are then: left: (C3 || C4) && 1 ->C3 || C4 right: !C3 && !C4 -> !(C3 || C4) With above correction, phi # quotient_3 = PHI would be substituted with: quotient_3 = !(C3 || C4) ? quotient_20 : quotient_22; or: quotient_3 = (C3 || C4) ? quotient_22 : quotient_20; which just happens to be the correct condition. QED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-01 15:46 --- Subject: Bug 32554 Author: jvdelisle Date: Sun Jul 1 15:46:33 2007 New Revision: 126173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126173 Log: 2007-07-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32554 * io/write.c (output_float): Set edigits to a fixed size, avoiding variation in field width calculation and eliminate buffer overrun. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-01 15:49 --- Subject: Bug 32554 Author: jvdelisle Date: Sun Jul 1 15:49:37 2007 New Revision: 126174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126174 Log: 2007-06-29 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32554 * gfortran.dg/fmt_p_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_p_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32239] optimize power in loops, use __builtin_powi instead of _gfortran_pow_r4_i4
--- Comment #5 from jb at gcc dot gnu dot org 2007-07-01 16:24 --- Subject: Bug 32239 Author: jb Date: Sun Jul 1 16:24:38 2007 New Revision: 126175 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126175 Log: gcc/fortran: 2007-07-01 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/32239 * trans-expr.c (gfc_conv_power_op): Use builtin_powi for real**int4 powers. * f95-lang.c (gfc_init_builtin_functions): Add builtin_powi to the builtins table. libgfortran: 2007-07-01 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/32239 * Makefile.am: Don't generate real**int4 pow functions. * gfortran.map: Remove real**int4 pow symbols. * Makefile.in: Regenerated. testsuite 2007-07-01 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/32239 * gfortran.fortran-torture/execute/intrinsic_fraction_exponent.f90 (test_4): Use proper test for floating point equality. (test_8): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_fraction_exponent.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/gfortran.map -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32239
gcc-core-4.2 does not build after 5/30/2007 snapshot
I usually download and build each week's snapshot of GCC 4.2 on Mac OS X (10.4.10). I unpack just gcc-core-4.2, configure, and it builds perfectly. This process has worked fine for months up until the 5/30/2007 snapshot. Starting in June sometime this broke. It dies early on in libiberty cleaning before any compiles have taken place; here is the error string: /bin/sh: line 1: cd: testsuite: No such file or directory Dan Allen
[Bug testsuite/32014] new gcc failures
--- Comment #8 from patchapp at dberlin dot org 2007-07-01 17:56 --- Subject: Bug number PR32014 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00031.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
[Bug tree-optimization/32572] New: Small C++ function fails to inline with large negative badness
The code below doesn't get image::set inlined into set_test at -O3, though it's
trivial.
Is it an integer overflow problem?
> /usr/local/gcc43/bin/g++ -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: ../gcc/configure --prefix=/usr/local/gcc43 --disable-multilib
--with-arch=pentium-m --with-tune=nocona --enable-target-optspace
--disable-bootstrap --with-gmp=/sw --with-system-zlib
--enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.3.0 20070701 (experimental)
> /usr/local/gcc43/bin/g++ -O3 -c -fdump-ipa-all -fdump-tree-final_cleanup
> rt-inline-overflow.cpp
>From the .inline dump:
Deciding on inlining. Starting with 39 insns.
Inlining always_inline functions:
Deciding on smaller functions:
Considering inline candidate void image::set(size_t, size_t, f_pixel, f_real).
Considering void image::set(size_t, size_t, f_pixel, f_real) with 15 insns
to be inlined into void set_test(image*, int, int, f_pixel&, double)
Estimated growth after inlined into all callees is -21 insns.
Estimated badness is -2147483642, frequency 1.00.
Not inlining into void set_test(image*, int, int, f_pixel&, double):function
not considered for inlining.
Deciding on functions called once:
Inlined 3 calls, eliminated 2 functions, 39 insns turned to 39 insns.
typedef unsigned int size_t;
typedef float f_real;
template struct triple
{
union {
T val[3];
struct {T x,y,z;};
struct {T r,g,b;};
};
T pad;
triple(const T v[3]) {for (int i = 0; i < 3; i++) val[i] = v[i];}
triple(T a_, T b_=0., T c_=0.) {x = a_; y = b_; z = c_;}
triple() {}
triple(const triple &t) {x=t.x;y=t.y;z=t.z;}
triple(const triple *t) {x=t->x;y=t->y;z=t->z;}
triple operator=(const triple &t) {x=t.x;y=t.y;z=t.z; return *this;}
} __attribute__((aligned));
typedef triple f_pixel;
struct image
{
f_pixel *buf;
f_real *depth_buf;
f_pixel minv, maxv;
size_t w, h;
image(size_t w, size_t h);
~image();
void write_to_bmp(const char *path);
inline void set(size_t x, size_t y, const f_pixel p, f_real depth) {
buf[y*w + x] = p;
depth_buf[y*w + x] = depth;
}
};
void set_test(image *target, int x, int y, f_pixel &c, double dist)
{
target->set(x,y,c,dist);
}
--
Summary: Small C++ function fails to inline with large negative
badness
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC build triplet: i386-apple-darwin8.10.1
GCC host triplet: i386-apple-darwin8.10.1
GCC target triplet: i386-apple-darwin8.10.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32572
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #8 from vmpn at hitechman dot com 2007-07-01 19:38 --- Created an attachment (id=13815) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13815&action=view) Test case fixed using forward declarations Thank you for your help. I think I now have a better understanding of what is going on. As far as GCC is concerned the overriding visit_each template function dealing with MyData does not exist when it makes its decision regarding visit_each(v, data, 0); call. I am attaching fixed (working with 4.1) text case that is more representative of the boost structure (to the best of my understanding). Also, I will be using it as a base for a follow up issue I ran into. I am also including couple of relevant links for better context to this issue for anyone else who might stumble on this entry: Two Phase looks ups and GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 http://groups.google.com/group/comp.std.c++/msg/6a53b35efe39fee3 http://gcc.gnu.org/gcc-3.4/changes.html http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html IMHO, the changes are mentioned as early as gcc 3.4 but they did not seem to fully kick in until gcc 4.x. Related boost email and change that I found: http://lists.boost.org/Archives/boost/2006/04/103989.php http://boost.cvs.sourceforge.net/boost/boost/boost/bind.hpp?r1=1.55&r2=1.56 Regards, Vladimir -- vmpn at hitechman dot com changed: What|Removed |Added Attachment #13808|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #9 from vmpn at hitechman dot com 2007-07-01 19:44 --- Created an attachment (id=13816) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13816&action=view) Test case that does not call MyData visit_each (as expected) Attaching a test case without forward declarations, that no longer calls MyData visit_each template function, as expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug target/15184] [4.0/4.1/4.2/4.3 Regression] Direct access to byte inside word not working with -march=pentiumpro
--- Comment #13 from rask at sygehus dot dk 2007-07-01 19:52 --- This has regressed quite badly. Here's what we get with -O2 -fomit-frame-pointer -m32 -march=pentium4: fl: movzbl %al, %eax # 21*zero_extendqisi2_movzbw[length = 3] movlx, %edx # 8 *movsi_1/1 [length = 6] xorb%dl, %dl# 27*movstrictqi_xor[length = 2] orl %edx, %eax # 10*iorsi_1/1 [length = 2] movl%eax, x # 11*movsi_1/2 [length = 5] ret # 25return_internal [length = 1] fu: movzbl %al, %eax # 22*zero_extendqisi2_movzbw[length = 3] sall$8, %eax# 8 *ashlsi3_1/1[length = 3] movlx, %edx # 9 *movsi_1/1 [length = 6] xorb%dh, %dh# 23*xorqi_ext_2[length = 2] orl %edx, %eax # 11*iorsi_1/1 [length = 2] movl%eax, x # 12*movsi_1/2 [length = 5] ret # 26return_internal [length = 1] gl: movzbl %al, %eax # 21*zero_extendqihi2_movzbl[length = 3] movzwl y, %edx # 8 *movhi_1/3 [length = 7] xorb%dl, %dl# 28*movstrictqi_xor[length = 2] orl %edx, %eax # 23*iorsi_1/1 [length = 2] movw%ax, y # 11*movhi_1/4 [length = 6] ret # 26return_internal [length = 1] gu: sall$8, %eax# 22*ashlsi3_1/1[length = 3] movzbl y, %edx # 23*zero_extendqihi2_movzbl[length = 7] orl %edx, %eax # 24*iorsi_1/1 [length = 2] movw%ax, y # 12*movhi_1/4 [length = 6] ret # 27return_internal [length = 1] Likewise for -march=pentium: fl: movlx, %edx # 8 *movsi_1/1 [length = 6] andl$255, %eax # 21*andsi_1/1 [length = 6] xorb%dl, %dl# 27*movstrictqi_xor[length = 2] orl %edx, %eax # 10*iorsi_1/1 [length = 2] movl%eax, x # 11*movsi_1/2 [length = 5] ret # 25return_internal [length = 1] fu: movlx, %edx # 9 *movsi_1/1 [length = 6] andl$255, %eax # 22*andsi_1/1 [length = 6] sall$8, %eax# 8 *ashlsi3_1/1[length = 3] xorb%dh, %dh# 23*xorqi_ext_2[length = 2] orl %edx, %eax # 11*iorsi_1/1 [length = 2] movl%eax, x # 12*movsi_1/2 [length = 5] ret # 26return_internal [length = 1] gl: movwy, %dx # 8 *movhi_1/3 [length = 7] andl$255, %eax # 22*andsi_1/1 [length = 6] xorb%dl, %dl# 29*movstrictqi_xor[length = 2] orl %edx, %eax # 24*iorsi_1/1 [length = 2] movw%ax, y # 11*movhi_1/4 [length = 6] ret # 27return_internal [length = 1] gu: movb%al, y+1# 12*movqi_1/7 [length = 5] ret # 24return_internal [length = 1] .ident "GCC: (GNU) 4.3.0 20070628 (experimental)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #10 from vmpn at hitechman dot com 2007-07-01 19:52 --- Created an attachment (id=13817) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13817&action=view) Test case that calls MyData visit_each without forward declaration If the MydData visit_each is moved into the bugsrus::internal name space GCC now finds it, even though it is not declared upfront. Regards, Vladimir -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c/32573] New: ice for legal code with -O3
I just tried to compile Suse Linux package physfs-1.0.1 with the GNU C compiler version 4.3 snapshot 20070629 The compiler said gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O3 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -D_REENTRANT -D_THREAD_SAFE -MT zip.lo -MD -MP -MF .deps/zip.Tpo -c zip.c -fPIC -DPIC -o .libs/zip.o zip.c: In function 'zip_find_end_of_central_dir': zip.c:418: internal compiler error: vector VEC(tree,base) index domain error, in build_classic_dist_vector_1 at tree-data-ref.c:2706 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: ice for legal code with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug c/32573] ice for legal code with -O3
--- Comment #1 from dcb314 at hotmail dot com 2007-07-01 21:07 --- Created an attachment (id=13818) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13818&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug c/32574] New: running out of memory during compiling
following .i files run the compiler out of memory during compile. appeared in the last 2 days. gcc -m32 -O2 -c storage.i (note the -m32 on amd64 seems necessary strangely) -- Summary: running out of memory during compiling Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32574
[Bug c/32574] running out of memory during compiling
--- Comment #1 from marcus at jet dot franken dot de 2007-07-01 21:28 --- Created an attachment (id=13819) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13819&action=view) storage.i gcc -m32 -O2 -c storage.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32574
[Bug c/32575] New: GCC 4.3.0 with -ftree-vrp miscompiles a single line of code in SQLite
A bug reported against SQLite appears to be a case of GCC 4.3.0 miscompiling a single line of code within SQLite. The problem only appears with -O2 or -Os. The problem goes away if we add the -fno-tree-vrp option. The original bug report can be found at http://www.sqlite.org/cvstrac/tktview?tn=2469 The line of code that is miscompiled is found in the source file named vdbe.c (version 1.635) on line 4309. 4308 for(j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32575] GCC 4.3.0 with -ftree-vrp miscompiles a single line of code in SQLite
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-01 22:16 --- Can you at least provide the preprocessed source of vdbe.c ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32571] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|ICE in set_ssa_val_to, at |[4.3 Regression] ICE in |tree-ssa-sccvn.c:1011 |set_ssa_val_to, at tree-ssa- ||sccvn.c:1011 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug c/32575] GCC 4.3.0 with -ftree-vrp miscompiles a single line of code in SQLite
--- Comment #2 from drh at sqlite dot org 2007-07-01 22:52 --- (In reply to comment #1) > Can you at least provide the preprocessed source of vdbe.c ? > Certainly. But before I do, I just noticed that I gave the wrong GCC version number in the bug report. The error is in GCC 4.2.0, not 4.3.0 as reported. I have not attempted to compile or test version 4.3.0. I have prepared a tarball containing the complete SQLite source code that can be compiled using a single command such as: gcc *.c -ldl -lpthread There is a README file in the tarball that describes this compilation step and which tells how to test (with a second command) whether or not the bug is present in your build. You can download the tarball from: http://www.sqlite.org/gccbug32575.tar.gz -- drh at sqlite dot org changed: What|Removed |Added CC||drh at sqlite dot org Component|tree-optimization |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug c/32575] GCC 4.2.0 with -ftree-vrp miscompiles a single line of code in SQLite
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Keywords||wrong-code Summary|GCC 4.3.0 with -ftree-vrp |GCC 4.2.0 with -ftree-vrp |miscompiles a single line of|miscompiles a single line of |code in SQLite |code in SQLite Version|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32576] New: [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011
svn revision: 126178 $ gcc adpcm.i -c -O1 In file included from adpcm.c:22: avcodec.h:2252: warning: 'ImgReSampleContext' is deprecated avcodec.h:2258: warning: 'ImgReSampleContext' is deprecated adpcm.c: In function 'adpcm_decode_frame': adpcm.c:854: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:101 1 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ gcc dsicinav.i -c -O1 In file included from dsicinav.c:28: avcodec.h:2252: warning: 'ImgReSampleContext' is deprecated avcodec.h:2258: warning: 'ImgReSampleContext' is deprecated dsicinav.c: In function 'cinvideo_decode_frame': dsicinav.c:199: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c: 1011 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
[Bug tree-optimization/32576] [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #1 from jojelino at gmail dot com 2007-07-01 23:04 --- Created an attachment (id=13820) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13820&action=view) preprocessed file #1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
[Bug tree-optimization/32576] [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #2 from jojelino at gmail dot com 2007-07-01 23:06 --- Created an attachment (id=13821) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13821&action=view) preprocessed file #2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
[Bug tree-optimization/32576] [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 Version|tree-ssa|4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #16 from zadeck at naturalbridge dot com 2007-07-02 00:19 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame Ian Lance Taylor wrote: >> Adding the stack pointer for asms is certainly the easiest thing to do. >> > > I don't know if that is enough. Maybe it is, maybe it isn't. You > can't delete the subtraction of the stack pointer if there is any use > of any local variable on the frame in any way. If an interrupt > occurs, and the stack pointer has not been decremented to be below the > local variables, then the local variables will be corrupted by the > interrupt handler. > > >> If you think that we want to view mem refs off the frame pointer as if >> they also touch the stack pointer, we can do that, but i would ask the >> question as to "why just in dce?" >> > > I meant it should be done when doing dataflow scanning, not in DCE. I > agree there is nothing special about DCE here. > ian, a set of specific questions: 1) Do i do this for both the frame_pointer and hard_frame_pointer? 2) There is currently code in the scanning for adding the stack pointer for call insns. This code marks that ref so that it is not considered when building log links for combine. a) Should I mark the stack pointer ref added for asm's this way? b) Should I mark the stack pointer refs put in for the mems in this way? Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug tree-optimization/32571] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-02 00:52 ---
Here is a more reduced testcase (without the inline-asm):
struct list_head {
struct list_head *next, *prev;
};
struct ib_fmr {
int *device;
struct list_head list;
};
static inline
struct mthca_fmr *to_mfmr(struct ib_fmr *ibmr)
{
const struct ib_fmr *__mptr = (ibmr);
return (struct mthca_fmr *)( (char *)__mptr );
}
void mthca_unmap_fmr(struct list_head *fmr_list)
{
struct ib_fmr *fmr;
if (mthca_is_memfree())
{
for (fmr =
({ const struct list_head *__mptr = ((fmr_list)->next); (struct ib_fmr *)(
(char *)__mptr - 8 );});
&fmr->list != (fmr_list);
fmr = ({ const struct list_head *__mptr = (fmr->list.next); (struct ib_fmr
*)( (char *)__mptr - 8);})
)
mthca_arbel_fmr_unmap(to_mfmr(fmr));
}
else
for (fmr =
({ const struct list_head *__mptr = ((fmr_list)->next); (struct ib_fmr *)(
(char *)__mptr - 8);});
&fmr->list != (fmr_list);
fmr = ({ const struct list_head *__mptr = (fmr->list.next); (struct ib_fmr
*)( (char *)__mptr - 8);})
)
mthca_tavor_fmr_unmap(to_mfmr(fmr));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-02 00:52:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #17 from ian at airs dot com 2007-07-02 01:45 --- Before I tackle the specific questions, let me try to explain the issue that I see. The issue is that during a function the value of the stack pointer register must always be at or below the local variables. An interrupt can occur at any time. On a processor which does not use a separate interrupt stack, the interrupt will push values on the stack and pass control to the kernel. The stack pointer must be set such that when an interrupt pushes values on the stack the local variables are not corrupted. Does that make sense? My hope is that understanding how this has to work will make clear what must be done. > 1) Do i do this for both the frame_pointer and hard_frame_pointer? I think this kind of dependency will only be relevant after the prologue has set up the stack. Therefore, it is only necessary to consider the hard frame pointer. > 2) There is currently code in the scanning for adding the stack pointer > for call insns. Sure, makes sense. > This code marks that ref so that it is not considered when building log > links for combine. That makes sense too. It doesn't make sense to build log links for the stack pointer for a call instruction; there isn't going to be anything combine. > a) Should I mark the stack pointer ref added for asm's this way? It's not obvious to me that asm's should have an implicit stack pointer ref. But maybe they should, I don't know. If asm's should have an explicit stack pointer ref, then regarding log links you should do whatever is simplest. asm's can not be combined anyhow. > b) Should I mark the stack pointer refs put in for the mems in this way? Yes, I would think so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #18 from zadeck at naturalbridge dot com 2007-07-02 02:45 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame ian at airs dot com wrote: > --- Comment #17 from ian at airs dot com 2007-07-02 01:45 --- > Before I tackle the specific questions, let me try to explain the issue that I > see. The issue is that during a function the value of the stack pointer > register must always be at or below the local variables. An interrupt can > occur at any time. On a processor which does not use a separate interrupt > stack, the interrupt will push values on the stack and pass control to the > kernel. The stack pointer must be set such that when an interrupt pushes > values on the stack the local variables are not corrupted. Does that make > sense? My hope is that understanding how this has to work will make clear > what > must be done. > > >> 1) Do i do this for both the frame_pointer and hard_frame_pointer? >> > > I think this kind of dependency will only be relevant after the prologue has > set up the stack. Therefore, it is only necessary to consider the hard frame > pointer. > > >> 2) There is currently code in the scanning for adding the stack pointer >> for call insns. >> > > Sure, makes sense. > > >> This code marks that ref so that it is not considered when building log >> links for combine. >> > > That makes sense too. It doesn't make sense to build log links for the stack > pointer for a call instruction; there isn't going to be anything combine. > > >> a) Should I mark the stack pointer ref added for asm's this way? >> > > It's not obvious to me that asm's should have an implicit stack pointer ref. > But maybe they should, I don't know. > > If asm's should have an explicit stack pointer ref, then regarding log links > you should do whatever is simplest. asm's can not be combined anyhow. > > >> b) Should I mark the stack pointer refs put in for the mems in this way? >> > > Yes, I would think so. > > > there is an inconsistency in your answers. Because if i am only marking the hard frame pointer and this is not set up until after reload, then the questions about the log_links and combine are moot since combine runs long before reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #19 from ian at airs dot com 2007-07-02 02:50 --- I don't see an inconsistency in my answers. If you mark local variables as having a reference to the stack pointer before combine, then you should handle log_links as appropriate. I am explicitly not telling you what to do. I am telling you what the problem is, and leaving the solution up to you. The correct solution is in the dataflow code, which I don't really know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug target/32577] New: [SH] static inline attribute causes stack overflow
When I use static inline attribute without any optimization as follows, stack
space is stacked. As a result, a stack overflow is caused. This problem came
from using gcc-4.2.0 for linux kernel which uses many inlines.
-compile options-
sh4-linux-gcc -S test.c
-testcase #1---
static inline __attribute__((always_inline)) int add(int x, int y)
{
return x + y;
}
int x, y;
main(int ac, char** av)
{
x = add(x, y);
return x;
}
-testcase #2---
static inline __attribute__((always_inline)) int add(int x, int y)
{
return x + y;
}
int x, y;
main(int ac, char** av)
{
x = add(x, y);
x = add(x, y);
return x;
}
-assembled code for testcase #1---
.global main
.type main, @function
main:
mov.l r14,@-r15
add #-16,r15
mov r15,r14
mov r14,r1
add #-48,r1
mov.l r4,@(52,r1)
...
-assembled code for testcase #2---
.global main
.type main, @function
main:
mov.l r14,@-r15
add #-24,r15 <-- stack grows down
mov r15,r14
mov r14,r1
add #-40,r1
mov.l r4,@(44,r1)
...
--
Summary: [SH] static inline attribute causes stack overflow
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saito at densan dot co dot jp
GCC build triplet: sh4-linux
GCC host triplet: sh4-linux
GCC target triplet: sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32577
[Bug fortran/32554] [4.2 Only] Bug in P formatting
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-07-02 04:11 --- Fixed on 4.3, will backport to 4.2 in about a week. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] Bug in P |[4.2 Only] Bug in P |formatting |formatting Target Milestone|4.3.0 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug tree-optimization/32571] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-02 04:35 --- Subject: Bug 32571 Author: dberlin Date: Mon Jul 2 04:35:37 2007 New Revision: 126186 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126186 Log: 2007-07-01 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/32571 * tree-ssa-sccvn.c (visit_use): Shortcut copies to avoid simplifying them. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #5 from patchapp at dberlin dot org 2007-07-02 06:12 --- Subject: Bug number PR30940 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02128.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug tree-optimization/32572] Small C++ function fails to inline with large negative badness
--- Comment #1 from astrange at ithinksw dot com 2007-07-02 06:18 --- This is a regression from Apple gcc 4.0: Considering void image::set(size_t, size_t, f_pixel, f_real) with 29 insns Estimated growth is -21 insns. Inlined into void set_test(image*, int, int, f_pixel&, double) which now has 32 insns. Inlined for a net change of -21 insns. and probably from earlier 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32572
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #20 from spark at gcc dot gnu dot org 2007-07-02 06:56 ---
We already put stack pointer in the exit block use set always.
However, after epilogue is generated, we see the sp restoration code:
1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
22 [--sp:SI]=bp:SI
23 bp:SI=sp:SI
24 {sp:SI=sp:SI-0x10;clobber flags:CC;clobber [scratch];}
25 NOTE_INSN_PROLOGUE_END
3 NOTE_INSN_FUNCTION_BEG
19 ax:SI=[bp:SI+0x8]
REG_EQUIV: [bp:SI+0x8]
6 [bp:SI-0x4]=ax:SI
21 dx:SI=bp:SI-0x4
18 ax:SI=0x5a
REG_EQUIV: 0x5a
9 {ax:SI=asm_operands;clobber fpsr:QI;clobber flags:QI;clobber [scratch];}
26 NOTE_INSN_EPILOGUE_BEG
27 {sp:SI=bp:SI+0x4;bp:SI=[bp:SI];clobber [scratch];}
28 return
i 29: barrier
20 NOTE_INSN_DELETED
Insn 27, which restores the sp for the caller, naturally writes to %sp,
and this makes %sp dead at insn 24.
I think the only correct solution is somehow to mark sp as used by insn 27,
or some similar effect. So, although this is a scanning problem,
we may want to consider adding a use of %sp inside 27 or just before insn 27,
*if* sp is indeed necessary. It is not possible for df to figure this out
alone, as its epilogue generation code that determines whether we want sp or
not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
