[Bug c++/29727] [4.2/4.3/4.4 regression] ICE on invalid initializer for template member
--- Comment #8 from simartin at gcc dot gnu dot org 2008-10-05 07:27 --- PR37736 opened for the reject valid case (it's a different bug). Patch for the ICE submitted here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00134.html -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |simartin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-26 00:19:12 |2008-10-05 07:27:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29727
[Bug fortran/37706] [4.3, 4.4 Regression] ICE with use only and equivalent
--- Comment #7 from pault at gcc dot gnu dot org 2008-10-05 08:42 --- Subject: Bug 37706 Author: pault Date: Sun Oct 5 08:41:00 2008 New Revision: 140881 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140881 Log: 2008-10-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37706 * module.c (load_equiv): Check the module before negating the unused flag. 2008-10-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37706 * gfortran.dg/module_equivalence_4.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_equivalence_4.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug c++/37737] ICE on variadic template function
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-10-05 12:02
---
This variant also ice's in same place but issues error first:
ice2.cpp:
template
void f()
{
f();
}
template<>
void f() { }
int main()
{
f();
}
ice2.cpp:8: error: template-id f<> for void f() does not match any template
declaration
ice2.cpp: In function void f() [with U = char, T = ]:
ice2.cpp:12: instantiated from here
ice2.cpp:4: internal compiler error: tree check: accessed elt 1 of tree_vec
with 0 elts in get_innermost_template_args, at cp/pt.c:516
(note: both compiled with -std=c++0x)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
[Bug fortran/37706] [4.3, 4.4 Regression] ICE with use only and equivalent
--- Comment #8 from pault at gcc dot gnu dot org 2008-10-05 08:45 --- Fixed on trunk and 4.3. This one is so obvious that I decided not to wait to commit to 4.3. Lester, I see that you use overnight builds of 4.4; you should see the benefit right away then:-) Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug c++/37737] New: ICE on variadic template function
The following snippet ICE's:
void f() { }
template
void f(){ f(); }
int main()
{
f();
}
tree check:
accessed elt 1 of tree_vec with 0 elts in get_innermost_template_args
at cp/pt.c:516
Is this ice-on-valid or will f<>() not be picked up by the non-template
function?
--
Summary: ICE on variadic template function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfairles at gcc dot gnu dot org
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
[Bug c++/37737] ICE on variadic template function
--- Comment #2 from cfairles at gcc dot gnu dot org 2008-10-05 12:09 --- I believe these are both ice-on-invalid code. -- cfairles at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37737
[Bug fortran/37735] Allocatable components in vectors of derived types cause ICE on assignment
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-05 12:58 --- Confirmed on (powerpc|i686)-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-05 13:03 --- Confirmed on (powerpc|i686)-apple-darwin9. Since gfortran produces a wrong code, I think the "severity" should be increased to "major" or even "critical". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug ada/37572] compile Ada program fails (XML/Ada, 64 bit AMD)
--- Comment #6 from esigra at gmail dot com 2008-10-05 13:42 --- This problem went away for me when I upgraded to GCC 4.3.1 (Gentoo x86), so it seems to be fixed. -- esigra at gmail dot com changed: What|Removed |Added CC||esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
[Bug debug/37738] New: Fortran DW_TAG_common_block has incorrect placement/scope
gfortran: (1) Merges all common blocks into a single one. (2) Places this single common block into the first subroutine where it was used. Fix: (1) The scope of the common block is only the subroutine where it is present. Each subroutine should have its own DW_TAG_common_block. Accessing variable imported by a common block in different subroutine does not access the common block - it creates a local variable there. (2) (Placing the common block directly under CU not discussed - IMO wrong.) Intel Fortran compiler IMO does it right. subroutine a INTEGER*4 a_i common /block/a_i a_i = 1 end subroutine a subroutine b INTEGER*4 b_i common /block/b_i a_i = 3 b_i = 2 end subroutine b subroutine c INTEGER*4 a_i common /block/a_i if (a_i .ne. 2) call abort end subroutine c program abc call a call b call c end program abc /opt/intel/fce/10.1.008/bin/ifort <0>: Abbrev Number: 1 (DW_TAG_compile_unit) <1><68>: Abbrev Number: 3 (DW_TAG_subprogram) <2><8a>: Abbrev Number: 4 (DW_TAG_common_block) <3>: Abbrev Number: 5 (DW_TAG_variable) <1>: Abbrev Number: 3 (DW_TAG_subprogram) <2>: Abbrev Number: 6 (DW_TAG_variable) <2>: Abbrev Number: 4 (DW_TAG_common_block) <3><110>: Abbrev Number: 5 (DW_TAG_variable) <1><135>: Abbrev Number: 3 (DW_TAG_subprogram) <2><157>: Abbrev Number: 4 (DW_TAG_common_block) <3><16d>: Abbrev Number: 5 (DW_TAG_variable) <1><187>: Abbrev Number: 7 (DW_TAG_subprogram) The section .debug_info contains: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_language: 14 (Fortran 95) DW_AT_name: abc.f90 DW_AT_producer: Intel (R) Fortran Compiler Fixes RangesRelative <1><68>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_name: a <2><8a>: Abbrev Number: 4 (DW_TAG_common_block) DW_AT_name: block_ DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <3>: Abbrev Number: 5 (DW_TAG_variable) DW_AT_name: a_i DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <1>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_name: b <2>: Abbrev Number: 6 (DW_TAG_variable) DW_AT_name: a_i DW_AT_location: 2 byte block: 76 70(DW_OP_breg6: -16) <2>: Abbrev Number: 4 (DW_TAG_common_block) DW_AT_name: block_ DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <3><110>: Abbrev Number: 5 (DW_TAG_variable) DW_AT_name: b_i DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <1><135>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_name: c <2><157>: Abbrev Number: 4 (DW_TAG_common_block) DW_AT_name: block_ DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <3><16d>: Abbrev Number: 5 (DW_TAG_variable) DW_AT_name: a_i DW_AT_location: 9 byte block: 3 70 45 68 0 0 0 0 0 (DW_OP_addr: 684570) <1><187>: Abbrev Number: 7 (DW_TAG_subprogram) DW_AT_calling_convention: 2(program) DW_AT_name: abc GNU Fortran (GCC) version 4.4.0 20081005 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081005 (experimental), GMP version 4.2.2, MPFR version 2.3.1. <0>: Abbrev Number: 1 (DW_TAG_compile_unit) <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram) <2><4b>: Abbrev Number: 3 (DW_TAG_common_block) <3><5c>: Abbrev Number: 4 (DW_TAG_variable) <3><72>: Abbrev Number: 4 (DW_TAG_variable) <3><88>: Abbrev Number: 4 (DW_TAG_variable) <1>: Abbrev Number: 2 (DW_TAG_subprogram) <2>: Abbrev Number: 6 (DW_TAG_variable) <1>: Abbrev Number: 7 (DW_TAG_subprogram) The section .debug_info contains: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) < c> DW_AT_producer: (indirect string, offset: 0x1e): GNU Fortran 4.4.0 20081005 (experimental) <10> DW_AT_language: 14 (Fortran 95) <11> DW_AT_name: (indirect string, offset: 0x0): abc.f90 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram) <2f> DW_AT_name: a <2><4b>: Abbrev Number: 3 (DW_TAG_common_block) <4c> DW_AT_name: (indirect string, offset: 0x8): block <52> DW_AT_location: 9 byte block: 3 0 c 60 0 0 0 0 0 (DW_OP_addr: 600c00) <3><5c>: Abbrev Number: 4 (DW_TAG_variable) <5d> DW_AT_name: a_i <68> DW_AT_location: 9 byte block: 3 0 c 60 0 0 0 0 0 (DW_OP_addr: 600c00) <3><72>: Abbrev Number: 4 (DW_TAG_variable) <73>
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-10-05 15:33 --- Saw there also needless DW_OP_plus_uconst - it could be single DW_OP_addr for all the common block variables (which would make the GDB support a bit easier). program a2 INTEGER*4 a INTEGER*4 b common /block/a,b a = 1 a = 2 end program a2 <2><4d>: Abbrev Number: 3 (DW_TAG_common_block) <4e> DW_AT_name: (indirect string, offset: 0x46): block <54> DW_AT_location: 9 byte block: 3 e0 a 60 0 0 0 0 0 (DW_OP_addr: 600ae0) <3><5e>: Abbrev Number: 4 (DW_TAG_variable) <5f> DW_AT_name: a <68> DW_AT_location: 9 byte block: 3 e0 a 60 0 0 0 0 0 (DW_OP_addr: 600ae0) <3><72>: Abbrev Number: 4 (DW_TAG_variable) <73> DW_AT_name: b <7c> DW_AT_location: 11 byte block: 3 e0 a 60 0 0 0 0 0 23 4 (DW_OP_addr: 600ae0; DW_OP_plus_uconst: 4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug target/35574] [4.4 regression] unrecognizable insn generated for vector move
--- Comment #4 from kazu at gcc dot gnu dot org 2008-10-05 15:52 --- I'm taking this. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|kazu at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-05 17:28 --- Confirmed on 4.3 and 4.1.2 so not a regression. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-05 17:28:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration
--- Comment #15 from pault at gcc dot gnu dot org 2008-10-05 18:54 --- Subject: Bug 35680 Author: pault Date: Sun Oct 5 18:53:19 2008 New Revision: 140892 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140892 Log: 2008-10-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/35680 * gfortran.h : Add 'error' bit field to gfc_expr structure. * expr.c (check_inquiry): When checking a restricted expression check that arguments are either variables or restricted. (check_restricted): Do not emit error if the expression has 'error' set. Clean up detection of host-associated variable. 2008-10-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/35680 * gfortran.dg/transfer_array_intrinsic_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680
[Bug fortran/37319] FAIL the unexplained fix: gfortran.dg/function_kinds_5.f90
--- Comment #5 from pault at gcc dot gnu dot org 2008-10-05 19:03 --- (In reply to comment #4) > At r140286 with the patch in > http://gcc.gnu.org/ml/fortran/2008-09/msg00210.html, the failure is gone!-( > I cannot explain it, other than the old version using something that was not initialized, as you suggest. If you do not mind, since it has cleared and the testcase remains in place, I'll remove the regression label but will retain the PR. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-05 19:03:35 date|| Summary|[4.4 Regression] FAIL: |FAIL the unexplained fix: |gfortran.dg/function_kinds_5|gfortran.dg/function_kinds_5 |.f90|.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug bootstrap/37739] New: bootstrap broken with core gcc > gcc-4.2.x
Since a longer time bootstrap is broken for powerpc-unknown-linux-gnu, 32-bit at least. The interesting condition is, it only fails when the bootstrapping compiler is > 4.2.x, iow. 4.3.x and 4.4.x (Well 4.4 I did not confirm myself) The failure started with r132589, this commit itself does not contain a fault per se. It is just uncovering the issue. The failure manifests itself as: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp -lmpfr -lgmp /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o /usr/lib/gcc/ppc64-redhat-linux/4.3.0/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/gcc/ppc64-redhat-linux/4.3.0/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' c-lang.o: In function `VEC_tree_base_quick_insert': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_ordered_remove': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_block_remove': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_copy': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_safe_grow_cleared': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_free': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_copy': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/ppc64-redhat-linux/4.3.0/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_safe_grow_cleared': /home/andreast/devel/gcc/head-clean/gcc/gcc/tree.h:192: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[3]: Leaving directory `/home/andreast/devel/gcc/head-clean/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/andreast/devel/gcc/head-clean/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/andreast/devel/gcc/head-clean/objdir' make: *** [all] Error 2 The bootstrapping compiler has this version: [EMAIL PROTECTED] objdir]$ gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32
[Bug bootstrap/37739] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #1 from andreast at gcc dot gnu dot org 2008-10-05 19:25 --- Created an attachment (id=16463) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16463&action=view) workaround patch Workaround patch to make bootstrap working again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #13 from hjl dot tools at gmail dot com 2008-10-05 19:44 --- ira-merge branch is OK for i586-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00316.html It has this patch: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01955.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug middle-end/37731] [4.2/4.3/4.4 Regression] long long may not work correctly on 32bit host
-- hjl dot tools at gmail dot com changed: What|Removed |Added Priority|P3 |P1 Target Milestone|4.4.0 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37731
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #7 from pault at gcc dot gnu dot org 2008-10-05 20:26 --- (In reply to comment #6) > Jacques, > > Now that 4.3 is out of the door, I have no excuse. It's in the queue behind > completing my move to Barcelona, memory leaks in allocatable components + some > associated bugs and adding procedure pointers. Thus, don't hold your breath > but it's on the way. > We have had some discussion on the list about reforming array descriptors, which is what is needed here. However, this is a big job because the early gfortran developers made some unfortunate choices and left no 'reserved' fields. Quite aside from the coding job, it will wreck the gfortran API. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #8 from dodji at gcc dot gnu dot org 2008-10-05 21:30 --- Subject: Bug 37410 Author: dodji Date: Sun Oct 5 21:29:32 2008 New Revision: 140895 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140895 Log: 2008-09-30 Dodji Seketeli <[EMAIL PROTECTED]> gcc/ChangeLog: PR c++/37410 * dwarf2out.c (dwarf2out_imported_module_or_decl): Split this function in two, making it call a new and reusable dwarf2out_imported_module_or_decl() that takes the containing BLOCK of the declaration in argument. (dwarf2out_imported_module_or_decl_real): New function. (decls_for_scope, gen_decl_die, dwarf2out_decl): Take IMPORTED_DECL in account. * tree.def: Added IMPORTED_DECL node type. * tree.h: Added accessors for IMPORTED_DECL nodes. * tree.c (init_ttree): Initialise IMPORTED_DECL node type. gcc/cp/ChangeLog: PR c++/37410 * cp-gimplify.c (cp_gimplify_expr): For each USING_STMT make sure an IMPORTED_DECL node is added to the BLOCK_VARS list of the innermost containing BLOCK. gcc/testsuite/ChangeLog: PR c++/37410 * g++.dg/debug/dwarf2/imported-module.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/name-lookup.c trunk/gcc/dwarf2out.c trunk/gcc/print-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.def trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug bootstrap/37739] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #2 from schwab at suse dot de 2008-10-05 21:54 --- Another workaround is to build with optimisation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #9 from dodji at gcc dot gnu dot org 2008-10-05 22:54 --- Fixed in trunk -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
overloaded operator new and delete
I'm targeting an embedded Arm7 architecture. I've overridden single obj, array and placement new and delete. My problem is that the override delete is not called for a class obj when the obj is deleted (neither is the obj's destructor.) However, if I declare the class destructor as virtual, then the delete behavior works correctly. new and delete for integral types as well as dew/delete for arrays for objects with non-virtual destructors both work fine. I won't post the override code here yet since it works for all other instances except one. Anyone know what could cause this kind of behavior? Thanks. -- View this message in context: http://www.nabble.com/overloaded-operator-new-and-delete-tp19830255p19830255.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/37740] New: [C++0x] "foo f{...}" form compiles, but "new foo{...}" one doesn't
With the following piece of code:
==
struct integer
{
int i;
};
struct foo1
{
double d;
int i;
};
struct foo2
{
double d;
integer i;
};
int main(int argc, char **argv)
{
int i1 = 0;
integer i2{0};
foo1 f1{3.2, i1}; //ok
new foo1{3.2, i1}; //ok
foo2 f2{3.2, i2}; //ok
new foo2{3.2, i2}; //error, why?
return 0;
}
==
GCC 4.4 svn (4.4.0 20081005) can't compile "new foo2{...}" line:
==
$ g++ -std=c++0x main.cpp
main.cpp: In function 'int main(int, char**)':
main.cpp:53: error: could not convert
'{3.20017763568394002504646778106689453e+0, i2}' to 'foo2'
==
though the other lines are OK.
I didn't see anything about a difference between the two forms in the standard,
so I guess it is a GCC bug.
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages='c c++' --disable-nls :
(reconfigured) ../gcc/configure --enable-languages='c c++' : (reconfigured)
../gcc/configure --enable-languages='c c++' --enable-shared --disable-static
--disable-nls
Thread model: posix
gcc version 4.4.0 20081005 (experimental) (GCC)
--
Summary: [C++0x] "foo f{...}" form compiles, but "new foo{...}"
one doesn't
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florian dot goujeon at wanadoo dot fr
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=37740
[Bug c++/37741] New: [C++0x] ICE with shared_ptr in initializer-list of new-expression
The following piece of code :
#include
struct empty
{
};
struct foo
{
empty empty_;
};
int main(int, char**)
{
new foo
{
*std::make_shared()
};
return 0;
}
leads to an internal compiler error with GCC 4.4 svn:
$ g++ -std=c++0x main.cpp
main.cpp: In function 'int main(int, char**)':
main.cpp:12: internal compiler error: in verify_types_in_gimple_stmt, at
tree-cfg.c:3944
No error if "new foo" is replaced by "foo f".
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages='c c++' --disable-nls :
(reconfigured) ../gcc/configure --enable-languages='c c++' : (reconfigured)
../gcc/configure --enable-languages='c c++' --enable-shared --disable-static
--disable-nls
Thread model: posix
gcc version 4.4.0 20081005 (experimental) (GCC)
--
Summary: [C++0x] ICE with shared_ptr in initializer-list of new-
expression
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florian dot goujeon at wanadoo dot fr
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=37741
Psst... Wanna torture the optimiser in gcc 3.4.6?
Just get hold of the yabbawhap sources and "make AP". Then sit back and listen for the gurgles. Aside: Is it just me, or does -march=k6-2 result in slower code than -march=k6 does? Reynir H. Stefánsson ([EMAIL PROTECTED]) -- Scriptures: The sacred books of our holy religion, as distinguished from the false and profane writings on which all other faiths are based. (Ambrose Bierce)
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-10-06 05:03 --- An easy fix to this would be to disallow kind=2 integer as an argument during checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
[Bug middle-end/37742] New: ICE when compile mpich2-1.1.0a1
I don't know how to make a preprocessed source,sorry! $gcc --version gcc (GCC) 4.4.0 20081005 (experimental) $cd mpich2-1.1.0a1; mkdir build; cd build $../configure --prefix=/usr/local/mpich2; make CC ../../../../src/mpi/coll/opsum.c ../../../../src/mpi/coll/opsum.c: In function 'MPIR_SUM': ../../../../src/mpi/coll/opsum.c:21: internal compiler error: in vectorizable_load, at tree-vect-transform.c:6675 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [opsum.o] Error 1 make[3]: Leaving directory `/mnt/usr/fortran/packages/mpich2-1.1.0a1/build/src/mpi/coll' make[2]: *** [all-redirect] Error 2 make[2]: Leaving directory `/mnt/usr/fortran/packages/mpich2-1.1.0a1/build/src/mpi' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/mnt/usr/fortran/packages/mpich2-1.1.0a1/build/src' -- Summary: ICE when compile mpich2-1.1.0a1 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu 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=37742
[Bug middle-end/37730] [4.4 Regression] gcc.c-torture/compile/pr37713.c ICEs at -O3 -msse2
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-06 06:18 ---
This looks like a vectorizer bug to me. Vectorizer creates:
vector void * * vect_pdtds.39;
vector void * * vect_pdtds.34;
vector unsigned char * vect_cst_.33;
...
vect_cst_.33_33 = {&dtd, &dtd, &dtd, &dtd};
vect_pdtds.39_34 = (vector void * *) &dtds;
vect_pdtds.34_35 = vect_pdtds.39_34;
...
# vect_pdtds.34_36 = PHI
# ivtmp.40_38 = PHI
*vect_pdtds.34_36 = vect_cst_.33_33;
Shouldn't that use VCE instead? void * and unsigned char * certainly have
different alias sets, so storing vect_cst.33 with element type's alias set 3
into dtds variable, which has element alias set 2, doesn't work very well.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37730
