[Bug regression/36811] New: [4.3/4.4 regression] endless (?) loop building with -O3
seen with the 4.3 branch and trunk 20080711 on i486-linux-gnu, the following preprocessed source doesn't finish to build after 120 cpu minutes. works with 4.2.4, or with -O2. -- Summary: [4.3/4.4 regression] endless (?) loop building with -O3 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36811
[Bug regression/36811] [4.3/4.4 regression] endless (?) loop building with -O3
--- Comment #1 from doko at ubuntu dot com 2008-07-12 07:07 --- Created an attachment (id=15903) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15903action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36811
[Bug regression/36811] [4.3/4.4 regression] endless (?) loop building with -O3
--- Comment #2 from doko at ubuntu dot com 2008-07-12 07:09 --- command to build: $ gcc -g -O3 -c utils.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36811
[Bug target/36806] [4.4 Regression] Broken IOs at rev. 137644 on i686-apple-darwin9
--- Comment #10 from dominiq at lps dot ens dot fr 2008-07-12 09:39 --- Formatted OPEN also hangs: open(unit=11,form='formatted') end It seems that all I/Os involving external files hang, but 'print *,' or 'write(tmp,*)' (where 'tmp' is an internal buffer) works. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|[4.4 Regression] Broken |[4.4 Regression] Broken IOs |unformatted IOs at rev. |at rev. 137644 on i686- |137644 on i686-apple-darwin9|apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug c++/36812] New: ICE: verify_stmts failed with -O -fipa-pta
compiling the attached preprocessed source, triggers an ICE with g++-4.4: [EMAIL PROTECTED]:~/workspace/nova$ g++-4.4 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --program-suffix=-4.4 Thread model: posix gcc version 4.4.0 20080703 (experimental) (GCC) compiled via: [EMAIL PROTECTED]:~/workspace/nova$ g++-4.4 -c -O -fipa-pta -march=core2 kernel_build.ii gives: /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/stl_list.h: In destructor âstd::listunsigned int, std::allocatorunsigned int ::~list()â: /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/stl_list.h:417: error: statement marked for throw, but doesnât _M_clear (D.353440_2); /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/stl_list.h:417: internal compiler error: verify_stmts failed sorry, for not providing a reduced test case, but i hope this is helpful anyway ... -- Summary: ICE: verify_stmts failed with -O -fipa-pta Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim at klingt dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36812
[Bug c++/36812] ICE: verify_stmts failed with -O -fipa-pta
--- Comment #1 from tim at klingt dot org 2008-07-12 10:47 --- Created an attachment (id=15904) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15904action=view) compressed pre-processed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36812
[Bug fortran/33221] Cannot declare variables of TYPE without components
--- Comment #6 from domob at gcc dot gnu dot org 2008-07-12 11:27 --- Subject: Bug 33221 Author: domob Date: Sat Jul 12 11:26:50 2008 New Revision: 137737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137737 Log: 2008-07-12 Daniel Kraft [EMAIL PROTECTED] * resolve.c (resolve_fl_derived): Allow pointer components to empty derived types fixing a missing part of PR fortran/33221. 2008-06-22 Daniel Kraft [EMAIL PROTECTED] * gfortran.dg/used_types_21.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33221
[Bug tree-optimization/36788] [4.4 Regression] ICE in loop_optimizer_init at -O3
--- Comment #4 from janus at gcc dot gnu dot org 2008-07-12 15:04 --- Rev. 137717 works again, and compiles the test case without any error. Has anyone fixed this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36788
[Bug tree-optimization/36788] [4.4 Regression] ICE in loop_optimizer_init at -O3
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-07-12 15:23 --- Has anyone fixed this? 2008-07-10 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-pre.c (create_expression_by_pieces): Add fold_convert calls. (eliminate): Ditto. (execute_pre): Call loop_optimizer_finalize in early exit. Moving to fixed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36788
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #15 from gcc at abeckmann dot de 2008-07-12 16:01 ---
Hi,
this bug (not searching for libgomp.spec in the correct place) is still present
in the gcc-4_3-branch as of today (r137745).
Configured on an amd64 Debian testing/unstable machine:
../gcc-4_3-branch/configure --prefix=/.../some/where/gcc-4.3.x
--enable-languages=c,c++
There are two (identical) libgomp.spec installed in .../gcc-4.3.x/lib{32,64}/
and after copying one to lib/ it is also found.
Andreas
--
gcc at abeckmann dot de changed:
What|Removed |Added
CC||gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug preprocessor/33305] We should warn about empty macro arguments
--- Comment #7 from tromey at gcc dot gnu dot org 2008-07-12 17:06 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug preprocessor/35055] missing path to finclude directory when compiling .F90 files
--- Comment #3 from tromey at gcc dot gnu dot org 2008-07-12 17:10 --- I tried this and it is fixed on trunk. Closing. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35055
[Bug preprocessor/15185] -M default target - -MT documentation
--- Comment #6 from tromey at gcc dot gnu dot org 2008-07-12 17:18 --- This was fixed for 4.3, and I think it unlikely that anyone will backport the doc fix. So, I am closing this. -- tromey 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=15185
[Bug preprocessor/20989] The -M option gives object file names without directory
--- Comment #7 from tromey at gcc dot gnu dot org 2008-07-12 17:19 --- This was fixed for 4.3 and I think it unlikely that anyone will backport the doc fix. So, I am closing this. -- tromey 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=20989
[Bug c++/36813] New: screwy diagnostic on ill-formed call from template with a local typedef
The second error message issued by gcc 4.3.0 for the ill-formed program below
looks wrong. I would expect it to read the same as the first one.
$ cat t.cpp g++ t.cpp
template class T struct A { };
template class T, class U struct B { typedef AT Y; };
template class T void foo (T*) { }
template class T, class U
void bar () {
foo (typename BT, U::Y ());
typedef typename BT, U::Y Y;
foo (Y ()); // line 11
}
int main () {
barint, Aint ();
}
t.cpp: In function void bar() [with T = int, U = Aint]:
t.cpp:15: instantiated from here
t.cpp:8: error: no matching function for call to foo(Aint)
t.cpp:11: error: no matching function for call to foo(bar() [with T = int, U =
Aint]::Y)
--
Summary: screwy diagnostic on ill-formed call from template with
a local typedef
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36813
[Bug c++/36813] screwy diagnostic on ill-formed call from template with a local typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-12 19:44 --- the error message is slightly wrongly written but this is true for any local typedef, I can find the other bug where templates are not involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36813
[Bug c++/15672] local function causes weird warning
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-07-12 19:46 --- *** Bug 36813 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672
[Bug c++/36813] screwy diagnostic on ill-formed call from template with a local typedef
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-12 19:46 --- *** This bug has been marked as a duplicate of 15672 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36813
[Bug c++/36814] New: G++ won't warn about an uninitialized value
Hello,
I've compiled the code below using `g++ -Wuninitialized -O test.cc -o test':
bool cMyClass::Init()
{
bool retval;
if (some_function())
{
// If the `goto' is executed, 'return retval;' will use the
// uninitialized value of 'retval'.
goto error;
}
retval = true;
error:
return retval;
}
The problem is explained in the code comments above.
I think that GCC is supposed to warn about this, is that correct?
Thanks, Jelle
--
Summary: G++ won't warn about an uninitialized value
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC build triplet: i386-undermydesk-freebsd
GCC host triplet: i386-undermydesk-freebsd
GCC target triplet: i386-undermydesk-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
[Bug bootstrap/36815] New: gnattools related error when building only c and fortran
With --enable-languages=c,fortran, system trys to build gnattools and fails with this error: gnu-make[2]: Entering directory `/home/delisle/gcc/obj44/gcc' gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44/gcc' /bin/sh: line 1: gnatls: not found gnu-make[2]: Entering directory `/home/delisle/gcc/obj44/gnattools' Cannot build gnattools while gnatlib is out of date or unbuilt gnu-make[2]: *** [../gcc/stamp-gnatlib] Error 1 gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44/gnattools' gnu-make[1]: *** [all-gnattools] Error 2 gnu-make[1]: Leaving directory `/home/delisle/gcc/obj44' gnu-make: *** [all] Error 2 Configured as follows: ../gcc44/configure --prefix=/home/delisle/gcc/usr --enable-64bit --with-as=/usr/local/bin/gnu-as --with-ld=/usr/local/bin/gnu-ld --enable-languages=c,fortran --disable-bootstrap --disable-libmudflap -- Summary: gnattools related error when building only c and fortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: -i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36815
[Bug bootstrap/36815] gnattools related error when building only c and fortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-12 20:14 --- Did you remove the Ada subdirectory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36815
[Bug c++/36816] New: error deducing template argument taking the address of rvalue reference template
Gcc 4.3.0 diagnoses the line marked error? in the program below.
I'd like to believe the program is well-formed and that the compiler should
be able to correctly deduce the template arguments from the initialed
expression without explicitly providing the template argument list.
template class T void f (T) { }
template class T void g (T) { }
template class T void h (T) { }
int main ()
{
{ void (*pf)(int)= f; } // okay
{ void (*pf)(int) = f; } // okay
{ void (*pf)(int) = f; } // okay
{ void (*pf)(int) = g; } // okay
{ void (*pf)(int) = h; } // okay
{ void (*pf)(int) = h; } // error?
{ void (*pf)(int) = hint; } // okay
// { void (*pf)(int) = hint; } // error!
// { void (*pf)(int) = hint; } // error!
}
t.cpp: In function int main():
t.cpp:14: error: no matches converting function h to type void (*)(int)
t.cpp:3: error: candidates are: templateclass T void h(T)
--
Summary: error deducing template argument taking the address of
rvalue reference template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36816
[Bug target/36782] php-5.2.5, error: unable to find a register to spill in class 'R0_REGS'
--- Comment #2 from kkojima at gcc dot gnu dot org 2008-07-12 23:46 --- Created an attachment (id=15905) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15905action=view) A reduced test case for -O1 -fpic -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36782
[Bug target/36782] [4.3/4.4 Regression] SH: spill failure in class 'R0_REGS' with -fpic
--- Comment #3 from kkojima at gcc dot gnu dot org 2008-07-12 23:53 --- I've added a reduced testcase and confirmed that 4.2.4 works too. The RTL dumps show what is going on in the problematic case. The backend creates a REG_EQUAL note for the GOT access and CSE pass locates a memory access after the result is set to R0 according to this note. Unfortunately this results a spill failure because the above memory access requires R0 for reload. The attached patch removes this note. I'll test it when 4.3/4.4 can be built for SH again. --- ORIG/trunk/gcc/config/sh/sh.md 2008-04-27 13:53:04.0 +0900 +++ INTEST/trunk/gcc/config/sh/sh.md2008-07-13 08:38:15.0 +0900 @@ -8880,9 +8880,6 @@ label: /* ??? Should we have a special alias set for the GOT? */ insn = emit_move_insn (operands[0], mem); - set_unique_reg_note (insn, REG_EQUAL, - XVECEXP (XEXP (operands[1], 0), 0, 0)); - DONE; }) -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.1 4.4.0 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2008-07-12 23:53:41 date|| Summary|php-5.2.5, error: unable to |[4.3/4.4 Regression] SH: |find a register to spill in |spill failure in class |class 'R0_REGS' |'R0_REGS' with -fpic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36782
[Bug target/36784] [4.3 Regression] g++ internal compiler error: in remove_insn, at emit-rtl.c:3601
--- Comment #2 from kkojima at gcc dot gnu dot org 2008-07-13 00:05 --- I've confirmed that 4.2.4 works and the patch suggested at #1 fixes this error on 4.3. I'll test it when 4.3 can be built for SH again. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.1 Known to work||4.2.4 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-07-13 00:05:32 date|| Summary|g++ internal compiler error:|[4.3 Regression] g++ |in remove_insn, at emit-|internal compiler error: in |rtl.c:3601 |remove_insn, at emit- ||rtl.c:3601 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36784
