[Bug fortran/33317] [4.3 regression]CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #12 from dominiq at lps dot ens dot fr 2007-11-19 08:07 --- Additional problem: gfortran.dg/optional_dim_2.f90 segfaults with -m64 on Intel Darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #15 from steven at gcc dot gnu dot org 2007-11-19 08:54 --- Cute little patch of comment #13 looking for foster parent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #13 from steven at gcc dot gnu dot org 2007-11-19 08:56 --- Maybe a wrong-code bug and it is "minor" and P2? Someone please update the status of this report :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #22 from steven at gcc dot gnu dot org 2007-11-19 09:01 --- "...and then he said: ``well, that's nice and all, but, ehm, where's the bug?''" -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin
--- Comment #26 from steven at gcc dot gnu dot org 2007-11-19 09:03 --- If there is a latent bug, it will show up somewhen and get its own nice bug report. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-11-19 09:08 --- This still fails on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Keywords|wrong-code | Last reconfirmed|2007-08-06 14:58:23 |2007-11-19 09:08:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug tree-optimization/21596] [4.0/4.1/4.2 Regression] extra temporaries when using global register variables
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-11-19 09:35 --- Actually we get: subl$4, %edi subl$12, %esp xorl%eax, %eax cmpl$0, -4(%edi) setle %al addl$12, %esp So this is fixed for the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |extra temporaries when using|extra temporaries when using |global register variables |global register variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #16 from bonzini at gnu dot org 2007-11-19 09:45 --- Steven, post it to gcc-patches and I'll be happy to commit it as soon as it is approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #40 from steven at gcc dot gnu dot org 2007-11-19 10:04 --- Can someone please redo the timings for GCC 4.3? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/27440] [4.0/4.1/4.2/4.3 regression] code quality regression due to ivopts
--- Comment #9 from steven at gcc dot gnu dot org 2007-11-19 10:07 --- What does GCC 4.3 do with the test case of this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE"
--- Comment #9 from steven at gcc dot gnu dot org 2007-11-19 10:16 --- This bug is P1, a "blocker", and ... UNCONFIRMED? :-) Any news on this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug tree-optimization/34148] New: [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
With the fix for PR33870 we now create _loads_ of VOPs for QTs qmake makefile.cpp at even -O so that all machines I have either run OOM or with a debug build of gcc, tree-ssa-sccvn.c:1853 (DFS visiting VUSEs) recurses too deeply and blows the 8MB stack on x86_64 (and takes too much compile-time). Which means, we no longer can build QT. -- Summary: [4.3 Regression] Too many VOPs, too deep tree-ssa- sccvn.c recursion Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: memory-hog, compile-time-hog Severity: blocker Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org OtherBugsDependingO 33870 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-19 10:51 --- Created an attachment (id=14577) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14577&action=view) testcase (unreduced) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-19 11:05 --- tree-ssa-sccvn should use a non-recursive DFS algorithm. Though, that is only part of the solution here, I suppose. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-19 11:05:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34036] [4.2/4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-19 11:07 --- Subject: Bug 34036 Author: ebotcazou Date: Mon Nov 19 11:07:28 2007 New Revision: 130287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130287 Log: PR tree-optimization/34036 * doc/invoke.texi (Optimize Options): Refactor documentation of -ffast-math. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug c++/33962] [4.1/4.2/4.3 Regression] ICE at call to overloaded template function with variable-length function argument list
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-19 11:12 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 04:47:57 |2007-11-19 11:12:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33962
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-19 11:19 --- Yes, I wonder if we can "cut" the DFS walk somewhere - in this case we have 1000s of stmts with each ~200 VUSEs... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-19 11:23 --- One workaround in this case is to run another forwprop / dce between inlining and the first alias pass. This get's rid of a lot of pointers and pointed to temporaries. Still that doesn't address the fundamental problems here. (but it makes the testcase work nicely within a bound of 600MB peak memory usage) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug ada/34149] New: GNAT crash - deeply inrerited function
I have following compiler crash: gcc -c -gnat05 qt-dom_nodes.adb +===GNAT BUG DETECTED==+ | 4.3.0 20071118 (experimental) (i686-pc-linux-gnu) Assert_Failure einfo.adb:1514| | Error detected at qt-dom_nodes.ads:60:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ It appears if tagged type with null record extension inherit (deeply) a dispatching function with anonymous access classwide parameter and both tagged types was declared in the same package. -- Summary: GNAT crash - deeply inrerited function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vgodunko at rostel dot ru GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
[Bug ada/34149] GNAT crash - deeply inrerited function
--- Comment #1 from vgodunko at rostel dot ru 2007-11-19 11:28 --- Created an attachment (id=14578) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14578&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
[Bug java/34150] New: ICE: output_operand: invalid expression as operand on hppa
[ Forwarded from http://bugs.debian.org/451757 ] gcj 4.2 fails to compile the attached jar file on hppa. paer% /usr/bin/gcj-4.2 -c -O2 -fPIC -findirect-dispatch hsqldb-1.8.0.9.jar.4.jar -o hsqldb-1.8.0.9.jar.4.o hsqldb-1.8.0.9.jar.4.jar: In class 'org.hsqldb.util.DatabaseManagerSwing': hsqldb-1.8.0.9.jar.4.jar: In method 'org.hsqldb.util.DatabaseManagerSwing.directRefreshTree()': hsqldb-1.8.0.9.jar.4.jar:0: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE: output_operand: invalid expression as operand on hppa Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: hppa-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34150
[Bug java/34150] ICE: output_operand: invalid expression as operand on hppa
--- Comment #1 from tbm at cyrius dot com 2007-11-19 11:29 --- Created an attachment (id=14579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14579&action=view) jar file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34150
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #41 from dank at kegel dot com 2007-11-19 12:27 --- OK, I'll see if I can get that done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug fortran/34079] Bind(C): Character argument/return value problems
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-19 12:30 --- Subject: Bug 34079 Author: burnus Date: Mon Nov 19 12:30:17 2007 New Revision: 130288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130288 Log: 2007-11-19 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34079 * decl.c (gfc_match_entry): Support BIND(C). (gfc_match_subroutine): Fix comment typo. 2007-11-19 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34079 * gfortran.dg/bind_c_usage_10_c.c: New. * gfortran.dg/bind_c_usage_10.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03 trunk/gcc/testsuite/gfortran.dg/bind_c_usage_10_c.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #3 from krebbel at gcc dot gnu dot org 2007-11-19 12:43 --- Created an attachment (id=14580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14580&action=view) Smaller testcase -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Attachment #14541|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-11-19 12:52 --- Subject: Bug 34099 Author: rguenth Date: Mon Nov 19 12:52:09 2007 New Revision: 130289 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130289 Log: 2007-11-19 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34099 * tree-ssa-ccp.c (likely_value): Exclude all but PLUS_EXPR, MINUS_EXPR and POINTER_PLUS_EXPR from handling as UNDEFINED if only one operand is undefined. * gcc.c-torture/execute/pr34099-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr34099-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-11-19 12:53 --- Subject: Bug 34099 Author: rguenth Date: Mon Nov 19 12:52:58 2007 New Revision: 130290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130290 Log: 2007-11-19 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34099 * tree-ssa-ccp.c (likely_value): Exclude all but PLUS_EXPR, MINUS_EXPR and POINTER_PLUS_EXPR from handling as UNDEFINED if only one operand is undefined. * gcc.c-torture/execute/pr34099-2.c: New testcase. Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c/34151] New: Compiling GCC-3.4.3 gives internal compiler error: in arm_dbx_register_number, at config/arm/arm.c
The host is linux 2.6.19. The target platform is Freescale imx31ads board. The cross toolchain is arm-none-linux-gnueabi-. While compiling the gcc-3.4.3, its giving the following error: -c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o ../../gcc/unwind-dw2.c: In function 'extract_cie_info': ../../gcc/unwind-dw2.c:328: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ../../gcc/unwind-dw2.c:381: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'execute_cfa_program': ../../gcc/unwind-dw2.c:844: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'uw_frame_state_for': ../../gcc/unwind-dw2.c:1060: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'init_dwarf_reg_size_table': ../../gcc/unwind-dw2.c:1272: internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:15183 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [libgcc/./unwind-dw2.o] Error 1 make[2]: Leaving directory `/home/deepak.singal/test1/ltib-imx31ads-20070511/rpm/BUILD/gcc-3.4.3/build-gcc/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/home/deepak.singal/test1/ltib-imx31ads-20070511/rpm/BUILD/gcc-3.4.3/build-gcc/gcc' make: *** [all-gcc] Error 2 error: Bad exit status from /home/deepak.singal/test1/ltib-imx31ads-20070511/tmp/rpm-tmp.87288 (%build) Regards, Deepak Singal -- Summary: Compiling GCC-3.4.3 gives internal compiler error: in arm_dbx_register_number, at config/arm/arm.c Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deepak dot singal at nechclst dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34151
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #4 from krebbel at gcc dot gnu dot org 2007-11-19 13:32 --- The problem occurs since this patch has removed the promotion of result types of a function decl: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00424.html With this patch the enum Status return type of getStatus is not promoted to int anymore and the enum type tree node is passed to the back end hook. Unfortunately enum types defined within a template declaration are not fully processed when they are defined. According to a comment in finish_enum the full processing is postponed to the point when the template gets instantiated. The back end hook is not called with the error mark node as I wrote in my last comment. The error mark node is created when our back end invokes promote_mode with the not fully processed enum type node and VOIDmode as mode parameter. Why is the back end involved at all? The example doesn't produce any code so why the back end has to bother in which register a value will be returned?! A comment in start_preparsed_function says that this is necessary to have CFUN set up - mmh. I think the bug is that a back end hook is invoked with a tree type node before the front end specific type promotions have been applied. So either we don't involve the back end at all or we promote enums to ints as it was done before. If I understand this correctly the whole layout of the function type is anyway re-done when the template gets instantiated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-19 13:36 --- Interestingly, on x86_64, TARGET_FUNCTION_VALUE is not invoked at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-19 13:36 --- So, on s390, how do we get there? Can you post a backtrace? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #7 from krebbel at gcc dot gnu dot org 2007-11-19 13:42 --- Breakpoint 1, s390_function_value (type=0x2326bb8, mode=VOIDmode) at /build2/gcc-4.3/gcc/config/s390/s390.c:7874 warning: Source file is more recent than executable. 7874 if (type) (gdb) bt #0 s390_function_value (type=0x2326bb8, mode=VOIDmode) at /build2/gcc-4.3/gcc/config/s390/s390.c:7874 #1 0x802c3f7a in hard_function_value (valtype=0x2326bb8, func=, fntype=, outgoing=) at /build2/gcc-4.3/gcc/explow.c:1484 #2 0x8035d63c in aggregate_value_p (exp=0x221bed8, fntype=0x2326ed8) at /build2/gcc-4.3/gcc/function.c:1808 #3 0x8035e7aa in allocate_struct_function (fndecl=0x2325a00) at /build2/gcc-4.3/gcc/function.c:3897 #4 0x8001e3d0 in start_preparsed_function (decl1=0x2325a00, attrs=, flags=0) at /build2/gcc-4.3/gcc/cp/decl.c:11171 #5 0x800f1b84 in cp_parser_late_parsing_for_member (parser=0x221c2d0, member_function=0x2325a00) at /build2/gcc-4.3/gcc/cp/parser.c:17216 #6 0x800e9c56 in cp_parser_class_specifier (parser=0x221c2d0) at /build2/gcc-4.3/gcc/cp/parser.c:14224 #7 0x800e1fa4 in cp_parser_type_specifier (parser=0x221c2d0, flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0x3cdc030, is_declaration=1 '\001', declares_class_or_enum=0x3cdbf40, is_cv_qualifier=0x3cdbf3f "") at /build2/gcc-4.3/gcc/cp/parser.c:10535 #8 0x800dd338 in cp_parser_decl_specifier_seq (parser=0x221c2d0, flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0x3cdc030, declares_class_or_enum=0x3cdc08c) at /build2/gcc-4.3/gcc/cp/parser.c:8139 #9 0x800f0d10 in cp_parser_single_declaration (parser=0x221c2d0, checks=0x0, member_p=0 '\0', explicit_specialization_p=0 '\0', friend_p=0x3cdc16f "") at /build2/gcc-4.3/gcc/cp/parser.c:16873 #10 0x800f065c in cp_parser_template_declaration_after_export (parser=0x221c2d0, member_p=0 '\0') at /build2/gcc-4.3/gcc/cp/parser.c:16786 #11 0x800df054 in cp_parser_template_declaration (parser=0x221c2d0, member_p=0 '\0') at /build2/gcc-4.3/gcc/cp/parser.c:9204 #12 0x800dc796 in cp_parser_declaration (parser=0x221c2d0) at /build2/gcc-4.3/gcc/cp/parser.c:7671 #13 0x800dc472 in cp_parser_declaration_seq_opt (parser=0x221c2d0) at /build2/gcc-4.3/gcc/cp/parser.c:7602 #14 0x800d2b42 in cp_parser_translation_unit (parser=0x221c2d0) at /build2/gcc-4.3/gcc/cp/parser.c:2971 #15 0x800fb7e2 in c_parse_file () at /build2/gcc-4.3/gcc/cp/parser.c:20507 #16 0x801cd2ae in c_common_parse_file (set_yydebug=) at /build2/gcc-4.3/gcc/c-opts.c:1275 #17 0x80476924 in toplev_main (argc=, argv=) at /build2/gcc-4.3/gcc/toplev.c:1042 #18 0x02098f08 in __libc_start_main () from /lib64/libc.so.6 #19 0x80004d22 in _start () (gdb) p debug_tree(type) local bindings <(nil)>> value readonly constant invariant private VOID file t.cpp line 6 align 1 context chain > chain local bindings <(nil)>> value >> context chain > $1 = void -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug tree-optimization/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE
--- Comment #8 from rob dot quill at gmail dot com 2007-11-19 13:46 --- Created an attachment (id=14581) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14581&action=view) Patch adds a dummy pass, as discussed in comments Patch attached, no regressions on x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-19 13:49 --- Interesting. x86_64 exits aggregate_value_p early (and wrong!?) here: 1801 if (targetm.calls.return_in_memory (type, fntype)) 1802return 1; with no adverse effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE"
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-19 14:28 --- Subject: Re: [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16i > --- Comment #9 from steven at gcc dot gnu dot org 2007-11-19 10:16 > --- > This bug is P1, a "blocker", and ... UNCONFIRMED? :-) > Any news on this bug? I'm not seeing it anymore. Whether it's actually fixed, I'm not sure. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug c++/34152] New: Erratic behaviour: Exception translation (throw from signal handlers)
In our application we want to translate synchronous signals (such as SIGSEGV)
to C++ exceptions.
The method is to use throw directly from either:
1 - From the signal handler itself.
2 - From a function called by the signal handler.
I'm having trouble getting this to work reliably. Test program attached below.
Building and running:
$ g++ sigthrow.cpp -fnon-call-exceptions -fexceptions
$ a.out
terminate called after throwing an instance of 'char const*'
Aborted (core dumped)
$
Removing option -fnon-call-exceptions gives:
$ g++ sigthrow.cpp -fexceptions
$ a.out
~StructWithDtor: Count 0
Caught exception
So it works, except the frame that generated the exception is not cleaned up
(it should call a destructor for another instance of StructWithDtor).
The pattern seems to be:
1 - If the function generating the signal has objects to unwind, this is always
missed.
2 - Also, when compiled with -fnon-call-exceptions the program often (not
always) aborts.
3 - If the function generating the signal does not have objects to unwind it
goes well (with or without -fnon-call-exceptions)
Are there some other compiler option to make this work? Something to be done in
the signal handler?
So far I haven't found any working examples of this functionality on the web.
But others have found similar difficulties.
What is the status of this?
It's an important feature when using plugins, script interpreters and linking
with code from other languages.
Regards
// ATS.
- source ---
#include
#include
#include
#include
typedef void(*stSignalHandlerFn)(int);
struct old_i386_kernel_sigaction {
stSignalHandlerFn k_sa_handler;
unsigned long k_sa_mask;
unsigned long k_sa_flags;
void (*sa_restorer) (void);
};
void stSigSegvHandler( int dummy ){
void **_p = (void **)&dummy;
struct sigcontext_struct *_regs = (struct sigcontext_struct *)++_p;
throw "SIGSEGV signaled";
}
int g_cnt;
struct StructWithDtor {
StructWithDtor() : m_cnt(g_cnt++) { }
~StructWithDtor(){ printf("~StructWithDtor: Count %d\n", m_cnt); }
int m_cnt;
};
int FuncNested1( int *pi ){
StructWithDtor swd;
return *pi;
}
int FuncTop( int *pi ){
StructWithDtor swd;
return FuncNested1( pi );
}
int main( int argc, const char* argv[] ) {
// Install a SIGSEGV handler using syscall
struct old_i386_kernel_sigaction kact;
kact.k_sa_handler = stSigSegvHandler;
kact.k_sa_mask = 0;
kact.k_sa_flags = 0;
syscall( SYS_sigaction, SIGSEGV, &kact, NULL );
// Trigger SIGSEGV
try {
FuncTop( NULL );
}catch( ... ){
puts( "Caught exception\n" );
}
}
--
Summary: Erratic behaviour: Exception translation (throw from
signal handlers)
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asteinarson at gmail dot com
GCC build triplet: Linux Ubuntu 7.10, X86-32, gcc 4.1.3 (Ubuntu default)
GCC host triplet: Linux Ubuntu 7.10, X86-32, gcc 4.1.3 (Ubuntu default)
GCC target triplet: Linux Ubuntu 7.10, X86-32, gcc 4.1.3 (Ubuntu default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug c/34146] [4.1/4.2/4.3 Regression] Inefficient code with compound literals inside a CONSTRUCTO
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-19 14:58 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-19 14:58:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34146
[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed
--- Comment #6 from pault at gcc dot gnu dot org 2007-11-19 15:10 --- (In reply to comment #5) > Off to generics and operators now! Ahhh... I have run into a serious problem here. It transpires that renaming is not accomplished for generic interfaces by keeping the use-name symbol with multiple symtrees, each with a local-name. Instead, the symtree and the symbol have the local-name. This breaks the mechanism that I evolved above. The DEC Manual puts the rules rather nicely: If more than one USE statement for a given module appears in a scoping unit, the following rules apply: If one USE statement does not have the ONLY option, all public entities in the module are accessible, and any rename- lists and only-lists are interpreted as a single, concatenated rename-list. If all the USE statements have ONLY options, all the only-lists are interpreted as a single, concatenated only-list. Only those entities named in one or more of the only-lists are accessible. This, I think, shows the way forward. ie. In matching the USE statements, we only build up the rename-list and flag the presence of a USE statement without an ONLY. Then, at the last USE statement, we process all the referenced .mod files just once, using the concatenated rename-list as an only-list or a rename list, according to what we have seen. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
[Bug fortran/34153] New: Unable to debug code compiled with gfortran on MacOSX 10.4.11
Hi, I'm having a problem using gdb to debug code compiled with gfortran (v 4.3.0). The code: program test i = 1 C Breakpoint here end when compiled with "gfortran -gstabs -o prog prog.f", debugged with "gdb prog" demonstrates the error. The commands: (gdb) break 3 (gdb) run produces the output: > Starting program: /private/tmp/prog > Reading symbols for shared libraries .++ done > > Breakpoint 1, main (argc=1, argv=0xbfffe9b8) at > ../../../gcc-4.3-20070810/libgfortran/fmain.c:12 > 12 ../../../gcc-4.3-20070810/libgfortran/fmain.c: No such file or > directory. > in ../../../gcc-4.3-20070810/libgfortran/fmain.c At this point commands to examine symbols fail: (gdb) display i No symbol "i" in current context. The problem is the same on a PowerPC machine also. -- Summary: Unable to debug code compiled with gfortran on MacOSX 10.4.11 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j dot wookey at bristol dot ac dot uk GCC host triplet: i386-apple-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #1 from asteinarson at gmail dot com 2007-11-19 16:21 ---
I found something out. If I add a further function call to FuncNested1:
int FuncNested2( ){
StructWithDtor swd;
return 0;
}
int FuncNested1( int *pi ){
StructWithDtor swd;
FuncNested2( ); // This trigger unwind table generation
return *pi;
}
then it works. It seems that FuncNested1 in the first form:
int FuncNested1( int *pi ){
StructWithDtor swd;
return *pi;
}
never generates any unwinding information (since it doesn't call other
functions) and when SIGSEGV happens inside it, it cannot find any unwind tables
and C++ run-time bails out. I can understand the logic behind this, but it
certainly made my first test case fail miserably.
In a realworld app, the optimization is probably OK, since a function
generating the signal is likely to contain other function calls (not bullet
proof).
It is possible to interpret -asynchronous-unwind-tables to support this but
that option changes nothing for my test case.
An option -always-generate-unwind-tables would be useful in this case (but
probably results in a larger executable).
Regards
// ATS.
--
asteinarson at gmail dot com changed:
What|Removed |Added
CC||asteinarson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug libfortran/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-19 16:54
---
EXPONENT is implemented in libgfortran with frexpf. Can you tell us what the
following gives:
int main() {
float x = 5.87747175E-39;
int i;
__builtin_frexpf (x, &i);
__builtin_printf ("%d\n", i);
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug c++/34089] [4.1/4.2/4.3 regression] Segfault on specialization using struct instead of template function.
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-19 16:55 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-15 04:38:59 |2007-11-19 16:55:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34089
[Bug libfortran/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #2 from dominiq at lps dot ens dot fr 2007-11-19 17:12 --- Subject: Re: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9 > Can you tell us what the following gives: -127 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-19 17:18 --- OK, so you need to file a bug report to Apple. We probably should consider XFAILing that testcase. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libfortran |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-19 17:18:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug tree-optimization/34036] [4.2/4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-11-19 17:27 --- Subject: Bug 34036 Author: ebotcazou Date: Mon Nov 19 17:27:06 2007 New Revision: 130293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130293 Log: PR tree-optimization/34036 * gcc.dg/tree-ssa/pr23109.c: Pass -ftrapping-math and expect warning. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-19 17:38 ---
With just a forwprop pass after inlining and before salias we miscompile
cp/semantics.c:pop_to_parent_deferring_access_checks() at -O2.
An optimization barrier like
pop_to_parent_deferring_access_checks (void)
{
if (deferred_access_no_check)
deferred_access_no_check--;
else
{
VEC (deferred_access_check,gc) *checks;
deferred_access *ptr;
checks = (VEC_last (deferred_access, deferred_access_stack)
->deferred_access_checks);
VEC_pop (deferred_access, deferred_access_stack);
__asm__ __volatile__ ("" : : : "memory");
ptr = VEC_last (deferred_access, deferred_access_stack);
fixes it. Reducing max-aliased-vops to 100 (as with -O1 which also passes)
fixes the problem as well. -O1 -fstrict-aliasing
--param max-aliased-vops=500 (as with -O2) also breaks. Disabling DOM
makes it work again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug ada/34098] xgcc: Internal error: Segmentation fault (program gnat1)
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-19 17:49 --- Subject: Bug 34098 Author: ebotcazou Date: Mon Nov 19 17:49:11 2007 New Revision: 130294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130294 Log: PR ada/34098 ada/ * misc.c (gnat_adjust_rli): Delete. (gnat_init): Do not initialize the translation code here. Do not call set_lang_adjust_rli. * trans.c (init_code_table): Make static. (gnat_init_stmt_group): Delete. (gigi): Initialize the translation code entirely here. Emit debug info for the common types here instead of... * utils.c (gnat_init_decl_processing): ...here. * gigi.h (init_code_table): Delete. (gnat_init_stmt_group): Likewise. * stor-layout.c (lang_adjust_rli): Delete. (set_lang_adjust_rli): Likewise. (layout_type): Do not call lang_adjust_rli hook. * tree.h (set_lang_adjust_rli): Delete. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gigi.h trunk/gcc/ada/misc.c trunk/gcc/ada/trans.c trunk/gcc/ada/utils.c trunk/gcc/stor-layout.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34098
[Bug ada/34098] xgcc: Internal error: Segmentation fault (program gnat1)
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-11-19 17:52 --- Should be OK now, reopen if not. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01023.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34098
[Bug fortran/34133] Bind(c): Accepts PROGRAM internal bind(c) procedure
--- Comment #3 from crickett at lanl dot gov 2007-11-19 18:13 --- (In reply to comment #2) > FIXED on the trunk (4.3.0). (Not part of any branch.) > i don't think this constraint exists in F08 (at least i cannot find it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE"
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-11-19 20:26 --- Fixed so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug debug/19523] [4.0/4.1/4.2/4.3 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #10 from tromey at gcc dot gnu dot org 2007-11-19 20:42 --- Perhaps this could be solved now by using the information provided by mapped locations... this is akin to the "replay" idea Eric mentions in the linked-to email. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-19 21:17 --- (In reply to comment #3) > i don't think this constraint exists in F08 (at least i cannot find it). You are right. However, there is still a constrain. Fortran 2003 has: C1236 (R1225) A proc-language-binding-spec with a NAME= specifier shall not be specified in the function-stmt or subroutine-stmt of an interface body for an abstract interface or a dummy procedure. C1237 (R1225) A proc-language-binding-spec shall not be specified for an internal procedure. while http://j3-fortran.org/doc/year/07/07-007r3.pdf has: 12.6.2.2 Function subprogram C1252 (R1229) A proc-language-binding-spec with a NAME= specifier shall not be specified in the function-stmt or subroutine-stmt of an internal procedure, or of an interface body for an abstract interface or a dummy procedure. Thus BIND(C) is allowed for internal procedures, but not BIND(C,name=...). I think the idea is to allow such procedures, e.g., as actual argument; one thing one needs to check is the following: How does this work in terms of name mangling? Assume the following: subroutine foo() contains subroutine bar() bind(c) end subroutine bar end subroutine foo subroutine my() bind(c,name="bar") end subroutine bar This will cause name clashes of "bar". Internal procedures have the advantage that they are internal and have no name clashes problems. I wonder what symbol should be created for the internal procedure with bind(C) symbol. Maybe this is something to check in the standard and ask at the j3 mailing list. The following is invalid per Fortran 2003 and 2008 and accepted by gfortran: subroutine bb(a) interface subroutine a() bind(c, name="foo") ! name= for dummy variable end subroutine a end interface end subroutine bb For the latter, we need a patch which rejects this outright. For the former, I think a patch makes sense which allows it (w/o name=) for -std=gnu (and add a note to PR 33197 to change the GFC_STD_GNU to GFC_STD_F2008 as soon as gfortran has it.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Summary|Bind(c): Accepts PROGRAM|Bind(c,name="") should be |internal bind(c) procedure |rejected for dummies; F2008: ||allow bind(c) for internal ||procs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
--- Comment #17 from jason at gcc dot gnu dot org 2007-11-19 21:24 --- is a dup of 28834. *** This bug has been marked as a duplicate of 28834 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #29 from jason at gcc dot gnu dot org 2007-11-19 21:24 --- *** Bug 29436 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-19 21:27 --- Ok. Found it in "15.5.2 Binding labels for procedures" of the Fortran 2008 draft with the expected wording: "If a procedure has the BIND attribute with no NAME= specifier, and the procedure is not a dummy procedure, internal procedure, or procedure pointer, then the binding label of the procedure is the same as the name of the procedure using lower case letters. Otherwise, the procedure has no binding label." Thus it can be handled the same way as gfortran does for 'bind(c,name="")': Simply use the Fortran name (which encodes the module name and parent procedure name). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
--- Comment #18 from jason at gcc dot gnu dot org 2007-11-19 21:35 --- Subject: Bug 29436 Author: jason Date: Mon Nov 19 21:35:13 2007 New Revision: 130297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130297 Log: PR debug/29436, c/32326 * tree.c (build_type_attribute_qual_variant): Refuse to make a distinct copy of a struct/enum type. Use build_distinct_type_copy. * doc/extend.texi (Type Attributes): Don't encourage people to add attributes to struct/enum types in a typedef. Fix transparent_union example. * tree-inline.c (remap_type_1): Remove code that's redundant with remap_type. (build_duplicate_type): Set id.copy_decl. * c-common.c (handle_transparent_union_attribute): Simplify logic. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c trunk/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c trunk/gcc/tree-inline.c trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c/34154] New: gcc 4.1.1 bug / case ranges / unsigned long long
The following program should print "19==19", not "19==20".
It is a big switch/case with 'case ranges', whose values are 'unsigned long
long'. It wokrs for most values except the last range.
More details here:
http://groups.google.com/group/gnu.gcc/browse_thread/thread/e48be6e521697259#eacdee661f68b550
#include
#define BIG_NUM 100ULL
static int foo( unsigned long long aLL )
{
switch( aLL )
{
case BIG_NUM ... 999ULL : return 19 ;
default : return 20 ;
};
};
int main( int argC, const char ** argV )
{
unsigned long long aLL = BIG_NUM ;
printf("19 == %d\n", foo( aLL ) );
return 0 ;
};
"this code does produce the value 19
on i686-pc-linux-gnu with gcc 2.95.3, 3.3.6, and 3.4.6,
but the value 20 with gcc 4.0.4, 4.1.2, and 4.2.2. "
It is taken from a sourceforge project:
http://itoa.cvs.sourceforge.net/*checkout*/itoa/itoa/itoa.c?revision=1.1.1.1
--
Summary: gcc 4.1.1 bug / case ranges / unsigned long long
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: remi dot chateauneu at gmail 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=34154
[Bug c/34154] gcc 4.1.1 bug / case ranges / unsigned long long
--- Comment #1 from remi dot chateauneu at gmail dot com 2007-11-19 21:47 --- Created an attachment (id=14582) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14582&action=view) Small program demonstrating the bug. this code does produce the value 19 on i686-pc-linux-gnu with gcc 2.95.3, 3.3.6, and 3.4.6, but the value 20 with gcc 4.0.4, 4.1.2, and 4.2.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34154
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #4 from dominiq at lps dot ens dot fr 2007-11-19 22:19 --- > OK, so you need to file a bug report to Apple. I'll do it as soon as I have checked what's happen on PPC. I have justa question: in which library is frexpf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #30 from jason at gcc dot gnu dot org 2007-11-19 22:32 --- Subject: Bug 28834 Author: jason Date: Mon Nov 19 22:32:30 2007 New Revision: 130298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130298 Log: note PR 28834 Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #31 from jason at gcc dot gnu dot org 2007-11-19 22:34 ---
The crash is fixed by ignoring the attribute on the typedef. If you want to
apply may_alias to a struct type, you need to specify it in the type
definition, either as
struct __attribute ((may_alias)) name { ... };
or
struct name { ... } __attribute ((may_alias));
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/28879] [4.0/4.1/4.2/4.3 regression] ICE with VLA in template function
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-19 23:31 --- http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01014.html fixes the second testcase. -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01014.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28879
[Bug target/34155] New: [4.3 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:2666 on sh64
With -O, gcc.c-torture/compile/simd-2.c ICEs with
internal compiler error: in simplify_binary_operation_1, at simplify-rtx.c:2666
on sh64. It didn't fail on revision 127620, so this is a 4.3 regression.
The backtrace with gdb looks like
#1 0x08388b7d in simplify_binary_operation (code=VEC_SELECT, mode=SFmode,
op0=0xa6a, op1=0x87d1c52) at ../../ORIG/trunk/gcc/simplify-rtx.c:2875
#2 0x086c6b05 in combine_simplify_rtx (x=0x40239888, op0_mode=SFmode,
in_dest=0) at ../../ORIG/trunk/gcc/combine.c:4706
#3 0x086c933a in subst (x=0x40239888, from=0x40234110, to=0x401a30c0,
in_dest=0, unique_copy=0) at ../../ORIG/trunk/gcc/combine.c:4541
and the first parameter of combine_simplify_rtx at #2 is:
(vec_select:SF (plus:SF (vec_select:SF (reg:V2SF 163)
(parallel [
(const_int 0 [0x0])
]))
(vec_select:SF (reg:V2SF 175)
(parallel [
(const_int 0 [0x0])
])))
(parallel [
(const_int 0 [0x0])
]))
simplify_binary_operation_1 checks if the first argument of vec_select
is VECTOR_MODE_P when the mode of vec_select is a scalar type:
case VEC_SELECT:
if (!VECTOR_MODE_P (mode))
{
gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
but the above rtl isn't. Thus the above gcc_assert fails.
It seems that combine optimization makes a rtl like
(vec_select:SF
(vec_select:V2SF
(vec_concat:V2SF
(vec_select:SF (reg:V2SF 187)
(parallel [
(const_int 1 [0x1])
]))
(plus:SF (vec_select:SF (reg:V2SF 163)
(parallel [
(const_int 0 [0x0])
]))
(vec_select:SF (reg:V2SF 175)
(parallel [
(const_int 0 [0x0])
]
(parallel [
(const_int 1 [0x1])
(const_int 0 [0x0])
]))
(parallel [
(const_int 0 [0x0])
]))
and simplify_binary_operation_1 simplifies it to
(vec_select:SF
(plus:SF (vec_select:SF (reg:V2SF 163)
(parallel [
(const_int 0 [0x0])
]))
(vec_select:SF (reg:V2SF 175)
(parallel [
(const_int 0 [0x0])
])))
(parallel [
(const_int 0 [0x0])
]))
with the code flow
case VEC_SELECT:
if (!VECTOR_MODE_P (mode))
{
gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
...
/* Extract a scalar element from a nested VEC_SELECT expression
(with optional nested VEC_CONCAT expression). Some targets
(i386) extract scalar element from a vector using chain of
nested VEC_SELECT expressions. When input operand is a memory
operand, this operation can be simplified to a simple scalar
load from an offseted memory address. */
if (GET_CODE (trueop0) == VEC_SELECT)
{
...
/* Handle the case when nested VEC_SELECT wraps VEC_CONCAT. */
if (GET_CODE (op0) == VEC_CONCAT)
...
tmp = gen_rtx_fmt_ee (code, mode,
tmp_op, gen_rtx_PARALLEL (VOIDmode, vec));
return tmp;
}
in the failed case.
Then at the another simplify_binary_operation_1 invocation, the last
rtl is considered a problematic one.
--
Summary: [4.3 Regression] ICE in simplify_binary_operation_1, at
simplify-rtx.c:2666 on sh64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34155
[Bug fortran/33317] [4.3 regression]CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-11-20 01:51 --- Subject: Bug 33317 Author: jvdelisle Date: Tue Nov 20 01:51:04 2007 New Revision: 130305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130305 Log: 2007-11-19 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/33317 * gfortran.dg/optional_dim_2.f90: Remove test. Removed: trunk/gcc/testsuite/gfortran.dg/optional_dim_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug fortran/33317] [4.3 regression]CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-11-20 01:37 --- Subject: Bug 33317 Author: jvdelisle Date: Tue Nov 20 01:37:43 2007 New Revision: 130304 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130304 Log: 2007-11-19 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/33317 * trans-expr.c (gfc_conv_missing_dummy): Revert. * iresolve.c (gfc_resolve_cshift): Revert. (gfc_resolve_eoshift): Likewise. * check.c (gfc_check_cshift): Revert. (gfc_check_eoshift): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug c/34156] New: gcc ignores the __may_alias__ attribute on a struct typedef
gcc ignores the __may_alias__ attribute on a struct typedef This is gcc as of Mon Nov 19 21:35:13 2007 UTC. There are numerous problems with forcing users to put the attribute there. First of all, given the number of people who put the attribute on the typedef, that is clearly what people find to be natural. Second of all, the struct definition may be coming from a header file that the user does not control. Third of all, the need for both aliasing and non-aliasing versions of a struct creates data type incompatibilities if one can not simply be a typedef that refers to the other. See also: #28834, #29436, and the numerous duplicates of both. (people REALLY expect this syntax to work) -- Summary: gcc ignores the __may_alias__ attribute on a struct typedef Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
[Bug rtl-optimization/34157] New: freebsd 6.3 jdk1.5 build internal compiler error: Segmentation fault: 11
deep# uname -a
FreeBSD deep.blue.inc 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Sun Nov 18
20:27:57 MST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEEPKERN i386
deep# gcc --version
gcc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
AMD 2.4gig
last pid: 13938; load averages: 0.06, 0.03, 0.04up 0+20:47:45 18:54:47
79 processes: 3 running, 76 sleeping
CPU states: 1.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 98.2% idle
Mem: 135M Active, 783M Inact, 186M Wired, 784K Cache, 112M Buf, 889M Free
Swap: 2023M Total, 2023M Free
deep#cd /usr/ports/java/jdk15
deep#make install clean
...
Compiling
/usr/ports/java/jdk15/work/hotspot/src/share/vm/runtime/deoptimization.cpp
In file included from ../generated/incls/_deoptimization.cpp.incl:77,
from
/usr/ports/java/jdk15/work/hotspot/src/share/vm/runtime/deoptimization.cpp:12:
/usr/ports/java/jdk15/work/hotspot/src/share/vm/memory/vmSymbols.hpp:577:
internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake[3]: *** [deoptimization.o] Error 1
gmake[3]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake[2]: *** [the_vm] Error 2
gmake[2]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/jvmg'
gmake[1]: *** [jvmg] Error 2
gmake[1]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp'
gmake: *** [jvmg] Error 2
*** Error code 2
Stop in /usr/ports/java/jdk15.
*** Error code 1
Stop in /usr/ports/java/jdk15.
deep#pwd
/usr/ports/java/jdk15
deep#cat Makefile
# New ports collection makefile for:jdk15
# Date created: 12 January 2005
# Whom: Alexey Zelkin <[EMAIL PROTECTED]>
#
# $FreeBSD: ports/java/jdk15/Makefile,v 1.140 2007/11/15 17:45:00 glewis Exp $
#
PORTNAME= jdk
PORTVERSION=${JDK_VERSION}.${JDK_UPDATE_VERSION}p${JDK_PATCHSET_VERSION}
PORTREVISION= 1
PORTEPOCH= 1
CATEGORIES= java devel
MASTER_SITES= # http://download.java.net/tiger/
#http://www.eyesbeyond.com/freebsddom/java/jdk15.html
#http://java.sun.com/javase/downloads/index.jsp
DISTFILES= ${JRL_SRCFILE} ${JRL_BINFILE} ${PATCHSETFILE}
EXTRACT_ONLY= ${JRL_SRCFILE} ${JRL_BINFILE}
MAINTAINER= [EMAIL PROTECTED]
COMMENT=Java Development Kit 1.5.0
BUILD_DEPENDS= gm4:${PORTSDIR}/devel/m4 \
zip:${PORTSDIR}/archivers/zip \
${X11BASE}/lib/libXm.so:${PORTSDIR}/x11-toolkits/open-motif
RUN_DEPENDS=javavm:${PORTSDIR}/java/javavmwrapper
OPTIONS=DEBUG "Enable debugging support" off \
OPTIONS+= WEB "Enable the browser plugin and Java Web Start" on
.endif
OPTIONS+= POLICY "Install the Unlimited Strength Policy Files" off \
TZUPDATE"Update the time zone data" on \
JAIL"Port is being built within a jail" off
WANT_GNOME= yes
PKGINSTALL= ${WRKDIR}/pkg-install
PKGDEINSTALL= ${WRKDIR}/pkg-deinstall
SUB_FILES+= pkg-install \
pkg-deinstall
SUB_LIST+= JRE_HOME=${PREFIX}/jdk${JDK_VERSION}/jre \
ARCH=${MACHINE_ARCH}
WRKSRC= ${WRKDIR}/control/make
USE_ZIP=YES
JRL_SRCFILE=
jdk-${JDK_VERSION:S/./_/g}_${JDK_UPDATE_VERSION}-fcs-src-b${JDK_
BUILD_NUMBER}-jrl-${JDK_BUILD_DATE}.jar
JRL_BINFILE=
jdk-${JDK_VERSION:S/./_/g}_${JDK_UPDATE_VERSION}-fcs-bin-b${JDK_
BUILD_NUMBER}-jrl-${JDK_BUILD_DATE}.jar
PATCHSETFILE= bsd-jdk15-patches-${JDK_PATCHSET_VERSION}.tar.bz2
POLICYFILE= jce_policy-${JDK_VERSION:S/./_/g}.zip
TZUPDATEFILE= tzupdater-${TZUPDATE_VERSION:S/./_/g}-${TZUPDATE_TZVERSION}.zip
JDK_VERSION=1.5.0
JDK_UPDATE_VERSION= 13
JDK_PATCHSET_VERSION= 7
JDK_BUILD_NUMBER= 05
JDK_BUILD_DATE= 25_sep_2007
LATEST_LINK=jdk15
TZUPDATE_VERSION= 1.3.0
TZUPDATE_TZVERSION= 2007h
.if !defined(WITH_LINUX_BOOTSTRAP)
NATIVE_BOOTSTRAP_JDKS+= ${LOCALBASE}/diablo-jdk1.5.0 \
${LOCALBASE}/jdk1.5.0 \
${LOCALBASE}/jdk1.4.2
.endif
LINUX_BOOTSTRAP_JDKS= ${LOCALBASE}/linux-sun-jdk1.5.0 \
${LOCALBASE}/linux-sun-jdk1.4.2
.include
.if defined(WITH_IPV6)
CATEGORIES+=ipv6
.endif
.if defined(WITH_POLICY)
DISTFILES+= ${POLICYFILE}
EXTRACT_ONLY+= ${POLICYFILE}
.endif
.if defined(WITH_TZUPDATE)
DISTFILES+= ${TZUPDATEFILE}
EXTRACT_ONLY+= ${TZUPDATEFILE}
.endif
# do we have valid native jdk installed?
.if !defined(WITH_LINUX_BOOTSTRAP)
.for CJDK in ${NATIVE_BOOTSTRAP_JDKS}
. if !defined(BOOTSTRAPJDKDIR) && exist
[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-20 02:24 --- Please read the dicussion starting at: http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
[Bug rtl-optimization/34157] freebsd 6.3 jdk1.5 build internal compiler error: Segmentation fault: 11
--- Comment #1 from nitefalll at gmail dot com 2007-11-20 02:22 --- I'm an advanced beginner. So if I can help provide more data please ask. Be warned you may need to help me figure out how to acquire the extra data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34157
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #2 from huamama at gmail dot com 2007-11-20 03:30 --- I build the toolchains use buildroot, the gcc version is 4.1.2, the target platform is arm, host platform is cygwin. The busybox version is 1.1.3 If i uncomment some configure of busybox, a new error will show as following: LINK busybox_unstripped /home/mahua/opt/test/busybox-1.1.3/networking/telnetd.c: In function 'telnetd_main': /home/mahua/opt/test/busybox-1.1.3/networking/telnetd.c:541: warning: pointer targets in passing argument 3 of 'accept' differ in signedness /home/mahua/opt/test/busybox-1.1.3/editors/vi.c: In function 'do_cmd': /home/mahua/opt/test/busybox-1.1.3/editors/vi.c:3846: 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. make[1]: *** [busybox_unstripped] Error 1 make: *** [_all] Error 2 -- huamama at gmail dot com changed: What|Removed |Added CC||huamama at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug c++/34158] New: Template delete doesn't call if exception thrown in constructor
I recently have been discovered some issue on gcc 4.1.2.
Here is my system:
OS:Intel-P4,WindowXP+SP2
Cygwin:Setup.exe version 2.573.2.2
config.status: "./configure --enable-languages=c,c++,java,objc"
Command line: g++ test.cpp > a 2> b
Minimal example (test.cpp):
///
#include
#include
//dummy...
template class TAlignedMem {};
struct A1 { A1() { throw 0; } }; //throwing in ctor
unsigned char* pAlloc1 = 0;
//Some user new
template
void* operator new(size_t n,TAlignedMem) /*throw()*/ {
unsigned char*const pRawMemory = pAlloc1 = reinterpret_cast(operator new(n+32));
for(int i = 0; i < 32; i++) {
pRawMemory[i] = 0xCC;
}
printf("user new\n");
return pRawMemory+32;
}
void DumpBlock(void* p) {
if(!p) return;
unsigned char*const pRawMemoryWithOffset = reinterpret_cast(p);
unsigned char*const pRawMemory = pRawMemoryWithOffset-32;
for(int i = 0; i < 32/4; i++) {
printf("0x%08X ",((unsigned int*)pRawMemory)[i]);
}
printf("\n");
}
//Some user delete
template
void operator delete(void* p,TAlignedMem) /*throw()*/ {
unsigned char*const pRawMemoryWithOffset = reinterpret_cast(p);
unsigned char*const pRawMemory = pRawMemoryWithOffset-32;
printf("user delete: ");
DumpBlock(p);
operator delete(pRawMemory);
}
int main() {
A1* p1 = 0;
try {
p1 = new ((TAlignedMem())) A1;
}
catch(...) {
printf("catch(...)\n");
}
printf("dumped block: ");
DumpBlock(pAlloc1);
return 0;
}
///
a.exe output:
///
user new
catch(...)
dumped block: 0x 0x 0x 0x 0x 0x
0x 0x002B
///
If you try correct code from here:
///
//Some user delete
template
void operator delete(void* p,TAlignedMem) /*throw()*/ {
///
To this one:
///
//Some user delete
void operator delete(void* p,TAlignedMem) /*throw()*/ {
///
And try run again:
///
user new
user delete: 0x 0x 0x 0x 0x 0x
0x 0x
catch(...)
dumped block: 0x 0x 0x 0x 0x 0x
0x 0x0061
///
"delete" will call successfully.
--
Summary: Template delete doesn't call if exception thrown in
constructor
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andry at inbox dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #66 from patchapp at dberlin dot org 2007-11-20 05:02 --- Subject: Bug number PR31608 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00898.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/34108] ICE: Segmentation fault occurs by "write(*,0)" statement
--- Comment #5 from patchapp at dberlin dot org 2007-11-20 05:03 --- Subject: Bug number PR 34108 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00932.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34108
[Bug fortran/25252] ICE on invalid code
--- Comment #20 from patchapp at dberlin dot org 2007-11-20 05:03 --- Subject: Bug number PR 25252 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00949.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #6 from patchapp at dberlin dot org 2007-11-20 05:04 --- Subject: Bug number PR34133 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00956.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #16 from patchapp at dberlin dot org 2007-11-20 05:04 --- Subject: Bug number PR33317 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00962.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug fortran/34137] Module function with ENTRY rejected
--- Comment #3 from patchapp at dberlin dot org 2007-11-20 05:04 --- Subject: Bug number PR34137 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00965.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34137
[Bug fortran/34079] Bind(C): Character argument/return value problems
--- Comment #8 from patchapp at dberlin dot org 2007-11-20 05:04 --- Subject: Bug number PR34079 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00980.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected
--- Comment #8 from patchapp at dberlin dot org 2007-11-20 05:05 --- Subject: Bug number PR33945 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00416.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33945
[Bug bootstrap/33396] add --enable-intermodule
--- Comment #6 from patchapp at dberlin dot org 2007-11-20 05:05 --- Subject: Bug number PR33396 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01024.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33396
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #67 from patchapp at dberlin dot org 2007-11-20 05:07 --- Subject: Bug number PR31608 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00898.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-11-20 04:46 --- Created an attachment (id=14583) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14583&action=view) New patch for testing on Darwin and ppc This patch regrssion tests OK on powerpc-linux-gnu. Please test on the Darwin Intel and ppc if you can. The patch is against current trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef
--- Comment #2 from acahalan at gmail dot com 2007-11-20 05:35 --- (In reply to comment #1) > Please read the dicussion starting at: > http://gcc.gnu.org/ml/gcc/2007-11/msg00213.html Discussion noted. It seems like the 100% workable solution is to let the C++ compiler factor attributes into the name mangling scheme. I can also imagine trying to hide the distinction, possibly maintaining it up until the point at which the compiler generates output. This may even be what users would most desire, assuming the C++ exception stuff can be made to work. Making this C-only is another option, though a rather crummy one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34156
[Bug libstdc++/34015] warning in backward_warning.h is illegible
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-08 10:56:30 |2007-11-20 06:03:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34015
[Bug c++/33962] [4.1/4.2/4.3 Regression] ICE at call to overloaded template function with variable-length function argument list
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 06:26 --- Subject: Bug 33962 Author: jakub Date: Tue Nov 20 06:26:11 2007 New Revision: 130308 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130308 Log: PR c++/33962 * pt.c (more_specialized_fn): Don't segfault if one or both argument list end with ellipsis. * g++.dg/overload/template3.C: New test. Added: trunk/gcc/testsuite/g++.dg/overload/template3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33962
[Bug rtl-optimization/34157] freebsd 6.3 jdk1.5 build internal compiler error: Segmentation fault: 11
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-20 06:49 --- The version of the compiler you use is now longer supported. Try with 4.1.x or later and reopen if it still fails. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34157
[Bug c++/33962] [4.1/4.2 Regression] ICE at call to overloaded template function with variable-length function argument list
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 06:39 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE at |at call to overloaded |call to overloaded template |template function with |function with variable- |variable-length function|length function argument |argument list |list http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33962
[Bug c++/28879] [4.0/4.1/4.2/4.3 regression] ICE with VLA in template function
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-20 06:38 --- Subject: Bug 28879 Author: jakub Date: Tue Nov 20 06:38:48 2007 New Revision: 130309 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130309 Log: PR c++/28879 * tree.c (build_cplus_array_type_1): Don't pass any VLA types when processing_template_decl to build_array_type. * g++.dg/template/vla2.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/vla2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28879
[Bug target/27440] [4.0/4.1/4.2/4.3 regression] code quality regression due to ivopts
-- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-11-20 07:36:22 |2007-11-20 07:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug target/27440] [4.0/4.1/4.2/4.3 regression] code quality regression due to ivopts
--- Comment #10 from ubizjak at gmail dot com 2007-11-20 07:36 --- (In reply to comment #9) > What does GCC 4.3 do with the test case of this bug? gcc -Os: .L3: movl%ebx, -4(%edx) incl%eax .L2: addl$4, %edx cmpl%ecx, %eax jb .L3 And the -4(...) is due to PR 26726, look at comment #18. -- ubizjak at gmail dot com changed: What|Removed |Added Last reconfirmed|2007-07-04 22:16:36 |2007-11-20 07:36:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug c++/33878] Pure virtual method body omitted from template
--- Comment #2 from herwig at gdsys dot de 2007-11-20 07:54 --- (In reply to comment #1) > 2.95.3 ICEd on this. I don't know if I can consider this a regression. > > Confirmed. > Shouldn't the keyword say "wrong-code" rather than "accepts-invalid"? Defining a pure virtual method is valid code, shouldn't that apply to templates as well? Regards, Björn A. Herwig Guntermann & Drunck GmbH Systementwicklung Dortmunder Str. 4a D-57234 Wilnsdorf - Germany -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33878
