[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
--- Comment #3 from jv244 at cam dot ac dot uk 2009-11-15 09:20 --- (In reply to comment #2) Mine (got a patch) has the patch been posted ? Couldn't find it yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug fortran/42048] New: [F03] Erroneous syntax error message on TBP call
Reported by Damian Rouson: module grid_module implicit none type grid contains procedure :: new_grid end type contains subroutine new_grid(this) class(grid) :: this end subroutine end module module field_module use grid_module implicit none type field type(grid) :: mesh end type contains type(field) function new_field() call new_field%mesh%new_grid() end function ! This compiles when uncommented: !function new_field() result(new) ! type(field) :: new ! call new%mesh%new_grid() !end function end module This is rejected with: call new_field%mesh%new_grid() 1 Error: Syntax error in CALL statement at (1) -- Summary: [F03] Erroneous syntax error message on TBP call Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 10:43 --- The following patch makes the test case compile: Index: gcc/fortran/match.c === --- gcc/fortran/match.c (revision 154106) +++ gcc/fortran/match.c (working copy) @@ -2975,7 +2975,7 @@ gfc_match_call (void) /* If this is a variable of derived-type, it probably starts a type-bound procedure call. */ - if (sym-attr.flavor != FL_PROCEDURE + if ((sym-attr.flavor != FL_PROCEDURE || sym == gfc_current_ns-proc_name) (sym-ts.type == BT_DERIVED || sym-ts.type == BT_CLASS)) return match_typebound_call (st); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug c/42049] New: ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
/* Following code give ICE with -O2 or -O3
ice.c: In function main:
ice.c:46: internal compiler error: in expand_expr_real_1, at expr.c:9314
works OK with -O1 and no warnings given
*/
extern char *strcpy(char *s1, const char *s2);
/* #include string.h */
typedef struct _ccy_nameCCY_NAME;
#define CURRENCY_NAME_LENGTH3
struct _ccy_name {
char CcyName[CURRENCY_NAME_LENGTH + 1];
};
int main(int argc, char *argv[])
{
char const *ccy1;
char const *ccy2;
CCY_NAME ccy_list[9];
long i;
if (argc 1)
{
ccy1 = argv[1];
}
else
{
ccy1 = EUR;
}
if (argc 2)
{
ccy2 = argv[2];
}
else
{
ccy2 = USD;
}
strcpy(ccy_list[0].CcyName, ccy1);
strcpy(ccy_list[1].CcyName, ccy2);
for(i = 2; i argc - 2 i 8; i++)
{
strcpy(ccy_list[i].CcyName, argv[i + 1]);
}
ccy_list[i].CcyName[0] = '\0';
return 0;
}
/*
$ gcc-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Debian 4.4.1-4)
*/
--
Summary: ICE with -O2 - internal compiler error: in
expand_expr_real_1, at expr.c:9314
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardn26 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug middle-end/42050] New: ice in graphite-clast-to-gimple.c:165
Program received signal SIGSEGV, Segmentation fault. clast_to_gcc_expression (type=0x7f419f5c4580, e=0x0, region=0x139a9e0, newivs=0x13a47a0, newivs_index=0x13a9b70) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:165 165 switch (e-type) (gdb) bt #0 clast_to_gcc_expression (type=0x7f419f5c4580, e=0x0, region=0x139a9e0, newivs=0x13a47a0, newivs_index=0x13a9b70) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:165 #1 0x00c43cc5 in translate_clast (region=0x139a9e0, context_loop=0x7f419f4c06c0, stmt=0x13c51d0, next_e=0x7f419f4c4740, rename_map=0x13879f0, newivs=0x7fffa9408ef8, newivs_index=0x13a9b70, bb_pbb_mapping=0x139a8c0) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:467 #2 0x00c44238 in translate_clast (region=0x139a9e0, context_loop=0x7f419f4c06c0, stmt=0x13c60a0, next_e=0x7f419f4c4280, rename_map=0x13879f0, newivs=0x7fffa9408ef8, newivs_index=0x13a9b70, bb_pbb_mapping=0x139a8c0) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:679 #3 0x00c4429e in translate_clast (region=0x139a9e0, context_loop=0x7f419f4c06c0, stmt=0x13c6a90, next_e=0x7f419f4c4040, rename_map=0x13879f0, newivs=0x7fffa9408ef8, newivs_index=0x13a9b70, bb_pbb_mapping=0x139a8c0) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:690 #4 0x00c43c27 in translate_clast (region=0x139a9e0, context_loop=0x7f419f4c06c0, stmt=0x13b0e90, next_e=0x7f419f4c4040, rename_map=0x13879f0, newivs=0x7fffa9408ef8, newivs_index=0x13a9b70, bb_pbb_mapping=0x139a8c0) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:602 #5 0x00c44c70 in gloog (scop=value optimized out, bb_pbb_mapping=0x139a8c0) at /data03/vondele/gcc_trunk/gcc/gcc/graphite-clast-to-gimple.c:1195 #6 0x00c418b5 in graphite_transform_loops () at /data03/vondele/gcc_trunk/gcc/gcc/graphite.c:275 #7 0x008e3c57 in graphite_transforms () at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop.c:300 compiling : cat bug.f90 MODULE qs_ks_methods INTEGER, PARAMETER :: sic_list_all=1 TYPE dft_control_type INTEGER :: sic_list_id END TYPE CONTAINS SUBROUTINE sic_explicit_orbitals( ) TYPE(dft_control_type), POINTER :: dft_control INTEGER, ALLOCATABLE, DIMENSION(:, :):: sic_orbital_list INTEGER, DIMENSION(:), POINTER:: mo_derivs SELECT CASE(dft_control%sic_list_id) CASE(sic_list_all) DO i=1,k_alpha IF (SIZE(mo_derivs,1)==1) THEN ELSE sic_orbital_list(3,iorb)=2 ENDIF ENDDO END SELECT CALL test() END SUBROUTINE sic_explicit_orbitals END MODULE qs_ks_methods gfortran -c -fgraphite-identity -O1 -v bug.f90 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto --enable-plugins Thread model: posix gcc version 4.5.0 20091115 (experimental) [trunk revision 154188] (GCC) COLLECT_GCC_OPTIONS='-c' '-fgraphite-identity' '-O1' '-v' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -O1 -version -fgraphite-identity -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/cc58n9IM.s GNU Fortran (GCC) version 4.5.0 20091115 (experimental) [trunk revision 154188] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20091115 (experimental) [trunk revision 154188] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 bug.f90: In function __qs_ks_methods_MOD_sic_explicit_orbitals: bug.f90:7:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ice in graphite-clast-to-gimple.c:165 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot
[Bug fortran/42045] [F03] passing a procedure pointer component to a procedure pointer dummy
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 12:39 --- Cf. also PR39997, the discussion in http://j3-fortran.org/pipermail/j3/2009-May/002736.html and follow-ups, and http://www.j3-fortran.org/doc/year/09/09-236r1.txt (which seems to confirm that the test case is valid). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42045
[Bug middle-end/42050] [4.5 Regression] ice in graphite-clast-to-gimple.c:165
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-15 12:40 --- works on 4.4 branch, fails on 4.5 branch -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.2 Summary|ice in graphite-clast-to- |[4.5 Regression] ice in |gimple.c:165|graphite-clast-to- ||gimple.c:165 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42050
[Bug fortran/42045] [F03] passing a procedure pointer component to a procedure pointer dummy
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 12:50 ---
With the following patch, the errors go away:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154188)
+++ gcc/fortran/resolve.c (working copy)
@@ -10217,11 +10217,6 @@ resolve_fl_derived (gfc_symbol *sym)
return FAILURE;
}
}
- else if (c-attr.proc_pointer c-ts.type == BT_UNKNOWN)
- {
- c-ts = *gfc_get_default_type (c-name, NULL);
- c-attr.implicit_type = 1;
- }
/* Procedure pointer components: Check PASS arg. */
if (c-attr.proc_pointer !c-tb-nopass c-tb-pass_arg_num == 0)
but then one gets:
internal compiler error: in gfc_walk_variable_expr, at
fortran/trans-array.c:6308
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42045
[Bug fortran/42045] [F03] passing a procedure pointer component to a procedure pointer dummy
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-15 14:24 --- (In reply to comment #2) internal compiler error: in gfc_walk_variable_expr, at fortran/trans-array.c:6308 The ICE goes away when adding this: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 154188) +++ gcc/fortran/resolve.c (working copy) @@ -1321,6 +1321,8 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p e-rank = comp-as-rank; e-expr_type = EXPR_FUNCTION; } + if (gfc_resolve_expr (e) == FAILURE) + return FAILURE; goto argument_list; } The patch in comment #2 however triggers the following regressions: FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_18.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_19.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_comp_2.f90 -O0 (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42045
[Bug tree-optimization/42046] missed optimization
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-15 14:27 --- This is the usual missing code-hoisting optimization. Dup is PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046
[Bug middle-end/42049] [4.4 Regression] ICE with -O2 - internal compiler error: in expand_expr_real_1, at expr.c:9314
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-15 14:32 --- Confirmed. #1 0x00570173 in expand_expr_real_1 (exp=0x7616e140, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /home/rguenther/src/gcc-4_4-branch/gcc/expr.c:9314 9314 gcc_unreachable (); (gdb) call debug_generic_expr (exp) ccy_list[1].CcyName = USD;, (char *) ccy_list[1].CcyName; (gdb) up #2 0x00568795 in expand_expr_real (exp=0x7616e140, target=0x77ebd450, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /home/rguenther/src/gcc-4_4-branch/gcc/expr.c:7131 7131 ret = expand_expr_real_1 (exp, target, tmode, modifier, alt_rtl); (gdb) #3 0x00490f0b in expand_expr (exp=0x7616e140, target=0x77ebd450, mode=VOIDmode, modifier=EXPAND_NORMAL) at /home/rguenther/src/gcc-4_4-branch/gcc/expr.h:539 539 return expand_expr_real (exp, target, mode, modifier, NULL); (gdb) #4 0x00497422 in expand_builtin_strcpy_args (fndecl=0x77f41000, dest=0x76168c40, src=0x76168800, target=0x77ebd450, mode=VOIDmode) at /home/rguenther/src/gcc-4_4-branch/gcc/builtins.c:3715 3715return expand_expr (result, target, mode, EXPAND_NORMAL); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.2 Known to work||4.3.4 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-11-15 14:32:24 date|| Summary|ICE with -O2 - internal |[4.4 Regression] ICE with - |compiler error: in |O2 - internal compiler |expand_expr_real_1, at |error: in |expr.c:9314 |expand_expr_real_1, at ||expr.c:9314 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42049
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-15 14:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 14:54 --- Subject: Bug 42048 Author: janus Date: Sun Nov 15 14:54:05 2009 New Revision: 154190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154190 Log: 2009-11-15 Janus Weil ja...@gcc.gnu.org PR fortran/42048 * match.c (gfc_match_call): If we're inside a function with derived type return value, allow calling a TBP of the result variable. 2009-11-15 Janus Weil ja...@gcc.gnu.org PR fortran/42048 * gfortran.dg/typebound_call_11.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_11.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-15 14:55 --- Fixed with r154190. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #4 from burnus at gcc dot gnu dot org 2009-11-15 14:59 --- - if (sym-attr.flavor != FL_PROCEDURE + if ((sym-attr.flavor != FL_PROCEDURE || sym == gfc_current_ns-proc_name) Wouldn't it be more obvious to check for attr.result or something like that? From the testcase I understand how it works, but when I first looked at sym == gfc_current_ns-proc_name I was completely puzzled. Besides, it probably fails for strange constructions such as type(field) function new_field() call g() contains subroutine g() call new_field%mesh%new_grid() end subroutine g end function new_field -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-15 15:05 --- (In reply to comment #4) Besides, it probably fails for strange constructions such as Ah, indeed. Sorry for comitting too early :( Seems it was not quite obvious enough ... -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-15 15:12 --- (In reply to comment #4) Besides, it probably fails for strange constructions such as Another thing that does not work is: type(field) function new_field() ! ... end function subroutine test call new_field()%mesh%new_grid() end subroutine OTOH, is this even valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug c++/42010] ICE: lang_* check: failed in discriminator_for_local_entity, at cp/mangle.c:1581
--- Comment #2 from zsojka at seznam dot cz 2009-11-15 15:17 --- Since: r153816 | jason | 2009-11-02 17:14:26 +0100 (Mon, 02 Nov 2009) | 5 lines Restrict DR 757 change to C++0x mode. * decl2.c (mark_used): Check cxx_dialect. * decl.c (grokfndecl): Do check type linkage in C++98 mode. (grokvardecl): Likewise. * pt.c (check_instantiated_arg): Likewise. Everything works fine when compiled with --enable-checking=release, the resulting binary seems to be working correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42010
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-15 15:24 --- (In reply to comment #6) OTOH, is this even valid? At first glance, I don't see why it shouldn't be. Btw, this also fails with type-bound functions: integer :: i i = new_field()%mesh%new_int() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-15 15:32 --- Uh, it seems we're opening a can of worms here. The following also fails: type(grid) :: g g = new_field()%mesh Let's hope these beasts are all invalid ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #9 from janus at gcc dot gnu dot org 2009-11-15 15:40 --- (In reply to comment #8) Let's hope these beasts are all invalid ;) At least this one is rejected by ifort and NAG. ifort says: error #6837: The leftmost part-ref in a data-ref can not be a function reference. g = new_field()%mesh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-15 15:49 --- (In reply to comment #9) error #6837: The leftmost part-ref in a data-ref can not be a function reference. This is C612 in the Fortran 2003 standard: R612 data-ref is part-ref [ % part-ref ] ... R613 part-ref is part-name [ ( section-subscript-list ) ] C612 (R612) The leftmost part-name shall be the name of a data object. 2.4.3.1 Data object A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a constant. This makes comments #6 to #8 invalid. However, a proper error message could be added for these cases (similar to ifort's). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #11 from janus at gcc dot gnu dot org 2009-11-15 16:00 --- (In reply to comment #4) Wouldn't it be more obvious to check for attr.result or something like that? Tobias, I don't quite see how that would work. Simply checking for attr.result is surely not enough. After all this construct is only allowed if we're inside the new_field function ... -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42051] New: ICE on allocatable array TBP result
Gfortran 4.5.0 20091106 (with Janus's patch for PR42048) produces the following on the code below: gfortran -c field_grid.f03 field_grid.f03: In function output: field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:550 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. module grid_module implicit none type grid real ,dimension(1) :: x=1. contains procedure :: return_x end type contains function return_x(this) result(this_x) class(grid) ,intent(in) :: this real ,dimension(1) :: this_x this_x = this%x end function end module module field_module use grid_module, only : grid implicit none type field type(grid) :: mesh contains procedure :: output end type contains subroutine output(this) class(field) ,intent(in) :: this real ,dimension(:) ,allocatable :: x x=this%mesh%return_x() end subroutine end module -- Summary: ICE on allocatable array TBP result Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5 GCC host triplet: Mac OS X 10.5 GCC target triplet: Mac OS X 10.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug c++/42010] [C++0x] ICE: lang_* check: failed in discriminator_for_local_entity, at cp/mangle.c:1581
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-15 16:45 --- It still crashes with checking enabled though, and that isn't good. Let's add Jason in CC, maybe he can have a look... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-15 16:45:22 date|| Summary|ICE: lang_* check: failed in|[C++0x] ICE: lang_* check: |discriminator_for_local_enti|failed in |ty, at cp/mangle.c:1581 |discriminator_for_local_enti ||ty, at cp/mangle.c:1581 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42010
[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-15 16:58 --- Let's CC Jason here too, being an issue with lambda... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
[Bug c++/41568] [C++0x] ADL being kinky
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-15 17:23 --- For the record, even before San Francisco, rvalue-rvalue swaps were prohibited. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|ADL being kinky |[C++0x] ADL being kinky http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41568
[Bug lto/41915] FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2009-11-15 17:28 --- also fails on hppa64-hp-hpux11.11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41915
[Bug c++/40966] [cxx0x-lambda] ICE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-15 17:39 --- Lambdas are in mainline now, and I don't see any ICE, just a normal error. Please double check, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40966
[Bug c++/40938] ice in create_tmp_var
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-15 17:44 --- Works for me now (r154190). If you can still see something wrong, please reopen. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40938
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-11-15 17:58 --- Patches submitted to do all of the above cleanups, etc. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-10-14 01:59:37 |2009-11-15 17:58:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/42051] ICE on allocatable array TBP result
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 18:30 --- (In reply to comment #0) field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:550 Here is a reduced test case which gives the same ICE: type grid end type contains function return_x(this) result(this_x) class(grid) :: this real ,dimension(1) :: this_x end function subroutine output() type(grid) :: mesh real ,dimension(1) :: x x = return_x(mesh) end subroutine end So it seems this is neither connected to TBPs, nor to ALLOCATABLE. The ICE goes away however, if I remove the DIMENSION attributes, or if I make the CLASS argument a TYPE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-15 18:38 ---
Jerry, I added
@@ -56,11 +55,11 @@ get_array_index (gfc_array_ref *ar, mpz_
for (i = 0; i ar-dimen; i++)
{
e = gfc_copy_expr (ar-start[i]);
- re = gfc_simplify_expr (e, 1);
+ gfc_simplify_expr (e, 1);
if ((gfc_is_constant_expr (ar-as-lower[i]) == 0)
|| (gfc_is_constant_expr (ar-as-upper[i]) == 0)
- || (gfc_is_constant_expr (e) == 0))
+ /*|| (gfc_is_constant_expr (e) == 0)*/)
gfc_error (non-constant array in DATA statement %L, ar-where);
@@ -313,6 +314,10 @@ gfc_assign_data_value (gfc_expr *lvalue,
else
mpz_set (offset, index);
+gmp_printf (offset: %Zd\n, offset);
+if (lvalue-ts.type == BT_DERIVED)
+ mpz_add_ui (offset, offset, 1);
+
in data.c to see the computed offset values. The first chunk comments out
a check for a constant ar-start[] value, so that I get back to where
get_data_index is called. For this code
implicit none
type :: a
real :: x(3)
end type a
integer, parameter :: n = 3
type(a) :: b(n)
real, parameter :: d1(3) = (/1., 2., 3./)
real, parameter :: d2(3) = (/4., 5., 6./)
real, parameter :: d3(3) = (/7., 8., 9./)
integer :: i, z(n)
data (b(i), i = 1, n) /a(d1), a(d2), a(d3)/
data (z(i), i = 1, n) / 1, 2, 3/
print *, z(1), b(1)
print *, z(2), b(2)
print *, z(3), b(3)
end
I get
REMOVE:kargl[248] gfc4x -o z pr41807.f90
offset: 0
offset: 1
offset: 2
offset: 0
offset: -1
offset: -1
REMOVE:kargl[249] ./z
1 7.000 8.000 9.000
2 1.000 2.000 3.000
3 0.000 0.000 0.000
The first 3 offset values is from the data statement for the
z(3) array. The next 3 are for the array b(3) of the derived
type a. My conclusion to this point is that the array spec for
an array of a derived type is not properly set, or we're looking
at the wrong array spec.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||sgk at troutmask dot apl dot
||washington dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 18:49 --- Backtrace: #0 gfc_conv_variable (se=0x7fffd860, expr=0x1788a00) at /home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:550 #1 0x0059ab0a in gfc_conv_expr (se=0x7fffd860, expr=0x1788a00) at /home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:4322 #2 0x0059adde in gfc_conv_expr_reference (se=0x7fffd860, expr=0x1788a00) at /home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:4413 #3 0x00595a88 in gfc_conv_procedure_call (se=0x7fffdc00, sym=0x17823b0, arg=0x17337b0, expr=0x1788ad0, append_args=0x0) at /home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:2813 -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE on allocatable array TBP|[OOP] ICE on array-valued |result |function with CLASS formal ||argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug c/42052] New: Incorrect code generated for cast to lvalue with post increment
gcc 4.4.1 generates incorrect code for the following type of expression:
void *P;
for (something) {
...
*((*(int **)P)++) = Value;
...
};
P remains unchanged throughout the loop.
This code worked correctly in earlier versions of gcc, last checked on gcc
4.3.2.
the following flags were used:
-std=gnu99 -fdata-sections -ffunction-sections -pipe -O2 -fomit-frame-pointer
-w -D_GNU_SOURCE -fexpensive-optimizations
--
Summary: Incorrect code generated for cast to lvalue with post
increment
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rajamukherji at gmail dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42052
[Bug c/42052] Incorrect code generated for cast to lvalue with post increment
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-15 19:02 --- You are violating C/C++ aliasing rules. You access a void* via a int*. *** This bug has been marked as a duplicate of 21920 *** -- 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=42052
[Bug c/21920] aliasing violations
--- Comment #149 from pinskia at gcc dot gnu dot org 2009-11-15 19:02 --- *** Bug 42052 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rajamukherji at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-15 19:04 --- When we simplify start[i], we turn that expression into a constant. Then I believe the traverse_data_var can no longer increment the index since we made it a constant. I don't think the start[i] expression should be used to increment the offset, but I think it is. I am wondering if we don't need a temporary expression to use for this to traverse for the offset. Still thinking ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/40938] ice in create_tmp_var
--- Comment #8 from dcb314 at hotmail dot com 2009-11-15 19:19 --- (In reply to comment #7) Works for me now (r154190). I have no idea what r154190 means, but I can confirm that the snapshot of 2009112 seems to work ok, even at optimisation level -O3 -march=native. This looks fixed to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40938
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-11-15 19:20 --- I have the same problem with current gcc trunk and the proposed patch on a Core2Duo under x86_64-apple-darwin10... gcj --main=testme -O testme.java gcj: Internal error: Abort trap (program ecj1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. gcc-4 -v Using built-in specs. COLLECT_GCC=gcc-4 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc-4.5-20091115/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib Thread model: posix gcc version 4.5.0 20091115 (experimental) (GCC) Also, I always install the gcc trunk release before running any tests on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2009-11-15 19:26 ---
Subject: Re: [4.5/4.4 Regression] data statement with nested type
constructors
On Sun, Nov 15, 2009 at 07:04:42PM -, jvdelisle at gcc dot gnu dot org
wrote:
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-15 19:04
---
When we simplify start[i], we turn that expression into a constant. Then I
believe the traverse_data_var can no longer increment the index since we made
it a constant. I don't think the start[i] expression should be used to
increment the offset, but I think it is. I am wondering if we don't need a
temporary expression to use for this to traverse for the offset. Still
thinking
...
Changed the instrumentaion of the code a little. In the for-loop
of get_array_index, I added
printf(i = %d -- , i);
gmp_printf (start = %Zd , e-value.integer);
gmp_printf (lower = %Zd , ar-as-lower[i]-value.integer);
gmp_printf (upper = %Zd , ar-as-upper[i]-value.integer);
gmp_printf (offset= %Zd\n, *offset);
REMOVE:kargl[252] gfc4x -o z pr41807.f90 -fdump-tree-original
i = 0 -- start = 1 lower = 1 upper = 3 offset= 0
i = 0 -- start = 2 lower = 1 upper = 3 offset= 1
i = 0 -- start = 3 lower = 1 upper = 3 offset= 2
i = 0 -- start = 1 lower = 1 upper = 3 offset= 0
i = 0 -- start = 0 lower = 1 upper = 3 offset= -1
i = 0 -- start = 0 lower = 1 upper = 3 offset= -1
The first 3 lines are from
data (z(i), i = 1, n) / 1, 2, 3/
with z integer. The next 3 are from the array of derived type b.
So, you appear to be on the right track. The start value appears
to be junk. What's disconcerting is that the dump shows (with
the check for /*|| (gfc_is_constant_expr (e) == 0)*/ disabled)
REMOVE:kargl[253] more pr41807.f90.003t.original
MAIN__ ()
{
static struct a b[3] = {{.x={7.0e+0, 8.0e+0, 9.0e+0}}, {.x={1.0e+0, 2.0e+0,
3.0e+0}}};
integer(kind=4) i;
static integer(kind=4) z[3] = {1, 2, 3};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/40938] ice in create_tmp_var
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-15 19:56 --- r154190 is the subversion version I built and tested, this project doesn't use cvs anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40938
[Bug fortran/42053] New: [OOP] SELECT TYPE: reject duplicate CLASS IS blocks
From the Fortran 2003 standard: C817 (R823) For a given select-type-construct, the same type and kind type parameter values shall not be speci#64257;ed in more than one TYPE IS type-guard-stmt and shall not be speci#64257;ed in more than one CLASS IS type-guard-stmt. This check is missing for CLASS IS blocks, as the following program is currently accepted (by the fortran-dev branch): type :: t integer :: i end type CLASS(t),pointer :: x select type (x) class is (t) print *,a class is (t) print *,b end select end -- Summary: [OOP] SELECT TYPE: reject duplicate CLASS IS blocks Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
[Bug c++/42054] New: [4.3/4.4/4.5 Regression] ICE with invalid template parameter
The following invalid testcase triggers an ICE since GCC 4.2.0: = templateint int struct A; templateint int struct A; = bug.cc:1:14: error: two or more data types in declaration of 'parameter' bug.cc:2:14: error: two or more data types in declaration of 'parameter' bug.cc:2:26: error: redefinition of default argument for 'declaration error' bug.cc:2:26: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in redeclare_class_template, at cp/pt.c:4576 Please submit a full bug report, [etc.] -- Summary: [4.3/4.4/4.5 Regression] ICE with invalid template parameter Product: gcc Version: 4.5.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=42054
[Bug c++/42054] [4.3/4.4/4.5 Regression] ICE with invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42054
[Bug c++/42056] New: ICE with invalid use of auto in template
The following invalid testcase triggers an ICE since GCC 4.4.0
(when the meaning of the auto keyword changed).
==
templateint struct A
{
int a[auto(1)];
};
==
bug.cc:3:16: internal compiler error: in fold_convert_loc, at fold-const.c:2671
Please submit a full bug report, [etc.]
A similar code snippet is wrongly accepted:
==
templateint void foo()
{
int a[auto(1)];
}
==
It is rejected when foo is instantiated, but (given the first example)
this is probably too late.
--
Summary: ICE with invalid use of auto in template
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, 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=42056
[Bug c++/42057] New: [4.5 Regression] ICE with invalid parameter of virtual function
The following invalid testcase triggers an ICE on trunk:
struct A;
struct B
{
virtual B* foo(A);
};
struct C : virtual B
{
virtual C* foo(A) { return 0; }
};
C c;
bug.cc: In member function 'virtual C* C::foo(A)':
bug.cc:10:14: error: 'anonymous' has incomplete type
bug.cc:1:8: error: forward declaration of 'struct A'
bug.cc: In member function 'C* C::_ZTch0_v0_n16_N1C3fooE1A(A)':
bug.cc:13:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in create_tmp_var, at gimplify.c:504
Please submit a full bug report, [etc.]
When the code snippet is compiles with -Wall then the ICE happens in a
different place (the rest of the error message is identical):
bug.cc:13:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in operand_equal_p, at fold-const.c:3182
--
Summary: [4.5 Regression] ICE with invalid parameter of virtual
function
Product: gcc
Version: 4.5.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=42057
[Bug c++/42057] [4.5 Regression] ICE with invalid parameter of virtual function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
[Bug c++/38646] [4.3/4.4/4.5 regression] ICE with invalid specialization of variadic template
--- Comment #7 from simartin at gcc dot gnu dot org 2009-11-15 21:38 --- Patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00747.html -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org Last reconfirmed|2009-01-26 18:20:47 |2009-11-15 21:38:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38646
[Bug c++/42058] New: [4.3/4.4/4.5 Regression] Trouble with invalid array initialization
The following invalid testcase triggers an ICE on trunk (and GCC 4.1.x):
struct A;
struct B
{
A a;
};
B b[1] = (B[]) { 0 };
bug.cc:5:5: error: field 'a' has incomplete type
bug.cc:8:20: error: initializer for 'B' must be brace-enclosed
bug.cc:8:20: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in digest_init_r, at cp/typeck2.c:844
Please submit a full bug report, [etc.]
If one actually defines A, the compiler goes into an infinite loop
(since GCC 4.1.0):
struct A {};
struct B
{
A a;
};
B b[1] = (B[]) { 0 };
bug.cc:8:20: error: initializer for 'A' must be brace-enclosed
bug.cc:8:20: error: initializer for 'A' must be brace-enclosed
bug.cc:8:20: error: initializer for 'A' must be brace-enclosed
[etc.]
--
Summary: [4.3/4.4/4.5 Regression] Trouble with invalid array
initialization
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, compile-
time-hog
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=42058
[Bug c++/42058] [4.3/4.4/4.5 Regression] Trouble with invalid array initialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
[Bug c++/42059] New: [4.4/4.5 Regression] ICE with initializer list for VLA
The following invalid testcase triggers an ICE since GCC 4.4.1:
==
void foo(int i)
{
int a[i];
a = {};
}
==
bug.cc: In function 'void foo(int)':
bug.cc:4:8: internal compiler error: tree check: expected integer_cst, have
nop_expr in process_init_constructor_array, at cp/typeck2.c:912
Please submit a full bug report, [etc.]
--
Summary: [4.4/4.5 Regression] ICE with initializer list for VLA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-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=42059
[Bug c++/42059] [4.4/4.5 Regression] ICE with initializer list for VLA
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42059
[Bug c++/42055] [4.5 Regression] ICE with amiguous template specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug c++/42055] New: [4.5 Regression] ICE with amiguous template specialization
The following invalid testcase triggers an ICE on trunk: === templatetypename T void foo(T, T); templatetypename T void foo(T, int); template void foo(int, int); === bug.cc:5:15: error: ambiguous template specialization 'foo' for 'void foo(int, int)' bug.cc:5:27: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] -- Summary: [4.5 Regression] ICE with amiguous template specialization Product: gcc Version: 4.5.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=42055
[Bug c++/42060] New: [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
The following invalid testcase triggers an ICE since GCC 4.4.1:
==
void foo()
{
int a[1];
throw a = {};
}
==
bug.cc: In function 'void foo()':
bug.cc:4:14: error: invalid use of non-lvalue array
bug.cc:4:15: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1221
Please submit a full bug report, [etc.]
--
Summary: [4.4/4.5 Regression] [c++0x] ICE throwing array with
initializer list
Product: gcc
Version: 4.5.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=42060
[Bug c++/42060] [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug c++/42061] New: [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
The following invalid testcase triggers an ICE since GCC 4.4.2:
==
int i = { j };
==
bug.cc:1:12: error: 'j' was not declared in this scope
bug.cc:1:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in reference_related_p, at cp/call.c:972
Please submit a full bug report, [etc.]
--
Summary: [4.4/4.5 Regression] [c++0x] ICE with invalid
initializer list for reference
Product: gcc
Version: 4.5.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=42061
[Bug c++/42061] [4.4/4.5 Regression] [c++0x] ICE with invalid initializer list for reference
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42061
[Bug c++/42062] New: [4.3/4.4/4.5 Regression] Trouble with invalid template specialization
The following invalid testcase triggers an ICE since GCC 4.3.4:
===
templatetypename struct A
{
templateint void foo();
template struct Avoid
{
templateint void foo();
};
};
void bar()
{
Avoid a;
a.foo0();
}
===
bug.cc:5:12: error: explicit specialization in non-namespace scope 'struct A
template-parameter-1-1 '
bug.cc:5:21: error: template parameters not used in partial specialization:
bug.cc:5:21: error: 'template-parameter-1-1'
bug.cc: In function 'void bar()':
bug.cc:14:12: internal compiler error: in retrieve_specialization, at
cp/pt.c:953
Please submit a full bug report, [etc.]
A similar testcase is wrongly accepted since GCC 3.3 (before it it triggered
an ICE):
===
templatetypename struct A
{
templateint void foo();
templatetypename T struct AT*
{
templateint void foo();
};
};
void bar()
{
Avoid* a;
a.foo0();
}
===
--
Summary: [4.3/4.4/4.5 Regression] Trouble with invalid template
specialization
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, 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=42062
[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-11-15 22:52 --- Comparing the linkages of ecjx and gij on x86_64-apple-darwin10 with your patch, one thing I did notice is that there is a slight difference in the link flags. The ecjx linkage is passed -findirect-dispatch but not -shared-libgcc while the linkage of gij is passed -shared-libgcc but not -findirect-dispatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare
--- Comment #4 from dje at gcc dot gnu dot org 2009-11-15 23:04 --- It's fixed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40343
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-11-16 01:26 --- This doesn't solve the abort in ejc1 on x86_64-apple-darwin10, but shouldn't we have... Index: libjava/Makefile.in === --- libjava/Makefile.in (revision 154191) +++ libjava/Makefile.in (working copy) @@ -8510,11 +8510,12 @@ ECJX_BASE_FLAGS = -findirect-dispatch \ --main=org.eclipse.jdt.internal.compiler.batch.GCCMain -...@native_false@ecjx_LINK = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS) -...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) @ENABLE_SHARED_FALSE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH) @ENABLE_SHARED_TRUE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) @native_fa...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) +...@native_false@ecjx_LINK = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS) +...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) -shared-libgcc $(extra_gij_ldflags) + @native_fa...@ecjx_ldadd = @native_t...@ecjx_ldadd = -L$(here)/.libs $(extra_ldflags) \ @NATIVE_TRUE@ $(am__append_31) Index: libjava/Makefile.am === --- libjava/Makefile.am (revision 154191) +++ libjava/Makefile.am (working copy) @@ -1085,8 +1085,6 @@ if NATIVE -ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) - if ENABLE_SHARED ## Use ecj.jar at runtime. ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) @@ -1095,6 +1093,8 @@ ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH) endif !ENABLE_SHARED +ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) -shared-libgcc $(extra_gij_ldflags) + ecjx_LDADD = -L$(here)/.libs $(extra_ldflags) ecjx_DEPENDENCIES = libgcj.la libgcj.spec if BUILD_SUBLIBS Currently ecjx_LDFLAGS is used in assigning ecjx_LINK before it is assigned itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #7 from craig dot schlenter at gmail dot com 2009-11-16 04:37
---
(In reply to comment #3)
I brought this up on the Google-internal C list. They reduced it further:
$ cat main.cc
#include map
int main(void)
{
typedef std::mapint, char* MyMap2;
MyMap2 map2_;
MyMap2::iterator map_iter2 = map2_.find(5);
return *map_iter2-second;
}
$ g++ -O3 -Wall -c main.cc
main.cc: In function 'int main()':
main.cc:8: warning: dereferencing pointer 'anonymous' does break
strict-aliasing rules
/opt/local/include/gcc44/c++/bits/stl_tree.h:179: note: initialized from here
Hironori Bono spotted btw. that if the key for the map is changed from an int
to a std::string, then the aliasing warning disappears:
#include map
#include string
int main(void)
{
typedef std::mapstd::string, char* MyMap2;
MyMap2 map2_;
MyMap2::iterator map_iter2 = map2_.find(hello);
return *map_iter2-second;
}
This is rather strange and confusing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug c++/42063] New: g++ violate [class.dtor] when explicit destructor call
This bug is related to the example in [class.dtor]/12 of standard N2960.
according to the example, in the following program:
#include iostream
struct B {
virtual ~B() { std::cout ~B std::endl; }
};
struct D : B {
~D () { std::cout ~D std::endl; }
};
typedef B B_alias;
int main()
{
D D_object;
B* B_ptr = D_object;
std::cout begin std::endl;
D_object.B::~B();
B_ptr-~B();
std::cout end std::endl;
return 0;
}
D_object .B::~B () should call B¡¯s destructor, and
B_ptr -~B () should call D's destructor.
However the actual result is
begin
~B
~B
end
...
the strange thing is when D_object.B::~B() be removed, or be swapped between
B_ptr-~B(), everything is OK.
Another problem: according to the spec, 'Once a destructor is invoked for an
object, the object no longer exists'. However, the following code shows that
g++ doesn't respect it:
#include iostream
struct C {
~C() { std::cout XXX std::endl; }
};
int main()
{
C * c = new C();
c-C::~C();
delete c;
return 0;
}
the program ends normally. Shouldn't it generate a double free fault?
--
Summary: g++ violate [class.dtor] when explicit destructor call
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pi3orama at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
[Bug c++/42064] New: g++ violate [class.qual]
below is an example in standard N2960.
struct A { A(); };
struct B : public A { B(); };
A::A() { }
B::B() { }
A::A a;
int main()
{
return 0;
}
According to the standard [class.qual]/2, 'A::A a;' is error because A::A is
not a type name. But g++ can compile it without error or warning.
--
Summary: g++ violate [class.qual]
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pi3orama at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42064
[Bug c++/42064] g++ violate [class.qual]
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-16 06:21 --- *** This bug has been marked as a duplicate of 11764 *** -- 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=42064
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-11-16 06:21 --- *** Bug 42064 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pi3orama at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
