[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-03-28 07:28 --- Subject: Bug 31334 Author: pinskia Date: Fri Mar 28 07:27:11 2008 New Revision: 133674 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133674 Log: 2008-03-28 Andrew Pinski [EMAIL PROTECTED] PR target/31334 * config/rs6000/rs6000.c (rs6000_expand_vector_init): Create a const_vector when all the vectors are constant. 2008-03-28 Andrew Pinski [EMAIL PROTECTED] PR target/31334 * gcc.target/powerpc/altivec-25.c: Nnew testcase. Added: trunk/gcc/testsuite/gcc.target/powerpc/altivec-25.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-03-28 07:30 --- The original issue has now been fixed, the rest is registered as PR 32107 and PR 32110. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-28 08:33 --- (In reply to comment #3) 1) If I am not mistaken, the first change is within a commented block (look at the last line in the diff.: ' } */') Yes, indeed - the comment has been made consistent with the intended patch 2) With the patch I have a lot of regressions on my quick and dirty testsuite. Among them I have several: The patch posted here is in error - the version posted to the lists is correct. Please note that I have no idea why what appears here did anything for the reporter's testcase! + size = fold_build3 (COND_EXPR, gfc_array_index_type, cond, + size, gfc_index_zero_node); has the last two arguments the wrong way round *sorry* Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #9 from nickc at redhat dot com 2008-03-28 08:43 --- Hi Jeff, Thanks - I have checked the patch in. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #10 from nickc at gcc dot gnu dot org 2008-03-28 08:43 --- Subject: Bug 31110 Author: nickc Date: Fri Mar 28 08:42:36 2008 New Revision: 133675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133675 Log: PR target/31110 * config/mn10300/mn10300.c (mn10300_secondary_reload_class): Return GENERAL_REGS for stack adjustment reloads. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mn10300/mn10300.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #11 from mstein dot lists at googlemail dot com 2008-03-28 08:54 --- Can the patch be applied to the 4.3 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug c++/35730] New: ICE on valid code convert_move expr.c:373
The following code produces an ICE with GCC-4.3.0 when compiled with g++ and
-O. Removing -O or using gcc removes the ICE.
#include string.h
int moo(void)
{
unsigned char msg[] = { 0, 0 };
unsigned char data[2];
memcpy(data, msg, sizeof (msg));
return memcmp(data, msg, sizeof (data)) != 0;
}
Also, changing msg's declaration from msg[] to msg[2] avoids the ICE.
g++430 test.c -c -O
test.c: In function 'int moo()':
test.c:6: internal compiler error: in convert_move, at expr.c:373
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions
Using gcc430, g++423, or g++412, the code compiles fine. Of the builds I
tested, only g++ 4.3.0 has the problem.
--
Summary: ICE on valid code convert_move expr.c:373
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davids at webmaster dot com
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=35730
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #5 from mstein dot lists at googlemail dot com 2008-03-28 08:56 --- Can the patch be applied to the 4.3 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug fortran/35731] New: libfortran should use gettext to for localized error messages
Currently, only libcpp and the compilers (gcc) use gettext for localized error messages. libgfortran should do the same. Note: Besides the actual change, the libgfortran.pot file needs also to uploaded at http://translationproject.org. I don't know where this is documented, but the release manager does these .pot uploads regularly. We essentially need: a) In libgfortran.h: #ifdef ENABLE_NLS #include libintl.h #else /* Stubs. */ # undef dgettext # define dgettext(package, msgid) (msgid) #endif b) In fmain.c (or somewhere else): #ifdef ENABLE_NLS (void) bindtextdomain (PACKAGE, LOCALEDIR); #endif #ifndef _ # define _(msgid) dgettext (PACKAGE, msgid) #endif #ifndef N_ # define N_(msgid) msgid #endif c) In configure.ac ZW_GNU_GETTEXT_SISTER_DIR d) We need to add somehow the po directory, but I have not figured out how. -- Summary: libfortran should use gettext to for localized error messages Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35731
[Bug c++/35730] ICE on valid code convert_move expr.c:373
--- Comment #1 from davids at webmaster dot com 2008-03-28 09:24 ---
#include string.h
int moo(void)
{
unsigned char msg1[] = { 0, 0 };
unsigned char msg2[] = { 0, 0 };
memcpy(msg1, msg2, 2);
return memcmp(msg1, msg2, 2) != 0;
}
With this code, changing the sizes in both memcpy and memcmp from '2' to '1'
makes the problem go away. So does changing both arrays from '{ 0, 0 }' to { 0,
0, 0 }'. So maybe it's an off-by-one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35730
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #12 from nickc at gcc dot gnu dot org 2008-03-28 09:30 --- Subject: Bug 31110 Author: nickc Date: Fri Mar 28 09:30:05 2008 New Revision: 133676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133676 Log: PR target/31110 * config/mn10300/mn10300.c (mn10300_secondary_reload_class): Return GENERAL_REGS for stack adjustment reloads. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/mn10300/mn10300.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #13 from nickc at redhat dot com 2008-03-28 09:31 --- Subject: Re: Problem while compiling gcc for mn10300-elf Hi Mike, Can the patch be applied to the 4.3 branch too? Done. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #6 from nickc at redhat dot com 2008-03-28 09:33 --- Subject: Re: Problem while compiling gcc for xstormy16-elf Hi Mike, Can the patch be applied to the 4.3 branch too? Done. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #7 from nickc at gcc dot gnu dot org 2008-03-28 09:33 --- Subject: Bug 31232 Author: nickc Date: Fri Mar 28 09:33:01 2008 New Revision: 133677 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133677 Log: PR target/31232 * config/stormy16/stormy16.c (xstormy16_legitimate_address_p): Do not allow INT+INT as a legitimate addressing mode. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/stormy16/stormy16.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-03-28 10:13 --- Note this is only fixed because we run inlining twice. It isn't fixed properly in that the new inlining opportunity should be exposed during the first inlining pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9079
[Bug c/35728] Inlined function via function pointer emitted unnecessarily
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-28 10:15 --- Hm, interesting. Do we not remove unused functions after final inlining? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35728
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-28 10:26 --- Confirmed. RTL loop invariant motion moves the volatile load out of the function. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |rtl-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.2.3 4.3.0 Known to work||4.1.3 Last reconfirmed|-00-00 00:00:00 |2008-03-28 10:26:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #8 from mstein dot lists at googlemail dot com 2008-03-28 10:30 --- Fixed :) -- mstein dot lists at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug c++/35730] ICE on valid code convert_move expr.c:373
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-28 10:30 --- *** This bug has been marked as a duplicate of 35526 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35730
[Bug c/35526] ICE on memcpy
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-28 10:30 --- *** Bug 35730 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||davids at webmaster dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35526
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #14 from mstein dot lists at googlemail dot com 2008-03-28 10:31 --- Fixed :) -- mstein dot lists at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #14 from burnus at gcc dot gnu dot org 2008-03-28 10:32 --- (In reply to comment #13) Created an attachment (id=15374) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15374action=view) [edit] Patch padding for constant character lengths I assume that you have not bootstrapped GCC/gfortran since with that patch it fails when compiling libgfortran/intrinsics/selected_real_kind.f90. Reduced test case: type :: real_info integer :: kind end type real_info type (real_info) :: real_infos(1) = (/ real_info (4) /) end type (real_info) :: real_infos(1) = (/ real_info (4) /) 1 Error: Syntax error in array constructor at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #14 from carlos at codesourcery dot com 2008-03-28 11:39 --- With the patch in comment #9, a glibc cvs head build completes successfully. The test results show some regressions, but this is almost always the case when switching to a new gcc branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug tree-optimization/30317] VRP cannot extract a range from (unsigned int) i + 0x0ffffffff 4
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-28 12:21 --- Subject: Bug 30317 Author: rguenth Date: Fri Mar 28 12:20:09 2008 New Revision: 133680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133680 Log: 2008-03-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/30317 PR tree-optimization/30911 PR tree-optimization/34793 * tree-vrp.c (set_and_canonicalize_value_range): New function. (struct assert_locus_d): New member EXPR. (register_new_assert_for): Add EXPR parameter to support ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_1): Adjust callers. (find_assert_locations): Likewise. (process_assert_insertions_for): Build condition from expression. (extract_range_from_assert): Handle ASSERT_EXPRs of the form ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_2): New helper registering asserts for comparisons. Recognize range tests of the form (unsigned)i - CST1 OP CST2. (register_edge_assert_for_1): Use it. (register_edge_assert_for): Likewise. * tree.def (ASSERT_EXPR): Document extra allowed conditional expressions. (needs_overflow_infinity): Integer sub-types do not need overflow infinities. (vrp_val_is_max): The extreme values of integer sub-types are those of the base type. (vrp_val_is_min): Likewise. * gcc.dg/tree-ssa/vrp35.c: New testcase. * gcc.dg/tree-ssa/vrp36.c: Likewise. * gcc.dg/tree-ssa/vrp37.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp35.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp36.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #44 from rguenth at gcc dot gnu dot org 2008-03-28 12:21 --- Subject: Bug 30911 Author: rguenth Date: Fri Mar 28 12:20:09 2008 New Revision: 133680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133680 Log: 2008-03-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/30317 PR tree-optimization/30911 PR tree-optimization/34793 * tree-vrp.c (set_and_canonicalize_value_range): New function. (struct assert_locus_d): New member EXPR. (register_new_assert_for): Add EXPR parameter to support ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_1): Adjust callers. (find_assert_locations): Likewise. (process_assert_insertions_for): Build condition from expression. (extract_range_from_assert): Handle ASSERT_EXPRs of the form ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_2): New helper registering asserts for comparisons. Recognize range tests of the form (unsigned)i - CST1 OP CST2. (register_edge_assert_for_1): Use it. (register_edge_assert_for): Likewise. * tree.def (ASSERT_EXPR): Document extra allowed conditional expressions. (needs_overflow_infinity): Integer sub-types do not need overflow infinities. (vrp_val_is_max): The extreme values of integer sub-types are those of the base type. (vrp_val_is_min): Likewise. * gcc.dg/tree-ssa/vrp35.c: New testcase. * gcc.dg/tree-ssa/vrp36.c: Likewise. * gcc.dg/tree-ssa/vrp37.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp35.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp36.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-28 12:21 --- Subject: Bug 34793 Author: rguenth Date: Fri Mar 28 12:20:09 2008 New Revision: 133680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133680 Log: 2008-03-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/30317 PR tree-optimization/30911 PR tree-optimization/34793 * tree-vrp.c (set_and_canonicalize_value_range): New function. (struct assert_locus_d): New member EXPR. (register_new_assert_for): Add EXPR parameter to support ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_1): Adjust callers. (find_assert_locations): Likewise. (process_assert_insertions_for): Build condition from expression. (extract_range_from_assert): Handle ASSERT_EXPRs of the form ASSERT_EXPR name, expr OP limit. (register_edge_assert_for_2): New helper registering asserts for comparisons. Recognize range tests of the form (unsigned)i - CST1 OP CST2. (register_edge_assert_for_1): Use it. (register_edge_assert_for): Likewise. * tree.def (ASSERT_EXPR): Document extra allowed conditional expressions. (needs_overflow_infinity): Integer sub-types do not need overflow infinities. (vrp_val_is_max): The extreme values of integer sub-types are those of the base type. (vrp_val_is_min): Likewise. * gcc.dg/tree-ssa/vrp35.c: New testcase. * gcc.dg/tree-ssa/vrp36.c: Likewise. * gcc.dg/tree-ssa/vrp37.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp35.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp36.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug fortran/35731] libfortran should use gettext to for localized error messages
--- Comment #1 from joseph at codesourcery dot com 2008-03-28 12:48 --- Subject: Re: New: libfortran should use gettext to for localized error messages On Fri, 28 Mar 2008, burnus at gcc dot gnu dot org wrote: Currently, only libcpp and the compilers (gcc) use gettext for localized error messages. libgfortran should do the same. Note: Besides the actual change, the libgfortran.pot file needs also to uploaded at http://translationproject.org. I don't know where this is documented, but the release manager does these .pot uploads regularly. You need to update translation.html with the details of any new pieces of GCC added to the TP (so RMs know how to regenerate the .pot file), and ensure the TP has the same configuration for them as for gcc and libcpp (e.g., new .po files are sent to gcc-patches). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35731
[Bug tree-optimization/30317] VRP cannot extract a range from (unsigned int) i + 0x0ffffffff 4
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-28 12:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.0 Known to work||4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-28 13:02 --- I have two patches for the other missing parts to fix this PR. -- 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|2008-01-20 16:06:48 |2008-03-28 13:02:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug rtl-optimization/19580] [4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #38 from rguenth at gcc dot gnu dot org 2008-03-28 13:40 --- Fixed in GCC 4.4 with the store-motion rewrite to use an alias-oracle: bb 3: r_I_lsm.18 = r[5]; r_I_lsm.13 = r[0]; r_I_lsm.14 = r[1]; r_I_lsm.15 = r[2]; r_I_lsm.16 = r[3]; r_I_lsm.17 = r[4]; r_I_lsm.27 = r_I_lsm.18; bb 4: r_I_lsm.13 = r_I_lsm.13 + r_I_lsm.27; r_I_lsm.14 = r_I_lsm.14 + r_I_lsm.13; r_I_lsm.15 = r_I_lsm.14 + r_I_lsm.15; r_I_lsm.16 = r_I_lsm.15 + r_I_lsm.16; r_I_lsm.17 = r_I_lsm.16 + r_I_lsm.17; r_I_lsm.18 = r_I_lsm.17 + r_I_lsm.18; n.26 = n.26 + -1; r_I_lsm.28 = r_I_lsm.27; r_I_lsm.27 = r_I_lsm.18; if (n.26 != 0) goto bb 4; else goto bb 5; bb 5: r_I_lsm.27 = r_I_lsm.28; r[0] = r_I_lsm.13; r[1] = r_I_lsm.14; r[2] = r_I_lsm.15; r[3] = r_I_lsm.16; r[4] = r_I_lsm.17; r[5] = r_I_lsm.18; I'll add a testcase to the testsuite. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.3.3 2.95.3 3.0.4 3.2.3|3.3.3 2.95.3 3.0.4 3.2.3 ||4.4.0 Summary|[4.1/4.2/4.3/4.4 Regression]|[4.1/4.2/4.3 Regression] |missed load/store motion|missed load/store motion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/19580] [4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-03-28 13:45 --- Subject: Bug 19580 Author: rguenth Date: Fri Mar 28 13:44:41 2008 New Revision: 133683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133683 Log: 2008-03-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/19580 * gcc.dg/tree-ssa/loop-34.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-34.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug fortran/35721] ASSOCIATED returns false when strides confusing
--- Comment #3 from burnus at gcc dot gnu dot org 2008-03-28 13:47 --- Subject: Bug 35721 Author: burnus Date: Fri Mar 28 13:47:06 2008 New Revision: 133684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133684 Log: 2008-03-28 Tobias Burnus [EMAIL PROTECTED] PR fortran/35721 * intrinsics/associated.c (associated): Ignore different stride of pointer vs. target if only one element is referred. 2008-03-28 Tobias Burnus [EMAIL PROTECTED] PR fortran/35721 * gfortran.dg/associated_target_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/associated.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35721
[Bug fortran/35721] ASSOCIATED returns false when strides confusing
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-28 13:49 --- FIXED on the trunk (4.4.0). Thanks again for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Keywords||wrong-code Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35721
[Bug c/35608] gcc.c-torture/compile/limits-structnest.c fails -O2 -Os
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-28 14:04 --- The testcase has 10001 nested (), which is processed with recursive calls. My default stack limit is 8MB. 10001 recursive calls need around 8MB stack. Any changes in my setup will push it over the limit. I think we should do one of the followings: 1. Mark it XFAIL. 2. Lower the number of (). 3. Call setrlimit to raise stack limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- Comment #13 from baldrick at gcc dot gnu dot org 2008-03-28 14:30 --- This has been fixed. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug target/35655] [m68hc11] Segmentation fault when compiling libgcc2.c
--- Comment #1 from mstein dot lists at googlemail dot com 2008-03-28 14:51 --- backtrace: [EMAIL PROTECTED]:~/build/m68hc11-elf/build/gcc$ gdb -args /home/mstein/build/m68hc11-elf/build/./gcc/cc1 -quiet -nostdinc -v -I. -I. -I../.././gcc -I/home/mstein/combined-trunk/libgcc -I/home/mstein/combined-trunk/libgcc/. -I/home/mstein/combined-trunk/libgcc/../gcc -I/home/mstein/combined-trunk/libgcc/../include -iprefix /home/mstein/build/m68hc11-elf/build/gcc/../lib/gcc/m68hc11-elf/4.4.0/ -isystem /home/mstein/build/m68hc11-elf/build/./gcc/include -isystem /home/mstein/build/m68hc11-elf/build/./gcc/include-fixed -MD _negdi2.d -MF _negdi2.dep -MP -MT _negdi2.o -D__INT__=32 -Dmc6811 -DMC6811 -Dmc68hc11 -DUSE_GAS -DIN_GCC -Dinhibit_libc -DIN_LIBGCC2 -DHAVE_CC_TLS -DL_negdi2 -isystem /home/mstein/build/m68hc11-elf/build/m68hc11-elf/newlib/targ-include -isystem /home/mstein/combined-trunk/newlib/libc/include -isystem /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/include -isystem /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/sys-include /home/mstein/combined-trunk/libgcc/../gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mrelax -auxbase-strip _negdi2.o -g -g -O2 -Os -version -o /tmp/ccQivAqe.s GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. Breakpoint 1 at 0x5029f0: file /home/mstein/combined-trunk/gcc/diagnostic.c, line 683. Breakpoint 2 at 0x502920: file /home/mstein/combined-trunk/gcc/diagnostic.c, line 624. Function exit not defined. Function abort not defined. (gdb) r Starting program: /home/mstein/build/m68hc11-elf/build/gcc/cc1 -quiet -nostdinc -v -I. -I. -I../.././gcc -I/home/mstein/combined-trunk/libgcc -I/home/mstein/combined-trunk/libgcc/. -I/home/mstein/combined-trunk/libgcc/../gcc -I/home/mstein/combined-trunk/libgcc/../include -iprefix /home/mstein/build/m68hc11-elf/build/gcc/../lib/gcc/m68hc11-elf/4.4.0/ -isystem /home/mstein/build/m68hc11-elf/build/./gcc/include -isystem /home/mstein/build/m68hc11-elf/build/./gcc/include-fixed -MD _negdi2.d -MF _negdi2.dep -MP -MT _negdi2.o -D__INT__=32 -Dmc6811 -DMC6811 -Dmc68hc11 -DUSE_GAS -DIN_GCC -Dinhibit_libc -DIN_LIBGCC2 -DHAVE_CC_TLS -DL_negdi2 -isystem /home/mstein/build/m68hc11-elf/build/m68hc11-elf/newlib/targ-include -isystem /home/mstein/combined-trunk/newlib/libc/include -isystem /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/include -isystem /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/sys-include /home/mstein/combined-trunk/libgcc/../gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mrelax -auxbase-strip _negdi2.o -g -g -O2 -Os -version -o /tmp/ccQivAqe.s ignoring nonexistent directory /home/mstein/build/m68hc11-elf/build/m68hc11-elf/newlib/targ-include ignoring nonexistent directory /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/include ignoring nonexistent directory /home/mstein/cross-local/m68hc11-elf-new/m68hc11-elf/sys-include ignoring duplicate directory . ignoring nonexistent directory ../.././gcc ignoring duplicate directory /home/mstein/combined-trunk/libgcc/. #include ... search starts here: #include ... search starts here: . /home/mstein/combined-trunk/libgcc /home/mstein/combined-trunk/libgcc/../gcc /home/mstein/combined-trunk/libgcc/../include /home/mstein/build/m68hc11-elf/build/./gcc/include /home/mstein/build/m68hc11-elf/build/./gcc/include-fixed /home/mstein/combined-trunk/newlib/libc/include End of search list. GNU C (GCC) version 4.4.0 20080320 (experimental) [trunk revision 133402] (m68hc11-elf) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.1, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7efcced2695484d8ae118bce9c57f4e6 Program received signal SIGSEGV, Segmentation fault. 0x004f646c in df_lr_bb_local_compute (bb_index=4) at /home/mstein/combined-trunk/gcc/df-problems.c:846 846 for (def_rec = DF_INSN_UID_DEFS (uid); *def_rec; def_rec++) (gdb) bt #0 0x004f646c in df_lr_bb_local_compute (bb_index=4) at /home/mstein/combined-trunk/gcc/df-problems.c:846 #1 0x004fb04e in df_lr_local_compute (all_blocks=value optimized out) at /home/mstein/combined-trunk/gcc/df-problems.c:947 #2 0x004f4503 in df_analyze_problem (dflow=0xc95bc0, blocks_to_consider=0xc7ab40, postorder=0xca4190, n_blocks=6) at /home/mstein/combined-trunk/gcc/df-core.c:1171 #3 0x004f4769 in df_analyze () at /home/mstein/combined-trunk/gcc/df-core.c:1270 #4 0x008901ed in m68hc11_reorg () at
[Bug fortran/35732] New: -fbounds-check: LHS/RHS size mismatch: Misleading error message
For integer :: a(2) integer, volatile :: i i = 1 a(1:i) = a(1:2) end The message is misleading: At line 4 of file aa.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'a' (0/1) ISSUE: The size should be 1/2 and not 0/1 (For a zero-sized array the output is even -1). -- Summary: -fbounds-check: LHS/RHS size mismatch: Misleading error message Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35732
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #45 from baldrick at gcc dot gnu dot org 2008-03-28 14:58 --- The recent VRP improvements made no difference to this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-03-28 15:18 --- Reduced testcase: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/) call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 end output is: 17 18 11 36 77 22 39 16 41 18 while it should be: 17 18 11 4 13 22 7 16 9 18 I don't know if it related, but the following compiles and segfault at runtime: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/) call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 end while it gives a strange error message with -fbounds-check: At line 2 of file a.f90 Fortran runtime error: Array reference out of bounds for array 'ila1', upper bound of dimension 1 exceeded (68 10) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-28 15:29 --- For the second test in comment #1, ifort gives: fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not conform. [MVBITS] call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #3 from dick dot hendrickson at gmail dot com 2008-03-28 15:48 --- Subject: Re: wrong result for vector subscripted array expression in MVBITS Right, in case you haven't found it yet, the first paragraph of 12.7.3, page 214, says effectively that all of the arguments must be conformable with the TO argument. I was mildly amused that a significant restriction on MVBITS came in the paragraph before the one that explicitly discusses MVBITS. Dick Hendrickson On 28 Mar 2008 15:29:05 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #2 from dominiq at lps dot ens dot fr 2008-03-28 15:29 --- For the second test in comment #1, ifort gives: fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not conform. [MVBITS] call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3) ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #4 from dominiq at lps dot ens dot fr 2008-03-28 16:22 --- It looks like a missing temporary: integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/), ILA2, ILA3 ILA3 = (/9,9,6,2,4,9,2,9,6,10/) print '(10(I3))', ILA1((/9,9,6,2,4,9,2,9,6,10/)) ILA2 = ILA1 do i = 1, 10 call mvbits (ila2(ila3(i)), 2, 4, ila2(i), 3) end do write (*,'(10(I3))') ila2 ILA2 = ILA1 call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA2, 3) write (*,'(10(I3))') ila2 call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3) write (*,'(10(I3))') ila1 if (any(ila1 /= ila2)) call abort() end yields 9 9 6 2 4 9 2 9 6 10 17 18 11 36 77 22 39 16 41 18 17 18 11 4 13 22 7 16 9 18 17 18 11 36 77 22 39 16 41 18 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug c/35733] New: Can't compile gcc 4.3.0 on old celeron processor (4.2.3 is ok)
Linux 2.6.24 glibc 2.7 Celeron (Mendocino) - 466MHz When i try to compile gcc 4.3.0, I get the following (gcc 4.2.3 compiles perfectly, but 4.3.0 doesn't): /home/fraga/b/./gcc/xgcc -B/home/fraga/b/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc-4.3.0/libgcc -I../../../gcc-4.3.0/libgcc/. -I../../../gcc-4.3.0/libgcc/../gcc -I../../../gcc-4.3.0/libgcc/../include -I../../../gcc-4.3.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _popcountsi2.o -MT _popcountsi2.o -MD -MP -MF _popcountsi2.dep -DL_popcountsi2 -c ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__popcountsi2': ../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c:799: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_popcountsi2.o] Error 1 make[3]: Leaving directory `/home/fraga/b/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/fraga/b' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/fraga/b' make: *** [bootstrap] Error 2 -- Summary: Can't compile gcc 4.3.0 on old celeron processor (4.2.3 is ok) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fragabr at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35733
[Bug c++/35734] New: [4.3/4.4 regression] ICE with copy constructor in derived class
The following valid code snippet triggers an ICE since GCC 4.3.0
when compiled with -W:
=
struct A
{
A();
templatetypename T A(const T);
};
struct B : A
{
B(const B) {}
};
=
bug.cc: In copy constructor 'B::B(const B)':
bug.cc:9: internal compiler error: tree check: expected function_decl, have
template_decl in type_has_user_nondefault_constructor, at cp/class.c:4063
Please submit a full bug report, [etc.]
In earlier versions we issued the warning:
bug.cc: In copy constructor 'B::B(const B)':
bug.cc:9: warning: base class 'struct A' should be explicitly initialized in
the copy constructor
--
Summary: [4.3/4.4 regression] ICE with copy constructor in
derived class
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug target/35733] Can't compile gcc 4.3.0 on old celeron processor (4.2.3 is ok)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-28 17:33 --- How did you configure GCC? How did you invoke make? How did you configure/build GMP/MPFR ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35733
[Bug middle-end/34226] [4.3/4.4 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #12 from mstein dot lists at googlemail dot com 2008-03-28
17:34 ---
A simple
'int main (int argc, char *argv[]) { return 0; }'
still fails with error: in default_secondary_reload, at
targhooks.c:612 in rev. 133684 (trunk).
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
CC||mstein dot lists at
||googlemail dot com, aoliva
||at gcc dot gnu dot org,
||aldyh at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-28 17:37 --- Manuel, Jason, was probably introduced by your patch: 2008-02-14 Manuel Lopez-Ibanez [EMAIL PROTECTED] Jason Merrill [EMAIL PROTECTED] PR c++/5645 PR c++/11159 * class.c (type_has_user_nondefault_constructor): New fn. * cp-tree.h: Declare it. * init.c (emit_mem_initializers): Use it for -W warning about missing base initializer. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com, ||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug middle-end/35400] [4.4 Regression] -Wtype-limits -O2 causes ICE tree check: expected ssa_name, have addr_expr in get_value_range, at tree-vrp.c:469
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-03-28 17:44
---
A short C++ testcase I ran into:
struct A
{
A();
~A();
};
void foo()
{
A x[1];
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35400
[Bug middle-end/35400] [4.4 Regression] -Wtype-limits -O2 causes ICE tree check: expected ssa_name, have addr_expr in get_value_range, at tree-vrp.c:469
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-03-28 18:13
---
Here's a reduced C testcase (fuirther reduced from PR35663):
===
struct A
{
struct A *p;
};
int foo(const struct A *q)
{
return q-p == q;
}
void bar(int);
void baz()
{
struct A a;
while (foo(a))
bar(foo(a));
}
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35400
[Bug target/35735] New: error in default_secondary_reload, at targhooks.c:649
Hi, compiling newlib now fails with: xgcc -c -O1 ldtoa-delta.c /home/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c: In function '_ldtoa_r': /home/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c:2857: internal compiler error: in default_secondary_reload, at targhooks.c:649 rev: 133684 -- Summary: error in default_secondary_reload, at targhooks.c:649 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein dot lists at googlemail dot com GCC host triplet: x86_64-linux-gnu GCC target triplet: mn10300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35735
[Bug c/35736] New: [4.4 regression] ICE with continue and -Wall
The following valid code snippet triggers an ICE on mainline
when compiled with -Wall:
=
void foo()
{
while (1)
for (;;({ continue; }))
;
}
=
bug.c: In function 'foo':
bug.c:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared between 2008-03-15 and 2008-03-20.
The C++ frontend is not affected.
--
Summary: [4.4 regression] ICE with continue and -Wall
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
[Bug c/35736] [4.4 regression] ICE with continue and -Wall
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
[Bug target/35735] error in default_secondary_reload, at targhooks.c:649
--- Comment #1 from mstein dot lists at googlemail dot com 2008-03-28 18:23 --- Created an attachment (id=15393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15393action=view) delta-reduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35735
[Bug tree-optimization/35737] New: [4.3/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
The following valid code snippet triggers an ICE since GCC 4.2.0
when compiled with -O:
=
#include setjmp.h
jmp_buf buf;
int foo()
{
__complex__ int i = 0;
if (__builtin_setjmp(buf))
{
i = 1;
bar();
}
return i == 0;
}
=
Corrupt SSA across abnormal edge BB2-BB7
Argument 0 (0) is not an SSA_NAME.
bug.c: In function 'foo':
bug.c:6: internal compiler error: SSA corruption
Please submit a full bug report, [etc.]
Maybe related to PR35314.
--
Summary: [4.3/4.3/4.4 regression] ICE with __builtin_setjmp and
complex variable
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug tree-optimization/35737] [4.3/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-28 18:33:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug c/35738] New: ICE with #pragma omp atomic and conversion from pointer to int
The following valid code snippet triggers an ICE since GCC 4.2.0
when compiled with -fopenmp:
=
int foo();
void bar()
{
int i;
#pragma omp atomic
i += foo;
}
=
bug.c: In function 'bar':
bug.c:7: internal compiler error: in default_conversion, at c-typeck.c:1759
Please submit a full bug report, [etc.]
Without -fopenmp I only get a warning:
bug.c: In function 'bar':
bug.c:7: warning: assignment makes integer from pointer without a cast
The C++ frontend is not affected (you have to add -fpermissive to make it
compile).
--
Summary: ICE with #pragma omp atomic and conversion from pointer
to int
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, openmp
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35738
[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-03-28 18:54 --- Patches: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01803.html http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01811.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
[Bug c/35739] New: [4.3/4.4 regression] ICE with _Decimal128 and va_list
The following valid code snippet triggers an ICE since GCC 4.3.0
when compiled with -fmudflap -O:
=
_Decimal128 foo(int n, ...)
{
int i;
_Decimal128 j;
__builtin_va_list va;
__builtin_va_start(va,n);
for (i = 0; i n; i++)
j += __builtin_va_arg(va,_Decimal128);
__builtin_va_end(va);
return j;
}
=
bug.c: In function 'foo':
bug.c:2: error: invalid operand to binary operator
retval
bug.c:2: internal compiler error: verify_stmts failed
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with _Decimal128 and va_list
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug fortran/35740] New: a = conjg(transpose(a)) still gives wrong results, see bug 31994
conjg(transpose(a)) still gives wrong results, if it is assigned to a. transpose(conjg(a)) works. program main implicit none complex, dimension(2,2) :: a,b,c a(1,1) = (1.,1.) a(2,1) = (2.,2.) a(1,2) = (3.,3.) a(2,2) = (4.,4.) print *, original: ,a b = conjg(transpose(a)) print *, H(a) - once wrong, now right: ,b c = transpose(a) c = conjg(c) print *, H(a) - right: ,c a = conjg(transpose(a)) print *, H(a) - still wrong: ,a a = transpose(c) a = conjg(a) a = transpose(conjg(a)) print *, H(a) - hack around: ,a END program main gfortran -v: Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-1) -- Summary: a = conjg(transpose(a)) still gives wrong results, see bug 31994 Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominik dot muth at gmx dot de GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35740
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #46 from rguenth at gcc dot gnu dot org 2008-03-28 19:18 --- Ok, I didn't really expect that ;) Some new background information. With the middle-end type-system work we now omit conversions from sub-types T' to their base-types T. Thus we have the three cases T' sub; T x; x = sub; (1) sub = (T')x; (2) x = VIEW_CONVERT_EXPR T(sub); (3) where VRP for the simple copy (1) does not restrict x value range based on the T's TYPE_MIN/MAX_VALUE (but it should). For (2) the same is true (though the conversion is _not_ truncating for out of bound values, so I am not sure if this doesn't break something). But for both (1) and (2) holds that a variable of type T' can be assumed to have a value range restricted by its TYPE_MIN/MAX_VALUE. Case (3) is special in that it is a propagation barrier, thus x will get a varying value range. We could do better here if we knew that subs value range was not restricted by its TYPE_MIN/MAX_VALUE only. I don't know if this is really the best setup to optimize Ada range checks, or if we should always fall back to the base types TYPE_MIN/MAX_VALUE range and use the type defined range of the sub-types T' only in special places like for example for the initial value-range of T' variables default definitions (thus uninitialized values and function parameters where if I understand correctly in Ada the caller ensures that the value is in range). Of course this wouldn't work very well in combination with inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/35740] a = conjg(transpose(a)) still gives wrong results, see bug 31994
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35740
[Bug tree-optimization/30997] FRE does not simplify comparisons in COND_EXPRs
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-28 19:21 --- SCCVN now tries to simplify COND_EXPR conditions using their operands value number. This still doesn't remove redundant comparisons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30997
[Bug c++/35741] New: [4.2/4.3/4.4 regression] ICE with offsetof and references
The following (valid ?) code snippet triggers an ICE since GCC 4.2.0:
=
struct A
{
char c;
int i;
};
int j = __builtin_offsetof (A, i);
=
bug.cc:7: warning: invalid access to non-static data member 'A::i' of NULL
object
bug.cc:7: warning: (perhaps the 'offsetof' macro was used incorrectly)
bug.cc:7: internal compiler error: in fold_offsetof_1, at c-common.c:6838
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3/4.4 regression] ICE with offsetof and
references
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
[Bug c++/35741] [4.2/4.3/4.4 regression] ICE with offsetof and references
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35741
[Bug fortran/35723] Can't use run-time array element in character declaration
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 19:40 --- Confirmed. A simple patch would be the following: Index: expr.c === --- expr.c (Revision 133693) +++ expr.c (Arbeitskopie) @@ -2502,6 +2502,7 @@ check_restricted (gfc_expr *e) || sym-attr.use_assoc || sym-attr.dummy || sym-attr.implied_index + || sym-attr.flavor == FL_PARAMETER || sym-ns != gfc_current_ns || (sym-ns-proc_name != NULL sym-ns-proc_name-attr.flavor == FL_MODULE) However, this also accepts the following invalid program (note the i): program try_vf0016 callvf0016( 1, 2, 3) end SUBROUTINE VF0016(nf1,nf2,nf3) CHARACTER(LEN=9,KIND=1),DIMENSION(3) , PARAMETER $ :: TEST_STRINGS = $ (/' HI','ABC ',' CDEFG '/) integer :: i = 2 CHARACTER :: TEST_ARRAY $(LEN_TRIM(ADJUSTL(TEST_STRINGS(i))), ! changing nf1 to 1 fixes it $ SUM(LEN_TRIM(ADJUSTL(TEST_STRINGS))), $ LEN_TRIM(ADJUSTL(ADJUSTR(TEST_STRINGS(3, $ SUM(LEN_TRIM(ADJUSTL(ADJUSTR(TEST_STRINGS(NF1:NF3:NF2) ) print *, 2, 10, 5, 7 print *, shape (test_array) end We therefore need to loop over expr-ref and check_restricted() these expressions as well. I think that we can throw in another half a dozen checks as well. ;-) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-03-28 19:40:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35723
[Bug fortran/35740] a = conjg(transpose(a)) still gives wrong results, see bug 31994
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 19:58 --- Confirm. There seems to be a temporary missing. Paul, you have fixed PR 31994, do you have an idea here? The problem seems to be in general expressions of this type: array = function(transpose(array)) where function() can be, e.g., sin() and the data type, e.g., real since then no temporary is created. If possible, we should backport a fix to 4.2 and 4.3. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-28 19:58:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35740
[Bug c/35742] New: [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'goto_expr' not supported by pp_c_expression
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.1.0:
=
void foo()
{
for (;;)
({break;})();
}
=
#'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:4: error: called object is not a function
--
Summary: [4.1/4.2/4.3/4.4 regression] Broken diagnostic:
'goto_expr' not supported by pp_c_expression
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 35441
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35742
[Bug c/35742] [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'goto_expr' not supported by pp_c_expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35742
Priorites for PR 35435 and PR 35441
Hi Joseph, on March 15 you changed to priority of PR 35435 and PR 35441 to P4. IMHO this is not in line with our current policy: * PR 35435 is not an error-recovery bug (i.e. we don't issue a valid error message before the ICE). So this should rather be P2, I think. * PR 35441 is a diagnostic bug, in which completely garbled diagnostics are emitted. This is a user-visible regression. Richard Guenther changed the related bugs PR 35442 and 35443 to P2, which I think is the right setting. Would you mind changing the priorities? Or explain why P4 is the correct setting after all? Thanks, Volker
Re: Priorites for PR 35435 and PR 35441
On Fri, 28 Mar 2008, Volker Reichelt wrote: Hi Joseph, on March 15 you changed to priority of PR 35435 and PR 35441 to P4. IMHO this is not in line with our current policy: * PR 35435 is not an error-recovery bug (i.e. we don't issue a valid error message before the ICE). So this should rather be P2, I think. * PR 35441 is a diagnostic bug, in which completely garbled diagnostics are emitted. This is a user-visible regression. Richard Guenther changed the related bugs PR 35442 and 35443 to P2, which I think is the right setting. Would you mind changing the priorities? Or explain why P4 is the correct setting after all? I made a judgement of how significant I felt the bugs were (which includes questions of how likely they are to affect users). If you think continued presence of these bugs in Stage 3 should delay moving to regression-only mode for 4.4 (which is what the choice of P2 or P4 is about), feel free to set them back to P3 for another RM to look at them. -- Joseph S. Myers [EMAIL PROTECTED]
[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-03-28 20:58 --- (In reply to comment #2) (In reply to comment #1) ld is running at this time so I doubt this is a GCC bug. The Pid it is referring to (Pid 18929 received a SIGSEGV for stack growth failure.) is /opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc. Seems to be recursing in cancel_option until stack runs out: Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555) at /opt/build/gcc-4.2.3/gcc/opts-common.c:118 118 if (cl_options [next_opt_idx].neg_index == opt_idx) (gdb) n 121 if (cl_options [next_opt_idx].neg_index != orig_next_opt_idx) (gdb) 122 return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index, (gdb) Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555) at /opt/build/gcc-4.2.3/gcc/opts-common.c:118 118 if (cl_options [next_opt_idx].neg_index == opt_idx) (gdb) 121 if (cl_options [next_opt_idx].neg_index != orig_next_opt_idx) (gdb) 122 return cancel_option (opt_idx, cl_options [next_opt_idx].neg_index, (gdb) Breakpoint 5, cancel_option (opt_idx=30, next_opt_idx=0, orig_next_opt_idx=555) at /opt/build/gcc-4.2.3/gcc/opts-common.c:118 118 if (cl_options [next_opt_idx].neg_index == opt_idx) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
[Bug fortran/35743] New: allocate negative memory for zero-sized WHERE construct
The following program fails when rg0025 attempts to allocate a negative amount of memory under windows XP. It doesn't abort when the array subscripts are explicit constants instead of variables. Dick Hendrickson program try_rg0025 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] logical lda(5) lda = (/ (i/2*2 .ne. I, i=1,5) /) call xx0025(lda, 1, 2, 3, 5, 6, -1, -2) !works call rg0025(lda, 1, 2, 3, 5, 6, -1, -2) !fails end program SUBROUTINE XX0025(LDA,nf1,nf2,nf3,nf5,nf6,mf1,mf2) type unseq real r end type unseq TYPE(UNSEQ) TDA1L(6) LOGICAL LDA(NF5) TDA1L(1:6)%r = 1.0 WHERE (LDA(6:3)) TDA1L(-1:5:-1) = TDA1L(6:2) ENDWHERE print *, 'end of xx0025' END SUBROUTINE SUBROUTINE RG0025(LDA,nf1,nf2,nf3,nf5,nf6,mf1,mf2) type unseq real r end type unseq TYPE(UNSEQ) TDA1L(6) LOGICAL LDA(NF5) TDA1L(1:6)%r = 1.0 WHERE (LDA(NF6:NF3)) TDA1L(MF1:NF5:MF1) = TDA1L(NF6:NF2) ENDWHERE END SUBROUTINE C:\g_experiments\gfortrangfortran rg0025.f C:g_experiments\gfortrana end of xx0025 Fortran runtime error: Attempt to allocate a negative amount of memory. -- Summary: allocate negative memory for zero-sized WHERE construct Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35743
[Bug c/35744] New: [4.1/4.2/4.3/4.4 regression] ICE attributes for invalid types
The following invalid code snippets triggers an ICE since GCC 4.1.0:
=
struct A
{
void x[1] __attribute__((packed));
};
=
bug.c:3: error: declaration of 'x' as array of voids
bug.c:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in handle_packed_attribute, at c-common.c:4653
Please submit a full bug report, [etc.]
Also other attributes applied to invalid variables cause ICEs
in various places, e.g.
=
typedef char x[N] __attribute__((aligned(4)));
=
bug.c:1: error: 'N' undeclared here (not in a function)
bug.c:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_variant_type_copy, at tree.c:4180
Please submit a full bug report, [etc.]
=
void x[1] __attribute__((vector_size(8)));
=
bug.c:1: error: declaration of 'x' as array of voids
bug.c:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in handle_vector_size_attribute, at c-common.c:6070
Please submit a full bug report, [etc.]
=
void x[1] __attribute__((may_alias));
=
bug.c:1: error: declaration of 'x' as array of voids
bug.c:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in decl_attributes, at attribs.c:355
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3/4.4 regression] ICE attributes for invalid
types
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug fortran/35745] New: Divide incorrectly extracted from WHERE block?; run time abort
The following program aborts at run-time opening a box that says a.exe has encountered a problem and needs to close. We are sorry for the inconvenience. And then offers to send an error report to Microsoft. I believe the problem is the extraction of the 1/NF0 from within the WHERE block. program RZ0048 INTEGER IDA(10) REAL RDA(10) RDA= 1.0 nf0 = 3 WHERE (RDA -15.0) IDA = 1/NF0 + 2 ENDWHERE print *, 'first where completed' nf0 = 0 WHERE (RDA -15.0) IDA = 1/NF0 + 2 ENDWHERE END -- Summary: Divide incorrectly extracted from WHERE block?; run time abort Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35745
[Bug c/35744] [4.1/4.2/4.3/4.4 regression] ICE attributes for invalid types
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-28 21:45 --- Mine. Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01822.html -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||03/msg01822.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-28 21:45:42 date|| Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug c/35746] New: [4.3/4.4 regression] ICE with undefined variables
The following invalid code snippets triggers an ICE since GCC 4.3.0:
==
int foo(int i);
void bar()
{
__complex__ int i;
X j;
if (i = foo(j))
;
}
==
bug.c: In function 'bar':
bug.c:6: error: 'X' undeclared (first use in this function)
bug.c:6: error: (Each undeclared identifier is reported only once
bug.c:6: error: for each function it appears in.)
bug.c:6: error: expected ';' before 'j'
bug.c:8: error: 'j' undeclared (first use in this function)
bug.c:8: internal compiler error: in create_tmp_from_val, at gimplify.c:535
Please submit a full bug report, [etc.]
The C++ frontend is not affected.
--
Summary: [4.3/4.4 regression] ICE with undefined variables
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c/35746] [4.3/4.4 regression] ICE with undefined variables
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c++/35747] New: [4.3/4.4 regression] ICE with undefined variable in statement expression
The following invalid code snippets triggers an ICE since GCC 4.3.0:
=
void foo()
{
({ i; ({ i; }); 0; });
}
=
bug.cc: In function 'void foo()':
bug.cc:3: error: 'i' was not declared in this scope
gimplification failed:
statement_list 0x402277c4
type void_type 0x401a94e0 void VOID
align 8 symtab 0 alias set -1 canonical type 0x401a94e0
pointer_to_this pointer_type 0x401a9548
head (nil) tail (nil) stmts
bug.cc:3: internal compiler error: gimplification failed
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with undefined variable in
statement expression
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
[Bug c/35748] New: ICE with cast to invalid union
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
union U { void x[1]; };
void foo()
{
(union U)0;
}
=
bug.c:1: error: declaration of 'x' as array of voids
bug.c: In function 'foo':
bug.c:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_c_cast, at c-typeck.c:3631
Please submit a full bug report, [etc.]
--
Summary: ICE with cast to invalid union
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35748
[Bug c/35749] New: Mudflap false violation
This is my code that is generating a false violation when compiled with mudflap
and the following options
export MUDFLAP_OPTIONS='-mode-check -viol-segv -backtrace=4 -verbose-violations
-check-initialization'
#include stdio.h
#include stdlib.h
#include errno.h
#include dirent.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
int main()
{
struct dirent **namelist;
struct stat statinfo;
int n=0, i;
n=scandir(/d/ttt/,namelist,NULL,alphasort);
if(n0)
{
printf(ERROR scandir: %s\n, strerror(errno));
return 0;
}
else
{
printf(n %d\n, n);
}
while(n--)
{
printf(namelist[%d]-d_name '%s'\n, n, namelist[n]-d_name);
memset(statinfo, 0, sizeof(statinfo));
stat(namelist[n]-d_name,statinfo);
free(namelist[n]);
}
free(namelist);
return 0;
}
And here is the false violation reported
***
mudflap violation 1 (check/read): time=1206741830.906553 ptr=0x80cf0db size=10
pc=0xb7dec8ad location=`(stat path)'
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7dec8ad]
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__mfwrap_stat+0x136)
[0xb7df2a46]
./scandir(main+0x3f2) [0x8048d8e]
Nearby object 1: checked region begins 11B into and ends 20B into
mudflap object 0x80cf110: name=`malloc region'
bounds=[0x80cf0d0,0x80cf0e7] size=24 area=heap check=1r/0w liveness=1
alloc time=1206741830.906135 pc=0xb7dec2fd
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__mf_register+0x3d)
[0xb7dec2fd]
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__wrap_malloc+0xe0)
[0xb7ded7c0]
/lib/libc.so.6(scandir+0x8f) [0xb7d43541]
./scandir(main+0x97) [0x8048a33]
Nearby object 2: checked region begins 2008B after and ends 2017B after
mudflap dead object 0x80ce948: name=`malloc region'
bounds=[0x80cd8e8,0x80ce903] size=4124 area=heap check=0r/0w liveness=0
alloc time=1206741830.905913 pc=0xb7dec2fd
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__mf_register+0x3d)
[0xb7dec2fd]
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__wrap_malloc+0xe0)
[0xb7ded7c0]
/lib/libc.so.6 [0xb7d43031]
/lib/libc.so.6(opendir+0x5d) [0xb7d430f6]
dealloc time=1206741830.906347 pc=0xb7dec2a6
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__mf_unregister+0x36)
[0xb7dec2a6]
/opt/miro_gcc/usr/local/lib/libmudflap.so.0(__real_free+0x80)
[0xb7ded090]
/lib/libc.so.6(closedir+0x24) [0xb7d4314c]
/lib/libc.so.6(scandir+0x139) [0xb7d435eb]
number of nearby objects: 2
Segmentation fault (core dumped)
--
Summary: Mudflap false violation
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eugen at familiamorjolic dot ro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35749
[Bug fortran/35745] Divide incorrectly extracted from WHERE block?; run time abort
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-28 22:05 --- Confirm. Valgrind shows: Process terminating with default action of signal 8 (SIGFPE): dumping core Integer divide by zero at address 0x40274EADB at 0x4008C6: MAIN__ (ghfhgk.f90:15) Divide incorrectly extracted from WHERE block? Yes and no. The compiler essentially transforms (as -fdump-tree-original shows) WHERE (RDA -15.0) IDA = 1/NF0 + 2 ENDWHERE into TMP = 1/NF0 + 2 WHERE (RDA -15.0) IDA = TMP ENDWHERE which is the reason for the integer divide by zero and shows that moving constant expressions out of a loop is not always a good idea. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-28 22:05:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35745
[Bug c/35750] New: ICE with invalid old-style parameter declaration
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
void foo(int[]);
void foo(x) int x[](); {}
=
bug.c: In function 'foo':
bug.c:2: error: declaration of 'x' as array of functions
bug.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in store_parm_decls_oldstyle, at c-decl.c:6486
Please submit a full bug report, [etc.]
--
Summary: ICE with invalid old-style parameter declaration
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35750
[Bug c/35751] New: ICE with invalid variable after #pragma omp parallel
The following invalid code snippet triggers an ICE since GCC 4.2.0:
=
void foo(int i)
{
extern int a[i];
#pragma omp parallel
a[0] = 0;
}
=
bug.c: In function 'foo':
bug.c:3: error: object with variably modified type must have no linkage
bug.c:3: error: storage size of 'a' isn't constant
bug.c:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: ICE with invalid variable after #pragma omp parallel
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-03-28 22:12 --- What is interesting is that j__target_type___XDLU_10__20 is a unsigned sub type with range [10, 20] of a signed base type with range [-128, 127]. So, we enter compare_values ((js__TtB)20, (j__target_type___XDLU_10__20)128) (both types have a precision of 8 bits, but the out-of-range value 128 is not representable in the base type, but is interpreted as -128). So, why is this range check if (target_first_66 == 128) goto bb 7; else goto bb 8; bb 7: __gnat_rcheck_12 (join_equal.adb, 15); using a value not representable in the base type? The TYPE_MIN/MAX_VALUEs are of the type of the base type, so target_first_66s value range is [10, 20] at the point of this comparison. Is this supposed to be a comparison with -128 or with 128? That is, is this target_first_66 == TYPE_MIN_VALUE (js__TtB) ? I guess so. The problem is that we try to compare different typed values here, the 10 and 20 of signed base type and the 128 of unsigned sub type. If we for the comparison canonicalize the 128 to the signed base type (which is the only thing that makes sense) we get an overflow value as it wraps to -128 and the comparison result will be ignored because it assumes that signed overflow is undefined. Bah. So let's try avoiding setting the overflow flag for conversions from a sub type to its base type. Then I have a patch that evaluates target_first_66 == 128 to false based on the initial value range idea for default SSA_NAMEs and the only remaining range checks are grep gnat_rcheck j.ads.127t.optimized __gnat_rcheck_04 (join_equal.adb, 13); __gnat_rcheck_12 (join_equal.adb, 29); __gnat_rcheck_12 (join_equal.adb, 39); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/35699] [4.3/4.4 regression] run-time abort writing zero sized section to direct access file
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-03-28 22:14 --- Subject: Bug 35699 Author: jvdelisle Date: Fri Mar 28 22:13:17 2008 New Revision: 133699 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133699 Log: 2008-03-28 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/35699 * io/transfer.c (write_buf): Don't pad the record, just return if the data is NULL. (next_record_w): If there are bytes left in the record for unformatted direct I/O, pad out the record with zero bytes. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35699
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #48 from rguenth at gcc dot gnu dot org 2008-03-28 22:14 --- Created an attachment (id=15394) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15394action=view) patch for comment #47 This is what I was playing with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/35699] [4.3/4.4 regression] run-time abort writing zero sized section to direct access file
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-28 22:17 --- Subject: Bug 35699 Author: jvdelisle Date: Fri Mar 28 22:16:29 2008 New Revision: 133700 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133700 Log: 2008-03-28 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35699 * gfortran.dg/direct_io_10.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/direct_io_10.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35699
[Bug bootstrap/35752] New: Combined gcc + binutils source tree doesn't bootstrap
I combined the current gcc and binutils mainlines into a combined gcc + binutils source tree. When I tried to bootstrap it on Linux/ia32 and Linux/Intel64 with shared library enabled, it went to an infinite loop when as or ld from stage 2 was used. The problem is ld-new tries to use itself to relink itself when it is invoked first time. How should gcc and libtool handle it properly? I think collect-ld should be modified. -- Summary: Combined gcc + binutils source tree doesn't bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-03-28 22:35 --- As of The TYPE_MIN/MAX_VALUEs are of the type of the base type, so target_first_66s value range is [10, 20] at the point of this comparison. Is this supposed to be a comparison with -128 or with 128? That is, is this target_first_66 == TYPE_MIN_VALUE (js__TtB) ? I guess so. This is fold simplifying (js__TtB) target_first == -128 to target_first == 128 via fold_sign_changed_comparison. And thus PR31023 which now also blocks this PR. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31023 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #50 from baldrick at free dot fr 2008-03-28 22:42 --- Subject: Re: VRP fails to eliminate range checks in Ada code T' sub; T x; x = sub; (1) sub = (T')x; (2) x = VIEW_CONVERT_EXPR T(sub); (3) where VRP for the simple copy (1) does not restrict x value range based on the T's TYPE_MIN/MAX_VALUE (but it should). For (2) the same is true (though the conversion is _not_ truncating for out of bound values, so I am not sure if this doesn't break something). Ada never does (2) unless the value of x is in the range of sub, so this should be ok for assignments coming straight out of the Ada f-e. It might be that fold, for example, generates problematic versions of (2) however. I have no idea if this can happen. I don't know if this is really the best setup to optimize Ada range checks, It seems reasonable. Only using range info for function arguments would side-step the fold-doesn't-use-base-types problem though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c++/35708] jump to label enters catch block
--- Comment #3 from bruno at clisp dot org 2008-03-28 22:46 --- you are entering a scope that has objects constructed. Can you point out the sections in the ISO C++ standard that say that an 'if' statement can create the scope for some objects? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #4 from bruno at clisp dot org 2008-03-28 22:48 --- The bug also occurs with g++ 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #51 from baldrick at free dot fr 2008-03-28 22:48 --- Subject: Re: VRP fails to eliminate range checks in Ada code This is fold simplifying (js__TtB) target_first == -128 to target_first == 128 via fold_sign_changed_comparison. Right, that was my instant guess. The Ada f-e is pretty systematic about converting everything to the base type before doing comparisons. While fold happily creates the kind of strangeness you observed. And thus PR31023 which now also blocks this PR. In fact PR31023 was split out of this because of exactly this kind of problem in the testcase! I should have marked it as blocking this one, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/34714] ICE-on-invalid in gfc_conv_descriptor_dtype
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-28 22:58 --- Subject: Bug 34714 Author: dfranke Date: Fri Mar 28 22:57:25 2008 New Revision: 133701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133701 Log: gcc/fortran: 2008-03-28 Daniel Franke [EMAIL PROTECTED] Paul Richard Thomas [EMAIL PROTECTED] PR fortran/34714 * primary.c (match_variable): Improved matching of function result variables. * resolve.c (resolve_allocate_deallocate): Removed checks if the actual argument for STAT is a variable. gcc/testsuite: 2008-03-28 Daniel Franke [EMAIL PROTECTED] PR fortran/34714 * gfortran.dg/alloc_alloc_expr_3.f90: New test. * gfortran.dg/allocate_stat.f90: Adjusted error-match text. * gfortran.dg/func_assign.f90: Likewise. * gfortran.dg/implicit_11.f90: Likewise. * gfortran.dg/proc_assign_1.f90: Likewise. * gfortran.dg/proc_assign_2.f90: Likewise. * gfortran.dg/procedure_lvalue.f90: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/alloc_alloc_expr_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_stat.f90 trunk/gcc/testsuite/gfortran.dg/func_assign.f90 trunk/gcc/testsuite/gfortran.dg/implicit_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_assign_1.f90 trunk/gcc/testsuite/gfortran.dg/proc_assign_2.f90 trunk/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34714
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-03-28 22:58 --- I'm now testing a variant of the patch that fixes fold_sign_changed_comparison and just initializes incoming parameter value-ranges based on their types. This seems to do the same range-check removals and looks like an overall sane change. I assume when inlining we will see the range check that assures the function parameters are in-range, right? So even for that case we should be able to do the same simplifications. Can you cook up a testcase that shows this case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/34714] ICE-on-invalid in gfc_conv_descriptor_dtype
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-28 23:02 --- Fixed in trunk, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords|patch | Known to work||4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34714
