[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-10-11 06:13 --- Hmm, in 32bits it does this: Won't transform loop. Optimal transform is the identity transform While in 64bits, it tries to transform it. It really does not matter which order for the testcase in comment #18 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug libstdc++/33734] New: iconv_t must not be assumed to be a pointer
There are three instances of reinterpret_casticonv_t(-1) in libstdc++-v3/include/ext/codecvt_specializations.h, all of which are invalid if iconv_t does not resolve to a pointer (on NetWare it is a plain int, but obviously it could also be a compound type). /home/jbeulich/build/gcc/4.2.1-netware/./gcc/xgcc -shared-libgcc -B/home/jbeulich/build/gcc/4.2.1-netware/./gcc -nostdinc++ -L/home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/src -L/home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/src/.libs -B/usr/local/i686-novell-netware/bin/ -B/usr/local/i686-novell-netware/lib/ -isystem /usr/local/i686-novell-netware/sys-include -isystem /usr/local/i686-novell-netware/include -L/home/jbeulich/build/gcc/4.2.1-netware/./ld -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -I/home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/i686-novell-netware -I/home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include -I/home/jbeulich/cpp/gcc/4.2.1/libstdc++-v3/libsupc++ -O2 -g /home/jbeulich/cpp/gcc/4.2.1/libstdc++-v3/include/precompiled/extc++.h -o i686-novell-netware/bits/extc++.h.gch/O2g.gch In file included from /home/jbeulich/cpp/gcc/4.2.1/libstdc++-v3/include/precompiled/extc++.h:39: /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'bool __gnu_cxx::encoding_state::good() const': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:131: error: invalid cast from type 'int' to type 'iconv_t' /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'void __gnu_cxx::encoding_state::init()': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:169: error: invalid cast from type 'int' to type 'iconv_t' /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'void __gnu_cxx::encoding_state::destroy()': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:202: error: invalid cast from type 'int' to type 'iconv_t' make[2]: *** [i686-novell-netware/bits/extc++.h.gch/O2g.gch] Error 1 make[2]: Leaving directory `/home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include' Making all in include In file included from /home/jbeulich/cpp/gcc/4.2.1/libstdc++-v3/include/precompiled/extc++.h:39: /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'bool __gnu_cxx::encoding_state::good() const': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:131: error: invalid cast from type 'int' to type 'iconv_t' /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'void __gnu_cxx::encoding_state::init()': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:169: error: invalid cast from type 'int' to type 'iconv_t' /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'void __gnu_cxx::encoding_state::destroy()': /home/jbeulich/build/gcc/4.2.1-netware/i686-novell-netware/libstdc++-v3/include/ext/codecvt_specializations.h:202: error: invalid cast from type 'int' to type 'iconv_t' make[4]: *** [i686-novell-netware/bits/extc++.h.gch/O2g.gch] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 -- Summary: iconv_t must not be assumed to be a pointer Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbeulich at novell dot com GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: i686-novell-netware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug fortran/33727] Segfault with ugly string array constructor
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-11 07:26 --- Confirmed. Tobias, You should have received the fix. Cheers Paul Index: gcc/fortran/trans-array.c === *** gcc/fortran/trans-array.c (révision 129121) --- gcc/fortran/trans-array.c (copie de travail) *** get_array_ctor_var_strlen (gfc_expr * ex *** 1340,1346 case REF_SUBSTRING: if (ref-u.ss.start-expr_type != EXPR_CONSTANT ! || ref-u.ss.start-expr_type != EXPR_CONSTANT) break; mpz_init_set_ui (char_len, 1); mpz_add (char_len, char_len, ref-u.ss.end-value.integer); --- 1340,1346 case REF_SUBSTRING: if (ref-u.ss.start-expr_type != EXPR_CONSTANT ! || ref-u.ss.end-expr_type != EXPR_CONSTANT) break; mpz_init_set_ui (char_len, 1); mpz_add (char_len, char_len, ref-u.ss.end-value.integer); -- pault 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-10-11 07:26:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #4 from pault at gcc dot gnu dot org 2007-10-11 07:29 --- (In reply to comment #3) The failure from #2 is now PR 33727. Tobi, Why don't you fix them both at once? :-) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug c/33726] [4.3 Regression] Type checking error with address-of and volatile and arrays
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-11 08:11 --- Subject: Bug 33726 Author: rguenth Date: Thu Oct 11 08:11:18 2007 New Revision: 129227 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129227 Log: 2007-10-11 Richard Guenther [EMAIL PROTECTED] PR c/33726 * c-typeck.c (build_array_ref): Do not strip qualifiers from the array element type. * gcc.dg/pr33726.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr33726.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33726
[Bug middle-end/33724] [4.3 Regression] Type checking error with address-of and ref-all pointer type
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-11 08:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33724
[Bug middle-end/33724] [4.3 Regression] Type checking error with address-of and ref-all pointer type
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-11 08:58 --- Subject: Bug 33724 Author: rguenth Date: Thu Oct 11 08:58:28 2007 New Revision: 129228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129228 Log: 2007-10-11 Richard Guenther [EMAIL PROTECTED] PR middle-end/33724 * tree-cfg.c (one_pointer_to_useless_type_conversion_p): New function. (verify_gimple_expr): Use it to verify pointer-to types for ADDR_EXPRs. * gcc.dg/pr33724.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr33724.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33724
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-11 09:38 --- After applying the patch and the one to PR33727 (thanks Paul!-), the first test fails at runtime: At line 6 of file pr32703_1.f90 Fortran runtime error: Different CHARACTER lengths (1/2) in array constructor but the following code program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = (/y(1:len(trim(y))), x(1:len(trim(x)))/) ! causes segfault print *, ', z(1), ' ', z(2), ' end program array_char gives [karma] f90/bug% gfc -fbounds-check pr33727_bad.f90 [karma] f90/bug% a.out 'cd' 'a' I am expecting this test to fail at runtime and the other one. Am I missing something. I have also noticed something strange with the following valid(?) code: program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = z = (/y(1:len(trim(x))), x(1:len(trim(x)))/) print *, ', z(1), ' ', z(2), ' end program array_char which gives 'c' 'a' while I am expecting 'c ' 'a ' Looks like another bug, should I fill a new PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
--- Comment #12 from jakub at gcc dot gnu dot org 2007-10-11 09:41 ---
The problem is that D.1556 (the var that hasn't been renamed or with the patch
can't be looked up) has been deleted.
*.phiprop has:
long unsigned intD.4 D.1556;
...
D.1554_11 = (long unsigned intD.4) dimD.1539_4(D);
D.1556_12 = D.1554_11 * 4;
...
D.1561_23 = D.1556_12 /[ex] 4;
D.1562_24 = (*newcentroid.1D.1559_22)[0]{lb: 0 sz: D.1561_23 * 4};
then FRE does:
Replaced D.1556_12 /[ex] 4 with D.1554_11 in D.1561_23 = D.1556_12 /[ex] 4;
long unsigned intD.4 D.1556;
...
D.1554_11 = (long unsigned intD.4) dimD.1539_4(D);
D.1556_12 = D.1554_11 * 4;
...
newcentroid.1D.1559_22 = (intD.0[3][0:D.1553] *) D.1560_21;
D.1561_23 = D.1554_11;
D.1562_24 = (*newcentroid.1D.1559_22)[0]{lb: 0 sz: D.1561_23 * 4};
and as D.1556 is unused, it is DCEd in dce2 pass. But D.1556 (and D.1555) is
still present in TYPE_SIZE{,_UNIT} of the VLA type, so when vectorizer
regimplifies it, it adds back code to compute its size, but that assumes
D.1556 has the correct value.
Not sure what could be done here to fix this. The easiest solution is not to
vectorize when VLA types are involved. In any case it means that debuginfo
will
be incomplete if its size variable has been DCEd.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug c++/31441] [4.3 regression] ICE with variadic template and specialization
--- Comment #3 from pcarlini at suse dot de 2007-10-11 09:44 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31441
[Bug c++/33461] [4.3 regression] ICE with invalid specialization involving parameter packs
--- Comment #4 from pcarlini at suse dot de 2007-10-11 09:45 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33461
[Bug tree-optimization/33735] [4.3 Regression] verify_stmts failed: missing PHI def
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-11 09:51 --- Created an attachment (id=14338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14338action=view) testcase (unreduced) Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33735
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #31 from dominiq at lps dot ens dot fr 2007-10-11 10:17 --- Works as advertised without regression so far (PPC Darwin, 32 bit mode close to complete), but for the codelets in #30. I wonder if the code in #28 is valid: the line(s) merge(transfer(string,x,len(string)), string, .true.) does not seems to obey: 13.7.75 MERGE (TSOURCE, FSOURCE, MASK) ... FSOURCE shall be of the same type and type parameters as TSOURCE. If I am not mistaken transfer(string,x,len(string)) is an array of characters of rank one, size len(string), of character(1), while string is a scalar character(20) (13.7.121 TRANSFER (SOURCE, MOLD [, SIZE]) ... Case (iii): If SIZE is present, the result is an array of rank one and size SIZE.). The patched gfortran, Intel, and g95 accept the code and give the same result; xlf accept the code, but gives some garbage in the first and fourth lines of the output; Portland Group compiler rejects the code with: PGF90-S-0074-Illegal number or type of arguments to merge - keyword argument fsource (pr31608_4.f90: 16) Should I fill another PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-11 10:21:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-11 10:26 --- It cannot be a coumpounded type because of the definition of iconv_open which says it returns -1 for a falure. Otherwise iconv_open() returns (iconv_t)-1 and sets errno to indicate the error. From http://www.opengroup.org/onlinepubs/007908799/xsh/iconv_open.html Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #2 from pcarlini at suse dot de 2007-10-11 10:31 --- Indeed, I'm just changing to cast notation per that document. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
Re: [Bug target/33730] [4.2 regression] Illegal instruction with build/genmddeps with PPC405 build on powerpc
On 11 Oct 2007 10:28:03 -, tbm at cyrius dot com [EMAIL PROTECTED] wrote: So it's just a coincidence that 4.1 and 4.3 bootstrap? Yes. You should look at what instruction is being executed to be sure but this is just the normal trying to boostrap using --with-cpu when you really don't have that CPU (or a superset of that CPU instructions). Use gdb to find out for sure. -- Pinski
[Bug target/33730] [4.2 regression] Illegal instruction with build/genmddeps with PPC405 build on powerpc
--- Comment #3 from pinskia at gmail dot com 2007-10-11 10:40 --- Subject: Re: [4.2 regression] Illegal instruction with build/genmddeps with PPC405 build on powerpc On 11 Oct 2007 10:28:03 -, tbm at cyrius dot com [EMAIL PROTECTED] wrote: So it's just a coincidence that 4.1 and 4.3 bootstrap? Yes. You should look at what instruction is being executed to be sure but this is just the normal trying to boostrap using --with-cpu when you really don't have that CPU (or a superset of that CPU instructions). Use gdb to find out for sure. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33730
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
--- Comment #13 from irar at il dot ibm dot com 2007-10-11 10:43 ---
Maybe we can fix DCE not to eliminate such vars?
Or somehow fix split_constant_offset?
The following patch changes the base from
(int[0:D.1553] *) newcentroid.1_22 + (long unsigned int) dim_4(D) * 8
to (int[0:D.1553] *) D.1560_21 + (long unsigned int) dim_4(D) * 8
and, hence, there is no need in the size of newcentroid.1_22:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 128902)
+++ tree-data-ref.c (working copy)
@@ -579,8 +579,10 @@ split_constant_offset (tree exp, tree *v
{
split_constant_offset (def_stmt_rhs, var0, off0);
var0 = fold_convert (type, var0);
- *var = var0;
- *off = off0;
+ split_constant_offset (var0, var2, off2);
+ *var = var2;
+ *off = fold_build2 (PLUS_EXPR, TREE_TYPE (off2),
+off0, off2);
return;
}
}
Maybe we can check if the base is of the VLA type and then try to further split
it as above (and not to vectorize if we fail)?
Thanks,
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Priority|P1 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 10:45 --- Subject: Re: Diagnose different string lengths in array constructors at run time dominiq at lps dot ens dot fr wrote: program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = (/y(1:len(trim(y))), x(1:len(trim(x)))/) ! causes segfault print *, ', z(1), ' ', z(2), ' end program array_char gives [karma] f90/bug% gfc -fbounds-check pr33727_bad.f90 [karma] f90/bug% a.out 'cd' 'a' I am expecting this test to fail at runtime and the other one. Am I missing something. This is weird, and can't really be (well, in a hypothetical world where only the bounds check goes wrong), as the whole array has only a single string length, so I would expect it to either print two length one strings or two length two strings, not one lenghth one string and one length two string. I have also noticed something strange with the following valid(?) code: program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = z = (/y(1:len(trim(x))), x(1:len(trim(x)))/) print *, ', z(1), ' ', z(2), ' end program array_char which gives 'c' 'a' while I am expecting 'c ' 'a ' Looks like another bug, should I fill a new PR? Yes. This looks related to the previous one, again the string length seems to be taken from the wrong place. Are these with or without Paul's patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #3 from paolo at gcc dot gnu dot org 2007-10-11 10:50 --- Subject: Bug 33734 Author: paolo Date: Thu Oct 11 10:50:09 2007 New Revision: 129232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129232 Log: 2007-10-11 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33734 * include/ext/codecvt_specializations.h (encoding_state::good, init, destroy): Use cast notation instead of reinterpret_cast. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/codecvt_specializations.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #4 from pcarlini at suse dot de 2007-10-11 10:52 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #1 from pault at gcc dot gnu dot org 2007-10-11 10:53 --- This fixes it. Index: gcc/fortran/simplify.c === *** gcc/fortran/simplify.c (révision 129121) --- gcc/fortran/simplify.c (copie de travail) *** gfc_simplify_transfer (gfc_expr *source, *** 4011,4016 --- 4011,4020 || !gfc_is_constant_expr (size)) return NULL; + if (source-expr_type != EXPR_ARRAY +source-expr_type != EXPR_CONSTANT) + return NULL; + /* Calculate the size of the source. */ if (source-expr_type == EXPR_ARRAY gfc_array_size (source, tmp) == FAILURE) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-11 10:53:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug rtl-optimization/24319] [4.0/4.1/4.2/4.3 regression] amd64 register spill error with -fschedule-insns
--- Comment #9 from ubizjak at gmail dot com 2007-10-11 10:32 ---
(In reply to comment #3)
int bar (char *s)
{
return foo (strlen(s));
}
The testcase above fails with AREG spill failure. The testcase below fails with
DIREG spill failure:
int bar (int x, long l);
int foo (char *s)
{
return bar (1, strlen(s));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-10-11 11:14
---
Revision 128957 causes this regression.
There is a suspect non-documented hunk in the commit:
* reload1.c (compute_use_by_pseudos): Change DF_RA_LIVE
usage to DF_LIVE usage.
--- trunk/gcc/reload1.c 2007/10/02 12:47:13 128956
+++ trunk/gcc/reload1.c 2007/10/02 13:10:07 128957
@@ -548,7 +548,7 @@
if (r 0)
{
/* reload_combine uses the information from
-DF_RA_LIVE_IN (BASIC_BLOCK), which might still
+DF_LIVE_IN (BASIC_BLOCK), which might still
contain registers that have not actually been allocated
since they have an equivalence. */
gcc_assert (reload_completed);
@@ -1158,10 +1158,7 @@
if (! frame_pointer_needed)
FOR_EACH_BB (bb)
- {
- bitmap_clear_bit (df_get_live_in (bb), HARD_FRAME_POINTER_REGNUM);
- bitmap_clear_bit (df_get_live_top (bb), HARD_FRAME_POINTER_REGNUM);
- }
+ bitmap_clear_bit (df_get_live_in (bb), HARD_FRAME_POINTER_REGNUM);
/* Come here (with failure set nonzero) if we can't get enough spill
regs. */
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #14 from zadeck at naturalbridge dot com 2007-10-11 11:43
---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
ebotcazou at gcc dot gnu dot org wrote:
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-10-11 11:14
---
Revision 128957 causes this regression.
There is a suspect non-documented hunk in the commit:
* reload1.c (compute_use_by_pseudos): Change DF_RA_LIVE
usage to DF_LIVE usage.
--- trunk/gcc/reload1.c 2007/10/02 12:47:13 128956
+++ trunk/gcc/reload1.c 2007/10/02 13:10:07 128957
@@ -548,7 +548,7 @@
if (r 0)
{
/* reload_combine uses the information from
-DF_RA_LIVE_IN (BASIC_BLOCK), which might still
+DF_LIVE_IN (BASIC_BLOCK), which might still
contain registers that have not actually been allocated
since they have an equivalence. */
gcc_assert (reload_completed);
@@ -1158,10 +1158,7 @@
if (! frame_pointer_needed)
FOR_EACH_BB (bb)
- {
- bitmap_clear_bit (df_get_live_in (bb), HARD_FRAME_POINTER_REGNUM);
- bitmap_clear_bit (df_get_live_top (bb), HARD_FRAME_POINTER_REGNUM);
- }
+ bitmap_clear_bit (df_get_live_in (bb), HARD_FRAME_POINTER_REGNUM);
/* Come here (with failure set nonzero) if we can't get enough spill
regs. */
That is fine, there are no top sets anymore.
the problem is the code that builds the reload insn chain. the new code
uses the cfg and does not add the label or the jump table that lives
between basic blocks to the chain. I will post a patch as soon as my
tests finish.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-11 11:57 --- The original issue seems to no longer trigger with the testcase, the missed combining is fixed with a patch I have. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-09 15:43:14 |2007-10-11 11:57:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug c++/32882] Mismatched types with pointer to member functions and -fstrict-aliasing
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-11 11:40 --- This was fixed by 2007-08-20 Richard Guenther [EMAIL PROTECTED] PR c++/22369 PR c++/22451 * call.c (build_new_method_call): Convert initializer to the basetype. * init.c (build_aggr_init): Do not fiddle with types. (build_vec_delete_1): Use correct type for POINTER_PLUS_EXPR. * except.c (build_throw): Do not drop qualifiers for the pointer type. * typeck.c (get_member_function_from_ptrfunc): Do not fiddle with types, instead convert. (build_ptrmemfunc1): Convert to the target type for initialization. (gfc_trans_allocate): Convert result to target type. * cp-objcp-common.c (cxx_get_alias_set): Pointers to pointer-to-member structures shall have alias set zero as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-11 12:10 ---
Also
because in fold_binary where we handle this kind of stuff we have
if (!offset0 || !offset1
|| TREE_TYPE (offset0) == TREE_TYPE (offset1))
{
...
is no longer true, we compare offsets in signed sizetype.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug tree-optimization/25736] ACATS tests c45342a, c52102b and c52102d fail with struct aliasing enabled
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-11 12:19 --- With 2007-06-21 Eric Botcazou [EMAIL PROTECTED] PR tree-optimization/25737 * misc.c (gnat_post_options): Do not force flag_tree_salias to 0. this has to be no longer true. And indeed those tests pass on x86_64. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25736
[Bug tree-optimization/25738] ACATS test cc50a01 fails with struct aliasing enabled
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-11 12:20 --- With 2007-06-21 Eric Botcazou [EMAIL PROTECTED] PR tree-optimization/25737 * misc.c (gnat_post_options): Do not force flag_tree_salias to 0. this has to be no longer true. Indeed, the test now passes on x86_64. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25738
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-10-11 12:24 --- That is fine, there are no top sets anymore. Thanks for the explanation, please fix the ChangeLog though. the problem is the code that builds the reload insn chain. the new code uses the cfg and does not add the label or the jump table that lives between basic blocks to the chain. I will post a patch as soon as my tests finish. OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug tree-optimization/33645] [4.3 Regression] undefined static variable in vortex for -fno-unit-at-a-time
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-11 11:58:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33645
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #7 from dominiq at lps dot ens dot fr 2007-10-11 12:34 --- This is weird, and can't really be (well, in a hypothetical world where only the bounds check goes wrong), as the whole array has only a single string length, so I would expect it to either print two length one strings or two length two strings, not one lenghth one string and one length two string. I am not sure to understand the above. Each element of z is a string of length 2, y(1:len(trim(y))) is also of length 2, while x(1:len(trim(x))) is of length one, so the constructor should give an error. Are these with or without Paul's patch? with otherwise I got an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
--- Comment #14 from irar at il dot ibm dot com 2007-10-11 12:34 --- BTW, without this patch http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02122.html there is no ICE and the loop gets vectorized. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||Jan dot Sjodin at amd dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug tree-optimization/25736] ACATS tests c45342a, c52102b and c52102d fail with struct aliasing enabled
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-11 12:50 --- Sorry for overlooking the PR... Do not hesitate to CC me for Ada related PRs. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25736
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-11 12:53:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #16 from zadeck at naturalbridge dot com 2007-10-11 12:40 --- Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer ebotcazou at gcc dot gnu dot org wrote: --- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-10-11 12:24 --- That is fine, there are no top sets anymore. Thanks for the explanation, please fix the ChangeLog though. I will, sorry for the oversight. the problem is the code that builds the reload insn chain. the new code uses the cfg and does not add the label or the jump table that lives between basic blocks to the chain. I will post a patch as soon as my tests finish. OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug c++/33736] New: error: integer constant is too large for �long� type incorrect for C++0x
Integer constants that don't fit into a long cause a pedwarn in GCC as of the 20070907 snapshot (this has been the behavior for a while). However this is incorrect for C++0x which does (at least in the WG draft) allows for something to be placed in a long long or unsigned long long if it doesn't fit into anything smaller (section 2.13.1.2 + table 5). However GCC pedwarns even with -std=c++0x or -std=gnu++0x (On x86-64 or other 64-bit machines this behavior can be observed while compiling with -m32). $ g++-4.3-20070907 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907 --enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20070907 (experimental) (GCC) -- Summary: error: integer constant is too large for long type incorrect for C++0x Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lloyd at randombit dot net 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=33736
[Bug middle-end/33737] New: [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94-1 -6651
/usr/lib/gcc/i586-suse-linux/4.3.0/cc1 -fpreprocessed gtksettings.i -quiet -dumpbase gtksettings.c -march=i586 -mtune=i686 -auxbase-strip .libs/gtksettings.o -O2 -Wall -version -fmessage-length=0 -fstack-protector -fno-strict-aliasing -fPIC -o gtksettings.s GNU C (SUSE Linux) version 4.3.0 20071011 (experimental) [trunk revision 129228] (i586-suse-linux) compiled by GNU C version 4.3.0 20071011 (experimental) [trunk revision 129228], GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e79c8f227c39ee1fb1e2b389f7eb1999 gtksettings.c: In function 'gtk_settings_class_intern_init': gtksettings.c:151: error: verify_flow_info: Wrong probability of edge 94-1 -6651 gtksettings.c:151: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. -- Summary: [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94-1 -6651 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, ice-checking Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
[Bug middle-end/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94-1 -6651
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-11 13:34 --- Created an attachment (id=14339) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14339action=view) testcase (unreduced) Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
[Bug c++/33677] Member with same name as class
--- Comment #2 from s__nakayama at infoseek dot jp 2007-10-11 13:50 --- (In reply to comment #1) This code is invalid, and we should reject both of them. Why do you think that this is invalid? Member with same name as class have restrictions(ISO/IEC 14882:2003 9.2 p13/13a). But, I can not find the restriction that this is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33677
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-11 13:53 --- The patch fixes the tests but resurect an old ICE on (was pr18769): program gfcbug21 implicit none type t integer :: i end type t type (t), parameter :: u = t (1) integer, parameter :: idx_list(1) = (/ 1 /) ! gfortran dies here: integer :: j(1) = transfer (u, idx_list) print *, j end program gfcbug21 pr18769.f90: In function 'MAIN__': pr18769.f90:1: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:3816 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 14:04 --- Subject: Re: Diagnose different string lengths in array constructors at run time dominiq at lps dot ens dot fr wrote: --- Comment #7 from dominiq at lps dot ens dot fr 2007-10-11 12:34 --- This is weird, and can't really be (well, in a hypothetical world where only the bounds check goes wrong), as the whole array has only a single string length, so I would expect it to either print two length one strings or two length two strings, not one lenghth one string and one length two string. I am not sure to understand the above. Each element of z is a string of length 2, y(1:len(trim(y))) is also of length 2, while x(1:len(trim(x))) is of length one, so the constructor should give an error. Yes, I agree with the latter. What I menat is the following: after the data has been added to the array, the compiler should use the string length of the array, so if you do CHARACTER*10 z z = (/ something /) print *, z all printed strings should be length 10, no the contents of the constructor. Are these with or without Paul's patch? with otherwise I got an ICE. ok, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 14:09 --- Subject: Re: Diagnose different string lengths in array constructors at run time Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: all printed strings should be length 10, no the contents of the constructor. ^^ read: independent of -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-11 14:10 --- ... What I menat is the following: after the data has been added to the array, the compiler should use the string length of the array, ... I agree, this is why I posted the second code with y(1:len(trim(x))), because the result seems wrong to me. My question was is this related to this PR or a different one? If the answer is yes to the latter, then we probably need to open a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-11 14:14 --- I don't know if this the right fix, but --- /opt/gcc/_gcc-clean/gcc/fortran/simplify.c 2007-10-07 09:37:46.0 +0200 +++ /opt/gcc/gcc-4.3-work/gcc/fortran/simplify.c2007-10-11 16:05:57.0 +0200 @@ -4011,6 +4011,11 @@ || !gfc_is_constant_expr (size)) return NULL; + if (source-expr_type != EXPR_ARRAY + source-expr_type != EXPR_STRUCTURE + source-expr_type != EXPR_CONSTANT) +return NULL; + /* Calculate the size of the source. */ if (source-expr_type == EXPR_ARRAY gfc_array_size (source, tmp) == FAILURE) fixes this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #11 from tobi at gcc dot gnu dot org 2007-10-11 14:14 --- I'm adding Paul to the CC list, as perhaps he immediately knows what's happening (Paul, see comment #5). Otherwise I will investigate tomorrow evening or Saturday. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug middle-end/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94-1 -6651
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-11 14:22 --- Created an attachment (id=14340) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14340action=view) reduced testcase The testcase depends on the exact (or minimal) amount of branching, so I suppose this might be an overflow issue somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
[Bug middle-end/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94-1 -6651
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-11 14:23 --- The reduced testcase also fails with x86_64, plain -O2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i?86-*-*|x86_64-*-*, i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures
--- Comment #2 from pault at gcc dot gnu dot org 2007-10-11 14:55 ---
(In reply to comment #1)
Ah this bug was present before my patch for PR30746. I can see from my
notes that I was fixated on PR30746, whilst not altering the behaviour of
gfortran in any other way., whether right or wrong. Bah!
With the patch below, we get the correct behaviour for
MODULE m
REAL :: x(3) = (/ 1.5, 2.5, 3.5 /)
CONTAINS
SUBROUTINE s
if (x(2) .eq. 2.5) call abort ()
CONTAINS
FUNCTION x(n, m)
integer, optional :: m
if (present(m)) then
x = REAL(n)**m
else
x = 0.0
end if
END FUNCTION
END SUBROUTINE s
END MODULE m
use m
call s
end
Paul
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (révision 129121)
--- gcc/fortran/resolve.c (copie de travail)
*** check_host_association (gfc_expr *e)
*** 3989,3999
return retval;
if (gfc_current_ns-parent
-gfc_current_ns-parent-parent
old_sym-ns != gfc_current_ns)
{
! gfc_find_symbol (old_sym-name, gfc_current_ns-parent, 1, sym);
! if (sym old_sym != sym sym-attr.flavor == FL_PROCEDURE)
{
temp_locus = gfc_current_locus;
gfc_current_locus = e-where;
--- 3989,4000
return retval;
if (gfc_current_ns-parent
old_sym-ns != gfc_current_ns)
{
! gfc_find_symbol (old_sym-name, gfc_current_ns, 1, sym);
! if (sym old_sym != sym
! sym-attr.flavor == FL_PROCEDURE
! sym-attr.contained)
{
temp_locus = gfc_current_locus;
gfc_current_locus = e-where;
Index: D:/svn/trunk/gcc/testsuite/gfortran.dg/host_assoc_function_1.f90
===
*** D:/svn/trunk/gcc/testsuite/gfortran.dg/host_assoc_function_1.f90
(révisio
n 129121)
--- D:/svn/trunk/gcc/testsuite/gfortran.dg/host_assoc_function_1.f90(copie
d
e travail)
*** MODULE m
*** 19,26
end interface
CONTAINS
SUBROUTINE s
! if (x(2) .ne. 2.5) call abort ()
! if (z(3) .ne. real (3)**3) call abort ()
CALL inner
CONTAINS
SUBROUTINE inner
--- 19,26
end interface
CONTAINS
SUBROUTINE s
! if (x(2, 3) .ne. real (2)**3) call abort ()
! if (z(3, 3) .ne. real (3)**3) call abort ()
CALL inner
CONTAINS
SUBROUTINE inner
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33233
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #5 from paolo at gcc dot gnu dot org 2007-10-11 15:23 --- Subject: Bug 33734 Author: paolo Date: Thu Oct 11 15:23:11 2007 New Revision: 129235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129235 Log: 2007-10-11 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33734 * include/ext/codecvt_specializations.h (encoding_state::good, init, destroy): Use cast notation instead of reinterpret_cast. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/ext/codecvt_specializations.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug libstdc++/33734] iconv_t must not be assumed to be a pointer
--- Comment #6 from pcarlini at suse dot de 2007-10-11 15:24 --- Fixed for 4.2.3 too. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|4.3.0 |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33734
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #17 from zadeck at naturalbridge dot com 2007-10-11 16:21
---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* global.c (build_insn_chain): Include insn that occur between
basic blocks.
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* gcc.c-torture/gcc.dg/torture/pr33676.c: New.
When I rewrote this code to use backward scanning rather than forwards
scanning, I converted it to properly use the cfg, since it is generally
considered outmoded to just scan the insns.
However, the reload_insn_chain actually needs the insns that appear
between basic blocks, in particular the labels in front of branch
tables. I added code here to check for insns that may be in front of a
basic block after scanning that block.
There are a lot of ways that I could have done this, for instance, I
could have just written in terms of the PREV_INSN as the old code was.
I think that in doing it the way that i have done it, it is obvious what
needs to be done if someone really does get rid of the branch tables
between the blocks.
This has been bootstrapped and regression tested on x86-{64,32} ppc-32,
and ia-64. However it is not clear to me how many platforms use this
kind of table branch. The bug appears to only be on the -march=i586, so
the reviewers may wish to comment on my choice of dg options on the test.
Ok to commit?
Kenny
Index: testsuite/gcc.dg/torture/pr33676.c
===
--- testsuite/gcc.dg/torture/pr33676.c (revision 0)
+++ testsuite/gcc.dg/torture/pr33676.c (revision 0)
@@ -0,0 +1,53 @@
+/* { dg-do run } */
+/* { dg-options -march=i586 -fomit-frame-pointer { target { { i?86-*-*
x86_64-*-* } ilp32 } } } */
+
+// Small testcase, compile with -march=i586 -O0 -fomit-frame-pointer:
+
+__attribute__((noreturn,noinline)) void abrt (const char *fi, const char *fu)
+{
+ __builtin_abort ();
+}
+
+__attribute__((noinline)) int f (int k)
+{
+ return k;
+}
+
+__attribute__((noinline)) int g (int t, int k)
+{
+ int b;
+
+ switch (t)
+{
+case 0:
+ abrt (__FILE__, __FUNCTION__);
+
+case 1:
+ b = f (k);
+ break;
+
+case 2:
+ b = f (k);
+ break;
+
+case 3:
+ b = f (k);
+ break;
+
+case 4:
+ b = f (k);
+ break;
+
+default:
+ abrt (__FILE__, __FUNCTION__);
+}
+
+ return b;
+}
+
+int main (void)
+{
+ if (g (3, 1337) != 1337)
+ abrt (__FILE__, __FUNCTION__);
+ return 0;
+}
Index: global.c
===
--- global.c(revision 129224)
+++ global.c(working copy)
@@ -1575,6 +1575,37 @@ build_insn_chain (void)
}
}
}
+
+ /* FIXME!! The following code is a disaster. Reload needs to see the
+labels and jump tables that are just hanging out in between
+the basic blocks. See pr33676. */
+
+ insn = BB_HEAD (bb);
+
+ /* Skip over the barriers and cruft. */
+ while (insn (BARRIER_P (insn) || NOTE_P (insn) || BLOCK_FOR_INSN
(insn) == bb))
+ insn = PREV_INSN (insn);
+
+ /* Look for labels and jump tables. */
+ while (insn)
+ {
+ if (!NOTE_P (insn) !BARRIER_P (insn))
+ {
+ if (BLOCK_FOR_INSN (insn))
+ break;
+
+ c = new_insn_chain ();
+ c-next = next;
+ next = c;
+ *p = c;
+ p = c-prev;
+
+ c-insn = insn;
+ c-block = bb-index;
+ bitmap_copy (c-live_throughout, live_relevant_regs);
+ }
+ insn = PREV_INSN (insn);
+ }
}
for (i = 0; i (unsigned int)max_regno; i++)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-11 16:27 ---
If cprop_jump changes a conditional jump into unconditional, then it forgets
to add a BARRIER after it. When not in cfglayout mode that's enough, but
in cfglayout mode it is uglier, though I haven't found a cfg hook which would
do what cprop_jump needs.
--- gcc/gcse.c.jj 2007-10-03 21:33:54.0 +0200
+++ gcc/gcse.c 2007-10-11 18:13:45.0 +0200
@@ -2853,6 +2853,14 @@ cprop_jump (basic_block bb, rtx setcc, r
/* Remove REG_EQUAL note after simplification. */
if (note_src)
remove_note (jump, note);
+
+ if (any_uncondjump_p (jump)
+ || (returnjump_p (jump) !any_condjump_p (jump)))
+ {
+ rtx barrier = emit_barrier_after (jump);
+ if (current_ir_type () == IR_RTL_CFGLAYOUT)
+ bb-il.rtl-footer = unlink_insn_chain (barrier, barrier);
+ }
}
#ifdef HAVE_cc0
is ugly, but fixes this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #4 from pault at gcc dot gnu dot org 2007-10-11 17:17 --- (In reply to comment #3) Dominique, Oui, c'est bon! Merci. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-11 17:30 --- Works as expected: now gfortran agrees with xlf. Regtest almost finished in 32 bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33233
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-11 17:31 --- Oui, c'est bon! Merci. Question: is this the only omission? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug c++/33738] New: -Wtype-limits misses a warning when comparing enums
This was found on GCC 4.2.1. In this test case, VRP quietly folds a comparison
between an enum type and a constant value that the enum type can never take.
With -Wtype-limits, this should give the warning:
comparison always false due to limited range of data type
extern void link_error (void);
enum Alpha {
ZERO = 0, ONE, TWO, THREE
};
Alpha a2;
int m1 = -1;
int GetM1() {
return m1;
}
int main() {
a2 = static_castAlpha(GetM1());
if (a2 == -1) { -- VRP should warn when folding this.
link_error ();
}
return 0;
}
This is not warned by the front end because we promote -1 to the same type as
a2. But during VRP, we *do* fold the predicate, so warning when -Wtype-limits
is given in this case would be a good QOI feature.
I have a patch in the works to make VRP warn when it linearizes this predicate.
--
Summary: -Wtype-limits misses a warning when comparing enums
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
[Bug rtl-optimization/33644] [4.3 Regression] ICE in local_cprop_pass with -ftrapv for crafty
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-11 18:12:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33644
[Bug c++/33738] -Wtype-limits misses a warning when comparing enums
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-11 18:09 --- Warnings from optimizers are semi a no-no. Yes we have them for strict aliasing and overflow but I think those cases are a bit weird. This is unspecified behavior no matter what and there is no flag to change the behavior here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
--- Comment #5 from steven at gcc dot gnu dot org 2007-10-11 18:52 --- What do the edge flags look like after cprop changes the jump? EDGE_FALLTHRU should be set. Also, the unconditional JUMP_INSN should be removed. Unconditional jumps are removed when going into cfglayout mode, and when a conditional jump is turned into an unconditional jump, the whole JUMP_INSN can be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
--- Comment #6 from steven at gcc dot gnu dot org 2007-10-11 18:53 --- The patch from comment #4 is wrong and should not be applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug debug/33739] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-11 19:15 --- This is not a testsuite error, this is a target issue with some stabs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Component|testsuite |debug Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug testsuite/33739] New: Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
From http://gcc.gnu.org/ml/fortran/2007-10/msg00083.html: On revision 129030 (built from scratch at revision 129024) I get the following error on Darwin: [karma] f90/bug% gfc -m64 -g /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/literal_character_constant_1_x.F ld64 warning: BINCL (/opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/literal_character_constant_1.inc) missing EINCL in /var/tmp//ccoy6bhp.o Any idea? Sill there at revision 129234 -- Summary: Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #6 from pault at gcc dot gnu dot org 2007-10-11 19:10 --- (In reply to comment #3) Dominique, Oui, c'est bon! Merci. Paul (In reply to comment #5) Oui, c'est bon! Merci. Question: is this the only omission? I think so - most important is that EXPR_FUNCTION and EXPR_VARIABLE do not get through. I think that EXPR_NULL would be rather bad too! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #18 from belyshev at depni dot sinp dot msu dot ru 2007-10-11
19:52 ---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
Kenneth Zadeck [EMAIL PROTECTED] writes:
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* global.c (build_insn_chain): Include insn that occur between
basic blocks.
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* gcc.c-torture/gcc.dg/torture/pr33676.c: New.
^^ typo, should be:
* gcc.dg/torture/pr33676.c: New.
Kenny
Index: testsuite/gcc.dg/torture/pr33676.c
===
--- testsuite/gcc.dg/torture/pr33676.c(revision 0)
+++ testsuite/gcc.dg/torture/pr33676.c(revision 0)
@@ -0,0 +1,53 @@
+/* { dg-do run } */
+/* { dg-options -march=i586 -fomit-frame-pointer { target { { i?86-*-*
x86_64-*-* } ilp32 } } } */
^ better use -march=i386 so testcase wont fail
with SIGILL on i486 machines in case (if ever)
anyone will try to test gcc there.
+// Small testcase, compile with -march=i586 -O0 -fomit-frame-pointer:
omit this comment to keep it cleaner and smaller. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-11 19:29 --- It calls purge_dead_edges after changing the jump, so if it changed that into an unconditional jump, purge_dead_edges will purge the EDGE_FALLTHRU edge and keep the other edge. If cfglayout mode is supposed to avoid unconditional jumps, then that needs to be changed, so that the old non-fallthrough edge becomes EDGE_FALLTHRU and old EDGE_FALLTHRU is removed. I believe in other cases cprop_jump could e.g. only simplify an conditional jump (then what it does ATM is probably ok) or could e.g. change a conditional returnjump_p into unconditional one (how are those supposed to be expressed in cfglayout mode)? Anyway, it seems both pass_gcse and pass_bypass are both always in cfglayout mode, so no conditionalization on current_ir_type () is needed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #22 from spop at gcc dot gnu dot org 2007-10-11 19:35 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear There are several bugs that fail in the exact same place, because we're not able to generate code for some induction variable containing a phi node in their evolution. I'm trying to fix all these bugs by implementing an analysis phase that will filter out all the difficult loops for which we know we won't be able to generate code for. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug debug/33740] New: gcc 4.1.1 on AIX - gdb and TV fail to see static value due to likely gcc compiler bug
I would like to report a probable gcc compiler bug that is to present on AIX
5.3, but not on x86 linux. The problem is that Totalview and gdb fail to see a
static value 'stupify' when the program is compiled and linked using gcc 4.1.1.
If I cross link and compile (e.g. compile using gcc and link using xlc
8.0.0.0), things do not work if the compilation is done using gcc. Things do
work if I compile using xlc and then link using gcc (or use xlc for both). This
makes us suspect that this is a compiler problem specific to AIX OS: the gcc
compiler apparently creates an .o file that is not anymore understandable to
the linker (more details below).
Compiler + Linker
gcc + gcc FAIL
gcc + xlc FAIL
xlc + xlc OK
xlc + gcc OK
Below please find the dump info related to two pure cases: gcc+gcc and xlc+xlc,
compilation and linking respectively. It seems to me that in the gcc case, the
final executable (see gcc_gcc_dump) has incorrect/undefined type declaration
(unamex), whereas the xlc version has the type of stupify as 'stsym' which
sounds right to me?
Our internal code for this bug is #10494. More details below:
XXX
# AIX 5.3
# compilation
/home/compilers/gnu/gcc/4.1.1/rs6000_5.3/bin/gcc -g -c -o file_static.o
file_static.c
# linking
/home/compilers/gnu/gcc/4.1.1/rs6000_5.3/bin/gcc -g -o file_static
file_static.o
#- 5.3, and gcc 4.1.1 does NOT WORK
objdump --syms ./file_static.o | grep stupify
dump -tv ./file_static | grep stupify
# AIX 5.3
# compilation
/home/compilers/ibm/c++/8.0.0.0/rs6000_5.3/usr/vac/bin/xlc -g -c -o
file_static.o file_static.c
# linking
/home/compilers/ibm/c++/8.0.0.0/rs6000_5.3/usr/vac/bin/xlc -g -o file_static
file_static.o
#- 5.3, and xlc 8.0.0.0 works
objdump --syms ./file_static.o | grep stupify
dump -tv ./file_static | grep stupify
In the latter case both Totalview and gdb see the variable 'stupify', whereas
with gcc compilation and linking, the symbol is not available to the debuggers.
On older versions of gcc, we see the following:
On AIX 5.1, gcc 3.2.3 works, but 3.3.3 does not:
gcc V3.2.3 compiles file_static.c into an object file containing both:
1. A hidden external CSECT definition for ``stupify'' in the TOC,
pointing to 4 anonymous bytes in BSS.
-and-
2. An initialized per-module static variable debug symbol for ``stupify''.
gcc V3.3 generates the same two symbols (although it denotes the COMMON
block containing ``stupify''s actual storage in a subtly different fashion).
However, when the V3.2.3 object file is linked, the a.out file preserves
both ``stupify''s CSECT definition, *and* its debug symbol,
while when the V3.3 object file is linked, the a.out file does not
contain ``stupify''s debug symbol.
This is true whether the object files in question are linked via by the
compiler driver gcc (3.2.3, 3.3 or 4.1.1), or IBM xlc.
The difference in symbols between the two executables may stem from
linker handling of the COMMON storage for ``stupify''.
XXx
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
file_static.c:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#include stdio.h
static unsigned long int stupify = 0;
void a(void)
{
if (!stupify) {
unsigned long int t = 0;
stupify = 256 * 1024 * 1024;
t = stupify;
printf(s = %lu, t = %lu\n,stupify,t);
}
}
main()
{
a();
printf(hello, world\n);
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
XXX
X
The key segments of the symbol info look like as follows
gcc compilation and linking::
chrome:/home/seppo/Bugs/Bug_10494 grep -A 3 -B 3 stupify gcc_gcc_objdump.txt
[259](sec 1)(fl 0x00)(ty 0)(scl 101) (nx 1) 0x0138 .ef
AUX lnno 19 size 0x0 tagndx 0
[261](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x010a .bs
[262](sec -2)(fl 0x00)(ty 0)(scl 133) (nx 0) 0x stupify:S-10
[263](sec 1)(fl 0x00)(ty 0)(scl 144) (nx 0) 0x .es
[264](sec 1)(fl 0x00)(ty 0)(scl 107) (nx 1) 0x0150 _filestatic.rw_
AUX val33 prmhsh 0 snhsh 0 typ 1 algn 3 clss 1 stb 0 snstb 0
--
AUX val 4 prmhsh 0 snhsh 0 typ 1 algn 3 clss 5 stb 0 snstb 0
[280](sec 2)(fl 0x00)(ty 0)(scl 107) (nx 1) 0x01a4 TOC
AUX val 0 prmhsh 0 snhsh 0 typ 1 algn 2 clss 15 stb 0 snstb 0
[282](sec 2)(fl 0x00)(ty 0)(scl 107) (nx 1) 0x01a4 stupify
AUX val 4 prmhsh 0 snhsh 0 typ 1 algn 2 clss 3 stb 0 snstb 0
[284](sec 2)(fl 0x00)(ty 0)(scl 107) (nx 1) 0x01a8 LC..1
AUX val 4 prmhsh 0 snhsh 0 typ 1 algn 2 clss 3 stb 0 snstb 0
chrome:/home/seppo/Bugs/Bug_10494 grep -A 3 -B 3 stupify gcc_gcc_dump.txt
[49]a4 0x0004 00 SD TC00
[50]m 0x2e04 .data 1 unamex
[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled
--- Comment #8 from steven at gcc dot gnu dot org 2007-10-11 19:55 --- Updating the CFG as suggested in comment #7 is the appropriate thing to do. How about using delete_insn_and_edges() on the jump insn, and setting EDGE_FALLTHRU on the remaining edge? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673
[Bug tree-optimization/33742] New: Segfault in vectorizable_operation
Seeing a segfault trying to build 164.gzip from cpu2000. Noticed it with -O3,
but also occurs for -O2/-O1 -ftree-vectorize.
run/0001 cat junk.c
typedef unsigned short ush;
extern ush prev[];
void fill_window()
{
register unsigned n, m;
for (n = 0; n 32768; n++) {
m = prev[n];
prev[n] = (ush)(m = 0x8000 ? m-0x8000 : 0);
}
}
run/0001 /home/pthaugen/install/gcc/trunk/bin/gcc -c -m32 -O3 junk.c
junk.c: In function 'fill_window':
junk.c:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Program received signal SIGSEGV, Segmentation fault.
vectorizable_operation (stmt=0xf7f69860, bsi=0x0, vec_stmt=0x0, slp_node=0x0)
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-transform.c:3807
3807 nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
(gdb) bt 5
#0 vectorizable_operation (stmt=0xf7f69860, bsi=0x0, vec_stmt=0x0,
slp_node=0x0)
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-transform.c:3807
#1 0x106efc68 in vect_analyze_operations (loop_vinfo=0x109d8d20)
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-analyze.c:484
#2 0x106f7060 in vect_analyze_loop (loop=0xf7ec43f0)
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-analyze.c:4341
#3 0x104d010c in vectorize_loops ()
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:2501
#4 0x1045e000 in tree_vectorize ()
at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:216
(More stack frames follow...)
--
Summary: Segfault in vectorizable_operation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33742
[Bug debug/33740] gcc 4.1.1 on AIX - gdb and TV fail to see static value due to likely gcc compiler bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-11 21:14 --- Can you try 4.1.2 or 4.2.x? 4.1.1 is getting a bit old. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33740
[Bug debug/33740] gcc 4.1.1 on AIX - gdb and TV fail to see static value due to likely gcc compiler bug
--- Comment #2 from seppo at totalviewtech dot com 2007-10-11 21:37 --- Hi Andrew, Thanks for the quick reply. We do not have more recent versions installed on AIX, but I have sent just now an installation request. I'll keep you posted. Thanks, Seppo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33740
[Bug middle-end/33662] [4.3 Regression] Wrong register allocation on SH
--- Comment #7 from zadeck at naturalbridge dot com 2007-10-11 21:50 --- kazumoto, there was a set of miscommunications associated with the final patch for pr33669. hj had checked in an earlier version of the patch and that testcase and i asked him to revert it because there were issues with it. He only reverted the code and left the testcase in. You tested against version 129192 and i checked in the corrected patch as 129193. given that, pr33669.c should have failed. seongbae has verified that pr33669.c and the testcase here no longer fails on the current truck with sh-elf. I am going to assume that this is closed unless you find some other issue. Sorry for the mess up. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33662
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #19 from zadeck at gcc dot gnu dot org 2007-10-11 22:32 --- Subject: Bug 33676 Author: zadeck Date: Thu Oct 11 22:31:55 2007 New Revision: 129244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129244 Log: 2007-10-11 Kenneth Zadeck [EMAIL PROTECTED] PR middle-end/33676 * global.c (build_insn_chain): Include insn that occur between basic blocks. 2007-10-11 Kenneth Zadeck [EMAIL PROTECTED] PR middle-end/33676 * gcc.dg/torture/pr33676.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr33676.c Modified: trunk/gcc/ChangeLog trunk/gcc/global.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #20 from zadeck at naturalbridge dot com 2007-10-11 22:35
---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
zadeck at naturalbridge dot com wrote:
--- Comment #17 from zadeck at naturalbridge dot com 2007-10-11 16:21
---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
When I rewrote this code to use backward scanning rather than forwards
scanning, I converted it to properly use the cfg, since it is generally
considered outmoded to just scan the insns.
However, the reload_insn_chain actually needs the insns that appear
between basic blocks, in particular the labels in front of branch
tables. I added code here to check for insns that may be in front of a
basic block after scanning that block.
There are a lot of ways that I could have done this, for instance, I
could have just written in terms of the PREV_INSN as the old code was.
I think that in doing it the way that i have done it, it is obvious what
needs to be done if someone really does get rid of the branch tables
between the blocks.
This has been bootstrapped and regression tested on x86-{64,32} ppc-32,
and ia-64. However it is not clear to me how many platforms use this
kind of table branch. The bug appears to only be on the -march=i586, so
the reviewers may wish to comment on my choice of dg options on the test.
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* global.c (build_insn_chain): Include insn that occur between
basic blocks.
2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/33676
* gcc.dg/torture/pr33676.c: New.
bootstrapped and regression tested on x86-32 x86-64, ppc-32 and ia-64.
committed as revision 129244.
Kenny
Index: ChangeLog
===
--- ChangeLog (revision 129243)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
+
+ PR middle-end/33676
+ * global.c (build_insn_chain): Include insn that occur between
+ basic blocks.
+
2007-10-11 Tom Tromey [EMAIL PROTECTED]
* gengtype-yacc.y: Delete.
Index: testsuite/gcc.dg/torture/pr33676.c
===
--- testsuite/gcc.dg/torture/pr33676.c (revision 0)
+++ testsuite/gcc.dg/torture/pr33676.c (revision 0)
@@ -0,0 +1,51 @@
+/* { dg-do run } */
+/* { dg-options -march=i586 -fomit-frame-pointer { target { { i?86-*-*
x86_64-*-* } ilp32 } } } */
+
+__attribute__((noreturn,noinline)) void abrt (const char *fi, const char *fu)
+{
+ __builtin_abort ();
+}
+
+__attribute__((noinline)) int f (int k)
+{
+ return k;
+}
+
+__attribute__((noinline)) int g (int t, int k)
+{
+ int b;
+
+ switch (t)
+{
+case 0:
+ abrt (__FILE__, __FUNCTION__);
+
+case 1:
+ b = f (k);
+ break;
+
+case 2:
+ b = f (k);
+ break;
+
+case 3:
+ b = f (k);
+ break;
+
+case 4:
+ b = f (k);
+ break;
+
+default:
+ abrt (__FILE__, __FUNCTION__);
+}
+
+ return b;
+}
+
+int main (void)
+{
+ if (g (3, 1337) != 1337)
+ abrt (__FILE__, __FUNCTION__);
+ return 0;
+}
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 129243)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2007-10-11 Kenneth Zadeck [EMAIL PROTECTED]
+
+ PR middle-end/33676
+ * gcc.dg/torture/pr33676.c: New.
+
2007-10-11 Paolo Carlini [EMAIL PROTECTED]
PR c++/31441
Index: global.c
===
--- global.c(revision 129243)
+++ global.c(working copy)
@@ -1575,6 +1575,41 @@ build_insn_chain (void)
}
}
}
+
+ /* FIXME!! The following code is a disaster. Reload needs to see the
+labels and jump tables that are just hanging out in between
+the basic blocks. See pr33676. */
+
+ insn = BB_HEAD (bb);
+
+ /* Skip over the barriers and cruft. */
+ while (insn (BARRIER_P (insn) || NOTE_P (insn) || BLOCK_FOR_INSN
(insn) == bb))
+ insn = PREV_INSN (insn);
+
+ /* While we add anything except barriers and notes, the focus is
+to get the labels and jump tables into the
+reload_insn_chain. */
+ while (insn)
+ {
+ if (!NOTE_P (insn) !BARRIER_P (insn))
+ {
+ if (BLOCK_FOR_INSN (insn))
+ break;
+
+ c = new_insn_chain ();
+ c-next = next;
+ next = c;
+ *p = c;
+ p = c-prev;
+
+ c-insn = insn;
+ /* The block makes no sense here, but it is what the old
+code did. */
+
[Bug target/33700] FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors)
--- Comment #9 from danglin at gcc dot gnu dot org 2007-10-11 23:50 --- Steve, Does this bug also affect ia64-hpux? -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||sje at cup dot hp dot com Component|libstdc++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33700
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-10-12 00:11 --- Mine -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-12-27 00:06:38 |2007-10-12 00:11:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug target/33743] New: problem with unwinding through signal frame.
gcc-4.1 with patch from PR26208 doesn't support unwinding through signal frames. $ uname -a SunOS hermes 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-1500 $ ./u-sparc-sun-solaris2.9 boom! 10af4 signalHandler+0x1c ff31f010 _setuid+0x68 alive! $ ./u-sparc64-sun-solaris2.9 boom! 10dac signalHandler+0x28 7f1a7b58 _setuid+0x54 alive! on x86 it works fine. $ ./u-i486-gnu-linux boom! 0x8048ac8 signalHandler+0x15 0xe500 __kernel_sigreturn+0x0 0x8048b0e zoo+0x34 0x8048b21 bar+0xb 0x8048b36 foo+0x13 0x8048b63 main+0x28 0x322de6 __libc_start_main+0xc6 alive! $ ./u-x86_64-gnu-linux boom! 0x400deb signalHandler+0x1a 0x400e26 zoo+0x2c 0x400e45 bar+0x17 0x400e55 foo+0xe 0x400e6f main+0x18 0x34cf71c4cc __libc_start_main+0xdc alive! -- Summary: problem with unwinding through signal frame. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: sparc*-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug target/33743] problem with unwinding through signal frame.
--- Comment #2 from pluto at agmk dot net 2007-10-12 00:26 --- Created an attachment (id=14343) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14343action=view) testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug middle-end/33662] [4.3 Regression] Wrong register allocation on SH
--- Comment #8 from kkojima at gcc dot gnu dot org 2007-10-12 02:06 --- You tested against version 129192 and i checked in the corrected patch as 129193. Oh, my tester had fallen into that narrow pitfall :-) I've confirmed that the errors go away with the current trunk. Thanks both of you and seongbae! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33662
[Bug middle-end/33714] [4.2 Regression] ivopts miscompiles insn-output.c
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-10-12 03:03 --- (In reply to comment #2) Confirmed. You need HWI of 32bits to trigger the problem. Maybe latent on the trunk (I didn't check if it fails there, too). The problem was fixed in mainline in this commit (I somehow did not realize that this code was present also in 4.2): 2006-12-13 Zdenek Dvorak [EMAIL PROTECTED] * tree-ssa-loop-ivopts.c: ... (constant_multiple_of): Fix order of operators for division. ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33714
[Bug c++/33744] New: within function-style cast incorrectly parsed as closing template angle bracket
This compiled with 3.3:
template bool cond
struct A {
};
A bool (2 1) x;
It doesn't compile with at least some later versions, including 3.4 and 4.2.1,
with:
x.cpp:4: error: template argument 1 is invalid
x.cpp:4: error: invalid type in declaration before ';' token
Rejects-valid regression in the new parser in 3.4?
--
Summary: within function-style cast incorrectly parsed as
closing template angle bracket
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mdorey at bluearc dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #21 from kargl at gcc dot gnu dot org 2007-10-12 04:07 --- Kenny, My build tonight's tree completed successfully. I think this PR can be close, but you may want to hear from Gerald first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug tree-optimization/33735] [4.3 Regression] verify_stmts failed: missing PHI def
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-10-11 10:36:13 |2007-10-12 04:19:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33735
[Bug fortran/33733] ICEs in simplify_transfer
--- Comment #7 from pault at gcc dot gnu dot org 2007-10-12 04:49 --- (In reply to comment #6) Better still is if (source-expr_type == EXPR_FUNCTION) return NULL; since source is already tested to be a constant expression. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
