[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-30 07:02 --- (In reply to comment #2) it prints the following output: ifc: ( 1.000, 0.000) ( 2.000, 0.000) ( 3.000, 0.000) ap Segmentation fault If one changes the order of PROCEDURE statements, one can also call add_poly recursively. The dump by itself looks OK, but I was puzzled by: vtab$polynom.get_degree = get_degree; vtab$polynom.add_poly = add_poly; vtab$polynom.init_from_coeff = (void (*T4cc) (struct class$polynom restrict, struct array1_complex(kind=4) restrict)) init_from_coeff; Why is there a cast for init_from_coeff? Thinking about it a bit more: My vague feeling is that the backend_decl for the module procedure init_from_coeff is not used in the assignment but some external init_from_coeff (with the same assembler name) or something like that. The reason for that could be that the decl is not quite available as the procedures are marked as PRIVATE. -- It works without the PRIVATE and it works if one splits the module and the PROGRAM into two separate files. You could check in (gfc_get_symbol_decl,) gfc_get_extern_function_decl, and gfc_create_function_decl whether the sym-backend_decl for init_from_coeff is always the same - or whether a new, non-gsym(bol) decl is generated in gfc_get_extern_function_decl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug bootstrap/45138] New: [4.6 Regression] Bootstrap ICE on arm-linux: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_lhs, at gimple.h:1724
r162396 OK r162497 KO /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ -B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/ -B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/ -B/n/57/guerby/install-t\ runk-162696/armv5tel-unknown-linux-gnueabi/lib/ -isystem /n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/include -isystem /n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/sys-include -c -g -O2 -gtog\ gle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -f\ no-common -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumb\ er ../../trunk/gcc/expmed.c -o expmed.o ../../trunk/gcc/expmed.c: In function 'init_expmed': ../../trunk/gcc/expmed.c:134:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:141:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:145:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:149:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:153:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:157:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:164:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:180:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:184:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:188:3: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:231:8: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:246:8: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c:247:8: warning: array subscript is above array bounds [-Warray-bounds] ../../trunk/gcc/expmed.c: In function 'extract_fixed_bit_field': ../../trunk/gcc/expmed.c:1703:1: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_lhs, at gimple.h:1724 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [expmed.o] Error 1 make[3]: Leaving directory `/home/guerby/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 -- Summary: [4.6 Regression] Bootstrap ICE on arm-linux: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_lhs, at gimple.h:1724 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: arm-linux-gnueabi GCC host triplet: arm-linux-gnueabi GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45138
[Bug c++/45139] New: constructor call with a single variable as the argument is interpreted as a variable declaration if it's a full expression.
Hopefully this isn't standard defined behavior, because it doesn't make much
sense.
// trying to have some overloaded functions to share some private data:
class A {
private:
// some static stuff
// ...
public:
A(int a, int b = 0) {}
// more versions of A(...)
// ...
};
int main() {
int a = 0;
A(a, 0); // works
A(a); // error: attempting to redeclare a
(A(a)); // this works
}
--
Summary: constructor call with a single variable as the argument
is interpreted as a variable declaration if it's a full
expression.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsdeckerido at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45139
[Bug tree-optimization/45022] No prefetch for the vectorized loop
--- Comment #5 from rguenther at suse dot de 2010-07-30 08:41 --- Subject: Re: No prefetch for the vectorized loop On Thu, 29 Jul 2010, changpeng dot fang at amd dot com wrote: --- Comment #4 from changpeng dot fang at amd dot com 2010-07-29 19:14 --- (In reply to comment #1) The misaligned indirect-refs will vanish soon. I saw your patch that remove ALIGNED_INDIRECT_REF. Do you also plan to remove MISALIGNED_INDIRECT_REF? Thanks. Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45022
[Bug debug/45105] [4.6 Regression] -fcompare-debug failure at -Os
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-30 08:55 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45105
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-30 09:03 --- Remove assignment. I think I won't work on this in the next weeks and New is better in allowing others to pick it up. If not, I will look at it again later. The patch of attachment 20714 plus the fix in comment 15 (plus the test cases at the bottom of attachment 20696) mostly work OK - except for a handful regressions. The implementation was using DT-name as generic function and created the derived type gfc_symbol using the suffix @. It was suggested to do the following - which might be cleaner: - Create the dt name as generic function (as before) - Use ns-derived_types to save the derived types (instead of generating another symbol) I think one can mostly recycle the resolve.c part of the patch - and the gfc_convert_to_structure_constructor's part in primary.c (one can probably get rid of gfc_match_structure_constructor after some modifications). However, all the rest has to be adapted. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/45140] New: valgrind errors when compiling gfortran.dg/typebound_proc_15.f03
$ valgrind ~/gcc-build/gcc/f951 -O -std=f2003 typebound_proc_15.f03
==22333== Memcheck, a memory error detector
==22333== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==22333== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==22333== Command: /home/uros/gcc-build/gcc/f951 -O -std=f2003
typebound_proc_15.f03
==22333==
typebound_proc_15.f03:15.23:
procedure :: bar, baz ! { dg-error PROCEDURE list }
1
Error: Fortran 2008: PROCEDURE list at (1)
==22333== Invalid read of size 8
==22333==at 0x4ACEF7: add_proc_comp (class.c:217)
==22333==by 0x4AD628: add_procs_to_declared_vtab (class.c:305)
==22333==by 0x4AD59A: gfc_find_derived_vtab (class.c:408)
==22333==by 0x4ADA88: gfc_build_class_symbol (class.c:177)
==22333==by 0x4B4CC5: build_sym (decl.c:1162)
==22333==by 0x4BA6C6: gfc_match_data_decl (decl.c:1754)
==22333==by 0x4FAA99: match_word (parse.c:65)
==22333==by 0x4FABFC: decode_statement (parse.c:285)
==22333==by 0x4FC754: next_statement (parse.c:727)
==22333==by 0x4FDC64: parse_spec (parse.c:2434)
==22333==by 0x4FF5A8: parse_progunit (parse.c:3940)
==22333==by 0x4FF8AD: parse_contained (parse.c:3880)
==22333== Address 0x5afd758 is 40 bytes inside a block of size 48 free'd
==22333==at 0x4C20A31: free (vg_replace_malloc.c:325)
==22333==by 0x52AABA: gfc_delete_symtree (symbol.c:2395)
==22333==by 0x52BB46: gfc_undo_symbols (symbol.c:2894)
==22333==by 0x4FA99A: reject_statement (parse.c:1659)
==22333==by 0x4FAABD: match_word (parse.c:70)
==22333==by 0x4FB2E4: decode_statement (parse.c:425)
==22333==by 0x4FC754: next_statement (parse.c:727)
==22333==by 0x4FDF04: parse_spec (parse.c:1882)
==22333==by 0x5003FF: gfc_parse_file (parse.c:4126)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D: toplev_main (toplev.c:945)
==22333==by 0x56E2993: (below main) (in /lib64/libc-2.5.so)
==22333==
==22333== Invalid read of size 1
==22333==at 0x515C45: resolve_fl_derived (resolve.c:10894)
==22333==by 0x514127: resolve_symbol (resolve.c:11508)
==22333==by 0x526986: traverse_ns (symbol.c:3364)
==22333==by 0x5121E3: resolve_types (resolve.c:12973)
==22333==by 0x50BC93: gfc_resolve (resolve.c:13069)
==22333==by 0x50051A: gfc_parse_file (parse.c:4383)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D: toplev_main (toplev.c:945)
==22333==by 0x56E2993: (below main) (in /lib64/libc-2.5.so)
==22333== Address 0x5afd58c is 76 bytes inside a block of size 424 free'd
==22333==at 0x4C20A31: free (vg_replace_malloc.c:325)
==22333==by 0x52BCFF: gfc_undo_symbols (symbol.c:2900)
==22333==by 0x4FA99A: reject_statement (parse.c:1659)
==22333==by 0x4FAABD: match_word (parse.c:70)
==22333==by 0x4FB2E4: decode_statement (parse.c:425)
==22333==by 0x4FC754: next_statement (parse.c:727)
==22333==by 0x4FDF04: parse_spec (parse.c:1882)
==22333==by 0x5003FF: gfc_parse_file (parse.c:4126)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D: toplev_main (toplev.c:945)
==22333==by 0x56E2993: (below main) (in /lib64/libc-2.5.so)
==22333==
==22333== Invalid read of size 1
==22333==at 0x515C56: resolve_fl_derived (resolve.c:10900)
==22333==by 0x514127: resolve_symbol (resolve.c:11508)
==22333==by 0x526986: traverse_ns (symbol.c:3364)
==22333==by 0x5121E3: resolve_types (resolve.c:12973)
==22333==by 0x50BC93: gfc_resolve (resolve.c:13069)
==22333==by 0x50051A: gfc_parse_file (parse.c:4383)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D: toplev_main (toplev.c:945)
==22333==by 0x56E2993: (below main) (in /lib64/libc-2.5.so)
==22333== Address 0x5afd592 is 82 bytes inside a block of size 424 free'd
==22333==at 0x4C20A31: free (vg_replace_malloc.c:325)
==22333==by 0x52BCFF: gfc_undo_symbols (symbol.c:2900)
==22333==by 0x4FA99A: reject_statement (parse.c:1659)
==22333==by 0x4FAABD: match_word (parse.c:70)
==22333==by 0x4FB2E4: decode_statement (parse.c:425)
==22333==by 0x4FC754: next_statement (parse.c:727)
==22333==by 0x4FDF04: parse_spec (parse.c:1882)
==22333==by 0x5003FF: gfc_parse_file (parse.c:4126)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D: toplev_main (toplev.c:945)
==22333==by 0x56E2993: (below main) (in /lib64/libc-2.5.so)
==22333==
==22333== Invalid read of size 1
==22333==at 0x515C5D: resolve_fl_derived (resolve.c:10901)
==22333==by 0x514127: resolve_symbol (resolve.c:11508)
==22333==by 0x526986: traverse_ns (symbol.c:3364)
==22333==by 0x5121E3: resolve_types (resolve.c:12973)
==22333==by 0x50BC93: gfc_resolve (resolve.c:13069)
==22333==by 0x50051A: gfc_parse_file (parse.c:4383)
==22333==by 0x536DA7: gfc_be_parse_file (f95-lang.c:241)
==22333==by 0x82824D:
[Bug lto/45037] lto1 ICEs when linking cns_solve
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:22 --- It can't be the same bug, please open a new one. Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45037
[Bug c++/45139] constructor call with a single variable as the argument is interpreted as a variable declaration if it's a full expression.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-30 09:32 --- It is, and it's well known. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45139
[Bug fortran/45131] [4.6 regression] New Fortran test failures
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:32 --- I see the same with -m32 on x86_64. Interestingly I see it with -O0 and libgfortran from 4.5 as well, so it looks like a frontend problem, not a library problem to me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-30 09:32:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug bootstrap/45138] [4.6 Regression] Bootstrap ICE on arm-linux: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_lhs, at gimple.h:1724
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-30 09:37 --- *** This bug has been marked as a duplicate of 45067 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45138
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-30 09:37 --- *** Bug 45138 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03
--- Comment #12 from janus at gcc dot gnu dot org 2010-07-30 09:38 --- *** Bug 45140 has been marked as a duplicate of this bug. *** -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug fortran/45140] [OOP] valgrind errors when compiling gfortran.dg/typebound_proc_15.f03
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-30 09:38 --- *** This bug has been marked as a duplicate of 44584 *** -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45140
[Bug rtl-optimization/45136] -fcompare-debug failure with -Os -fschedule-insns
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 09:40 --- Confirmed, this seems to be sched1 fault. In bb5 we have 2 normal insns, followed by (-g only) a debug_insn, followed by two NOTE_INSN_DELETED created by combine (do we ever remove these from the IL?), followed again (-g only) by debug_insn and then other insns. sched1 moves those two NOTE_INSN_DELETED in -g case to the start of the block, keeps them where they were otherwise. Alex, can you please have a look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45136
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug rtl-optimization/45130] -fcompare-debug failure with -Os -fsched-spec-load -fschedule-insns
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 09:48 --- This is likely dup of PR45136. Again, NOTE_INSN_DELETED moved just with -g and kept where it was with -g0. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-30 09:48:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45130
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-30 09:58 --- Revision 162697 fixes this pr on powerpc-apple-darwin9. If there is no objection in the coming 12 hours from other ppc platforms, I'll close the pr as fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03
--- Comment #13 from mikael at gcc dot gnu dot org 2010-07-30 10:23 --- I have a patch. -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|mikael at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug lto/45141] New: lto1 ICEs when linking cns_solve again
Current gcc trunk (but not gcc 4.5.1) ICEs when linking cns_solve using -O2 -fwhopr -fwholeprogram. The reduced test case is attached and crashes as... [MacPro:~/badlinkdir2] howarth% more README [MacPro:~/badlinkdir2] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr -fwhole-program --save-temps array_reduced.f [MacPro:~/badlinkdir2] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr -fwhole-program --save-temps cns_reduced.f [MacPro:~/badlinkdir2] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr -fwhole-program --save-temps genic_reduced.f [MacPro:~/badlinkdir2] howarth% gfortran -r -nostdlib -o cns_solve-1007222053.exe array_reduced.o cns_reduced.o genic_reduced.o -DINTEGER='long int' -DCNS_ARCH_TYPE_LINUX -fdefault-integer-8 -O2 -fwhopr -fwhole-program -w In file included from genic_reduced.f:602:0, from genic_reduced.f:602, from :3: array_reduced.f: In function find52_.constprop.0: array_reduced.f:34: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. lto-wrapper: gfortran returned 1 exit status collect2: lto-wrapper returned 1 exit status The lto1 ICE doesn't occur if the optimization is reduced to -O1 or if the -fwhole-program flag is omitted. This crash is distinct from the the resolved one from PR45037. -- Summary: lto1 ICEs when linking cns_solve again Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45141
[Bug lto/45141] lto1 ICEs when linking cns_solve again
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-30 10:43 --- Created an attachment (id=21358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21358action=view) reduced testcase of lto1 crash when linking cns_solve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45141
[Bug target/45142] New: split for *vec_setmode_0_sse2 incomplete
t.c:24:1: error: could not split insn
(insn:TI 20 47 43 (set (mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 0 ax))
(mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(const_int 1 [0x1]))) t.c:16 1424 {*vec_setv4si_0_sse2}
(expr_list:REG_DEAD (reg:SI 0 ax)
(expr_list:REG_EQUAL (vec_merge:V4SI (vec_duplicate:V4SI (mem/j/i:SI
(plus:DI (plus:DI (mult:DI (reg:DI 5 di [orig:68 argc ] [68])
(const_int 4 [0x4]))
(reg/f:DI 7 sp))
(const_int 16 [0x10])) [2 vectmp.4 S4 A32]))
(const_vector:V4SI [
(const_int 0 [0])
(const_int 3 [0x3])
(const_int 2 [0x2])
(const_int 1 [0x1])
])
(const_int 1 [0x1]))
(nil
t.c:24:1: internal compiler error: in final_scan_insn, at final.c:2645
Which is because while the insn matches
(define_insn *vec_setmode_0_sse2
[(set (match_operand:SSEMODE4S 0 nonimmediate_operand =x, x,x,m)
(vec_merge:SSEMODE4S
(vec_duplicate:SSEMODE4S
(match_operand:ssescalarmode 2
general_operand m,*r,x,x*rfF))
(match_operand:SSEMODE4S 1 vector_move_operand C, C,0,0)
(const_int 1)))]
TARGET_SSE2
@
movssescalarmodesuffix\t{%2, %0|%0, %2}
movd\t{%2, %0|%0, %2}
movss\t{%2, %0|%0, %2}
#
[(set_attr type ssemov)
(set_attr mode ssescalarmode,SI,SF,*)])
the only matching split is
(define_split
[(set (match_operand:V4SF 0 memory_operand )
(vec_merge:V4SF
(vec_duplicate:V4SF
(match_operand:SF 1 nonmemory_operand ))
(match_dup 0)
(const_int 1)))]
TARGET_SSE reload_completed
[(const_int 0)]
{
emit_move_insn (adjust_address (operands[0], SFmode, 0), operands[1]);
DONE;
})
which only allows V4SF mode. It probably should be macroized to use
SSEMODE4S.
--
Summary: split for *vec_setmode_0_sse2 incomplete
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86-64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45142
[Bug lto/45141] lto1 ICEs when linking cns_solve again
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-30 10:47 --- The ICE in lto1 backtraces as... gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto1 (gdb) r -fPIC -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase cns_solve-1007222053.exe.ltrans2 -mmacosx-version-min=10.6.4 -mtune=generic -auxbase-strip cns_solve-1007222053.exe.ltrans2.ltrans.o -g -O2 -w -version -fdefault-integer-8 -fwhole-program -fltrans cns_solve-1007222053.exe.ltrans2.o -o cns_solve-1007222053.exe.ltrans2.s Starting program: /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto1 -fPIC -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase cns_solve-1007222053.exe.ltrans2 -mmacosx-version-min=10.6.4 -mtune=generic -auxbase-strip cns_solve-1007222053.exe.ltrans2.ltrans.o -g -O2 -w -version -fdefault-integer-8 -fwhole-program -fltrans cns_solve-1007222053.exe.ltrans2.o -o cns_solve-1007222053.exe.ltrans2.s Reading symbols for shared libraries .. done GNU GIMPLE (GCC) version 4.6.0 20100729 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100729 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.6.0 20100729 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100729 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x expand_expr_real_1 (exp=0x1425365d8, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.6-20100729/gcc/expr.c:8667 8667if (INDIRECT_REF_P (base) (gdb) bt #0 expand_expr_real_1 (exp=0x1425365d8, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.6-20100729/gcc/expr.c:8667 #1 0x00010033c82f in expand_expr_real (exp=0x1425365d8, target=value temporarily unavailable, due to optimizations, tmode=value temporarily unavailable, due to optimizations, modifier=value temporarily unavailable, due to optimizations, alt_rtl=value temporarily unavailable, due to optimizations) at ../../gcc-4.6-20100729/gcc/expr.c:7231 #2 0x000100337266 in expand_expr_real_1 (exp=0x142530d68, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.h:422 #3 0x0001002ceb68 in do_jump (exp=0x142530d68, if_false_label=0x0, if_true_label=0x1425439d8, prob=1) at expr.h:428 #4 0x00010025cfc1 in expand_gimple_cond (bb=value temporarily unavailable, due to optimizations, stmt=0x142529960) at ../../gcc-4.6-20100729/gcc/cfgexpand.c:1692 #5 0x00010025dea1 in expand_gimple_basic_block (bb=0x142516f70) at ../../gcc-4.6-20100729/gcc/cfgexpand.c:3328 #6 0x000100262e48 in gimple_expand_cfg () at ../../gcc-4.6-20100729/gcc/cfgexpand.c:3881 #7 0x0001004f7386 in execute_one_pass (pass=0x100aae920) at ../../gcc-4.6-20100729/gcc/passes.c:1564 #8 0x0001004f765d in execute_pass_list (pass=0x100aae920) at ../../gcc-4.6-20100729/gcc/passes.c:1619 #9 0x0001006289ac in tree_rest_of_compilation (fndecl=0x142519b00) at ../../gcc-4.6-20100729/gcc/tree-optimize.c:452 #10 0x0001007f747d in cgraph_expand_function (node=0x14251f2b0) at ../../gcc-4.6-20100729/gcc/cgraphunit.c:1643 #11 0x0001007fa6fa in cgraph_optimize () at ../../gcc-4.6-20100729/gcc/cgraphunit.c:1722 #12 0x000100019e14 in lto_main (debug_p=value temporarily unavailable, due to optimizations) at ../../gcc-4.6-20100729/gcc/lto/lto.c:2038 #13 0x0001005ba96a in toplev_main (argc=22, argv=0x7fff5fbfee50) at ../../gcc-4.6-20100729/gcc/toplev.c:945 #14 0x000110b4 in start () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45141
[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03
--- Comment #14 from mikael at gcc dot gnu dot org 2010-07-30 11:00 --- (In reply to comment #13) I have a patch. No, I don't. -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mikael at gcc dot gnu dot |janus at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug lto/45141] lto1 ICEs when linking cns_solve again
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45141
[Bug lto/45141] lto1 ICEs when linking cns_solve again
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 --- Subject: Bug 45141 Author: rguenth Date: Fri Jul 30 11:01:22 2010 New Revision: 162709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162709 Log: 2010-07-30 Richard Guenther rguent...@suse.de PR middle-end/45141 * expr.c (expand_expr_real_1): Check for not handled base address. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45141
[Bug debug/45055] another -fcompare-debug failure with uninitialised read in walk_gimple_stmt
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 11:57 --- Created an attachment (id=21359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21359action=view) gcc46-pr45055.patch So far untested 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45055
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 11:59 --- I agree, and after all, we had one of those two functions already, just private to combine.c. See the patch in PR45055. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03
--- Comment #15 from mikael at gcc dot gnu dot org 2010-07-30 12:05 ---
The symtree allocated at decl.c:7811
/* Insert it and set attributes. */
if (!stree)
{
stree = gfc_new_symtree (ns-tb_sym_root, name);
gcc_assert (stree);
}
has to be freed in gfc_undo_symbols, together with its corresponding typebound
procedure at symbol.c:~2960
for (tbp = tentative_tbp_list; tbp; tbp = tbq)
{
tbq = tbp-next;
/* Procedure is already marked `error' by default. */
gfc_free (tbp);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-07-30 12:54 --- I've confirmed that gcc46-pr45055.patch solves this PR too. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug fortran/45143] New: [F2008,corrig1] Endless loop with unlimited edit descriptor
The following is valid according to the F2008 FDIS, but it does not make sense
and is invalid according the the first rounds of interpretation for F08/0030.
gfortran currently ends in an endless loop for the example:
print 20
20 format ( *('a') )
end
As it is a constraint, one needs to diagnose it during compilation, but should
also add it to libgfortran if the string is not checkable.
Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt has for F08/0030
EDITS to 10-007:
[246:15] After C1002 in 10.3.1, add a new constraint:
C1002A (R1005) An unlimited-format-item shall contain at least
one data edit descriptor.
The rest of the request seems to be already covered by gfortran's
implementation.
--
Summary: [F2008,corrig1] Endless loop with unlimited edit
descriptor
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
[Bug target/45127] Out-of-order execution
--- Comment #6 from aleksazr at gmail dot com 2010-07-30 13:56 --- Anyway, the files can be used to generate poor listings, and that is also a bug. See method2.lss -- aleksazr at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug target/45127] Out-of-order execution
--- Comment #7 from aleksazr at gmail dot com 2010-07-30 14:00 --- Poor listings = listings without debug info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #15 from johnfb at mail dot utexas dot edu 2010-07-30 14:00 --- We have also had some trouble with this issue. We found that in general if we where running on a machine with hardware threads (i.e., Intel's Hyper-Threading) then performance was poor. Most of our runs where on a machine with a Intel Xeon L5530 running RHEL 5. Profiling showed that our program was spending 50% of its time inside libgomp. Setting either GOMP_SPINCOUNT or OMP_WAIT_POLICY as discussed in this thread increased performance greatly. Experiments with disabling and enabling cores with default OMP settings showed that when the Hyper-Thread cores come on performance dipped below what we got when we had only one core enabled on some runs. A little thought as to how hardware threads are implemented makes it obvious why spinning for more than a few cycles will cause performance problems. If one hardware threads spins then all other threads on that core may be starved as resources are shared between cores. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug fortran/45131] [4.6 regression] New Fortran test failures
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:06 --- #7 confirms my suspicions. I will try to have a look into this in the next few days. If anyone else has time, please do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:10 --- Mine -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-30 14:10:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
[Bug target/45142] split for *vec_setmode_0_sse2 incomplete
--- Comment #1 from rth at gcc dot gnu dot org 2010-07-30 14:17 --- Test case? -- rth at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45142
[Bug target/45142] split for *vec_setmode_0_sse2 incomplete
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-30 14:24 ---
Created an attachment (id=21360)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21360action=view)
required patch
Together with attached patch (from the vector-enhancement GSoC project).
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
#define vidx(type, vec, idx) (*(((type *) (vec)) + idx))
int main (int argc, char **argv)
{
vector (4, int) i0 = {argc, 1,2,3};
vector(4,int) i2;
vector (4, int) imask = {0,3,2,1};
int a, b, c;
if (argc 4)
__builtin_abort ();
i2 = __builtin_shuffle (imask, i0);
b = 0;
if (vidx (int,imask,b) == vidx (int, i2, b))
__builtin_abort ();
return 0;
}
ICEs at -O2 on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45142
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-30 14:24 --- Trunk is fixed for powerpc64-linux too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 14:30 --- (In reply to comment #0) I would assume the result of doing a get() when !valid() is undefined, No need to assume, it's stated explicitly in the FCD. so throwing an exception when someone does this would be conforming, and a lot more obvious and friendly. If for some reason this couldn't work, even just an assertion fail would be more informative than a NULL pointer deref. Confirming, as an enhancement request. I'm travelling until Tuesday so won't look in detail right now, but IIRC there are possible race conditions so it's not necessarily as simple as just checking for a NULL pointer. -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-30 14:30:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
[Bug debug/45055] another -fcompare-debug failure with uninitialised read in walk_gimple_stmt
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 14:37 --- Subject: Bug 45055 Author: jakub Date: Fri Jul 30 14:36:56 2010 New Revision: 162714 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162714 Log: PR debug/45055 PR rtl-optimization/45137 * rtl.h (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New prototypes. * emit-rtl.c (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New functions. * combine.c (next_nonnote_nondebug_insn): Removed. * ifcvt.c (noce_process_if_block): Use prev_nonnote_nondebug_insn. * haifa-sched.c (queue_to_ready): Use next_nonnote_nondebug_insn. * sched-deps.c (sched_analyze_insn): Likewise. (fixup_sched_groups, deps_start_bb): Use prev_nonnote_nondebug_insn. * rtlanal.c (canonicalize_condition): Likewise. * postreload.c (reload_combine_recognize_pattern): Likewise. (reload_cse_move2add): Use next_nonnote_nondebug_insn. * gcc.dg/pr45055.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45055.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/emit-rtl.c trunk/gcc/haifa-sched.c trunk/gcc/ifcvt.c trunk/gcc/postreload.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45055
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 14:37 --- Subject: Bug 45137 Author: jakub Date: Fri Jul 30 14:36:56 2010 New Revision: 162714 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162714 Log: PR debug/45055 PR rtl-optimization/45137 * rtl.h (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New prototypes. * emit-rtl.c (prev_nonnote_nondebug_insn, next_nonnote_nondebug_insn): New functions. * combine.c (next_nonnote_nondebug_insn): Removed. * ifcvt.c (noce_process_if_block): Use prev_nonnote_nondebug_insn. * haifa-sched.c (queue_to_ready): Use next_nonnote_nondebug_insn. * sched-deps.c (sched_analyze_insn): Likewise. (fixup_sched_groups, deps_start_bb): Use prev_nonnote_nondebug_insn. * rtlanal.c (canonicalize_condition): Likewise. * postreload.c (reload_combine_recognize_pattern): Likewise. (reload_cse_move2add): Use next_nonnote_nondebug_insn. * gcc.dg/pr45055.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45055.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/emit-rtl.c trunk/gcc/haifa-sched.c trunk/gcc/ifcvt.c trunk/gcc/postreload.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-30 14:39 --- On second thoughts, concurrent calls to future::get are also undefined, so simply asserting valid() would be better. I'll do that asap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
[Bug c++/45121] [4.6 Regression] c-c++-common/uninit-17.c
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-30 14:48 --- In fact, revision 162688 gave: FAIL: c-c++-common/uninit-17.c (test for warnings, line 12) FAIL: c-c++-common/uninit-17.c (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c (test for excess errors) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 12) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for excess errors) -- hjl dot tools at gmail dot com changed: What|Removed |Added Last reconfirmed|2010-07-29 09:40:46 |2010-07-30 14:48:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45121
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #53 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30 15:09 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote: --- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29 19:46 --- Thanks. I can more-or-less produce the same assembly with a cross compiler, but just from looking at the assembly and the debugging dumps I can't quite figure out which function is being miscompiled. Can you produce a good (not miscompiled) .s file with a working cc1 and attach that as well for comparison? Just one further point, I know that the problem is related to 2010-07-16 Bernd Schmidt ber...@codesourcery.com PR target/42235 * function.c (record_hard_reg_sets): New static function. (assign_parm_setup_reg): If an optab for extending exists and the generated code clobbbers no hard regs, emit the insn directly and create a REG_EQUIV note. At least at one time, reverting this change restored bootstrap. It probably would be useful to compare .s files with and without this change. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug fortran/45131] [4.6 regression] New Fortran test failures
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-30 15:11 --- I can also reproduce it with -m32 and x86-64. The dump looks OK; if one uses a debugger, one sees that in inquire_via_unit: u-last_record == 0 - instead of the expect 5. but u-flags.access == ACCESS_DIRECT as expected. I wonder whether the information somehow gets lost due to the new fn spec settings for trans-io.c (..._with_spec) - though using .w looks ok - additionally, I do not see how the FE could modify the libraries' unit data in such a way. Side question: Why is st_inquire actually listed as returning an integer if it is void? 362 parm_type = build_pointer_type (st_parameter[IOPARM_ptype_inquire].type); 363 iocall[IOCALL_INQUIRE] = gfc_build_library_function_decl_with_spec ( 364 get_identifier (PREFIX(st_inquire)), .w, 365 gfc_int4_type_node, 1, parm_type); Ditto for st_iolength_done, st_flush, st_endfile, st_backspace, st_rewind, and st_wait -- burnus 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=45131
[Bug tree-optimization/45144] New: SRA optimization issue of bit-field
For the following code:
void baz (unsigned);
extern unsigned buf[];
struct A
{
unsigned a1:10;
unsigned a2:3;
unsigned:19;
};
union TMP
{
struct A a;
unsigned int b;
};
static unsigned
foo (struct A *p)
{
union TMP t;
struct A x;
x = *p;
t.a = x;
return t.b;
}
void
bar (unsigned orig, unsigned *new)
{
struct A a;
union TMP s;
s.b = orig;
a = s.a;
if (a.a1)
baz (a.a2);
*new = foo (a);
}
arm-none-eabi-gcc -O2 generates:
bar:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r3, r4, r5, r6, r7, lr}
mov r4, r0, asl #22
mov r5, r0, lsr #10
movsr4, r4, lsr #22
mov r6, r1
and r5, r5, #7
mov r7, r0, lsr #13
movne r0, r5
blnebaz
.L2:
orr r4, r4, r5, asl #10
orr r7, r4, r7, asl #13
str r7, [r6, #0]
ldmfd sp!, {r3, r4, r5, r6, r7, lr}
bx lr
while arm-none-eabi-gcc -O2 -fno-tree-sra generates:
bar:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r3, r4, r5, lr}
movsr3, r0, asl #22
mov r4, r0
mov r5, r1
movne r0, r0, lsr #10
andne r0, r0, #7
blnebaz
.L2:
str r4, [r5, #0]
ldmfd sp!, {r3, r4, r5, lr}
bx lr
--
Summary: SRA optimization issue of bit-field
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jiez at gcc dot gnu dot org
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45144
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #54 from bernds at gcc dot gnu dot org 2010-07-30 15:12 --- Yeah, that's what I did. I if (0)ed the newly added code block to produce comparisons, but I haven't found anything yet that looks wrong in the dumps (and I can't read PA assembly very well). So it would be useful to pinpoint the problem further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-30 15:29 --- One observation: In case one does not have PRIVATE, one initializes seemingly the global variable __polynomial_MOD_vtab while with PRIVATE and failing, one uses the variables vtab$polynomD which is local in test_poly; admittedly, I do not fully understand the code which sets the TBP to the vtable - shouldn't this be done when the vtable for a type is created rather than every time before it is used? Or couldn't this be done before because there was no -fwhole-file? For types defined in modules, this information should be available after the module procedures have been generated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug c++/45112] [4.5/4.6 regression] Aligned attribute on static class member definition ignored
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-07-30 15:50 --- Subject: Bug 45112 Author: uweigand Date: Fri Jul 30 15:49:34 2010 New Revision: 162716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162716 Log: gcc/ PR c++/45112 * cp/decl.c (duplicate_decls): Merge DECL_USER_ALIGN and DECL_PACKED. gcc/testsuite/ PR c++/45112 * testsuite/g++.dg/pr45112.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr45112.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45112
[Bug debug/45055] [4.5/4.6 Regression] another -fcompare-debug failure with uninitialised read in walk_gimple_stmt
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-30 15:57 --- Fixed on the trunk, will backport to 4.5.2 once 4.5.1 is released. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|another -fcompare-debug |[4.5/4.6 Regression] another |failure with uninitialised |-fcompare-debug failure with |read in walk_gimple_stmt|uninitialised read in ||walk_gimple_stmt Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45055
[Bug c++/45112] [4.5 regression] Aligned attribute on static class member definition ignored
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-30 16:19 --- Fixed in mainline. Will check in to 4.5 after 4.5.1 release. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 regression] Aligned|[4.5 regression] Aligned |attribute on static class |attribute on static class |member definition ignored |member definition ignored Target Milestone|4.5.1 |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45112
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
-- 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|NEW |ASSIGNED Last reconfirmed|2010-07-13 22:20:03 |2010-07-30 16:25:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #18 from janus at gcc dot gnu dot org 2010-07-30 17:50 --- Subject: Bug 44929 Author: janus Date: Fri Jul 30 17:50:28 2010 New Revision: 162724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162724 Log: 2010-07-30 Janus Weil ja...@gcc.gnu.org Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * match.c (match_type_spec): Try to parse derived types before intrinsic types. 2010-07-30 Janus Weil ja...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_derived_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_derived_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug middle-end/45098] Missed induction variable optimization
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-30 17:23 --- Seems -Os specific -- also reproducible on x86. With -O2, the result is expected. David -- davidxl at gcc dot gnu dot org changed: What|Removed |Added CC||davidxl at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098
[Bug c++/45145] printing tabs fails strangely
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 17:54 --- 4.2.1 is no logner supported, and bugs for Apple builds should be reported to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45145
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #19 from janus at gcc dot gnu dot org 2010-07-30 17:55 --- Fixed with r162724. I am planning to backport this to 4.5 in about a week, provided it does not introduce any more regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug c++/45145] New: printing tabs fails strangely
This should print 100 numbers separated by tabs, then 100 x's separated by spaces, then 100 x's separated by tabs, then 100 0's (int not char) separated by tabs. But the last two print fewer than 100--only one line of them. g++ -v -O0 -Wall --save-temps bug.cc Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5659~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5659) /usr/libexec/gcc/i686-apple-darwin10/4.2.1/cc1plus -E -quiet -v -imultilib x86_64 -D__DYNAMIC__ bug.cc -fPIC -mmacosx-version-min=10.6.4 -m64 -mtune=core2 -Wall -O0 -fpch-preprocess -D__private_extern__=extern -o bug.ii ignoring nonexistent directory /usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../../i686-apple-darwin10/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.2.1 /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64 /usr/include/c++/4.2.1/backward /usr/local/include /usr/lib/gcc/i686-apple-darwin10/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /usr/libexec/gcc/i686-apple-darwin10/4.2.1/cc1plus -fpreprocessed bug.ii -fPIC -quiet -dumpbase bug.cc -mmacosx-version-min=10.6.4 -m64 -mtune=core2 -auxbase bug -O0 -Wall -version -D__private_extern__=extern -o bug.s GNU C++ version 4.2.1 (Apple Inc. build 5659) (i686-apple-darwin10) compiled by GNU C version 4.2.1 (Apple Inc. build 5659). GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072 Compiler executable checksum: d1de7f2cb6246ecf28813a5aea73d6f2 /usr/libexec/gcc/i686-apple-darwin10/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o bug.o bug.s /usr/libexec/gcc/i686-apple-darwin10/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. bug.o -lstdc++ -lSystem -lgcc -lSystem -- Summary: printing tabs fails strangely Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: allcock at math dot utexas dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45145
[Bug c++/45145] printing tabs fails strangely
--- Comment #1 from allcock at math dot utexas dot edu 2010-07-30 17:33 --- Created an attachment (id=21361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21361action=view) preprocessed version of 20-line c++ file exhibiting bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45145
[Bug tree-optimization/45144] SRA optimization issue of bit-field
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-30 17:09 --- The solution IMNSHO is to detect adjacent bitfield operations that can be handled together and lower bitfield ops still at the tree level, though soon before expansion, rather than disabling SRA for bitfields. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45144
[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c
--- Comment #16 from sje at cup dot hp dot com 2010-07-30 18:33 --- I just tried the patch in comment #15 and successfully bootstrapped GCC on my 32 bit PA system (including building matmul_i1.c). This was on ToT (r162716). -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-30 18:39 --- (In reply to comment #4) admittedly, I do not fully understand the code which sets the TBP to the vtable - shouldn't this be done when the vtable for a type is created rather than every time before it is used? Well, this is a bit tricky. We do not want to generate unnecessary code for non-OOP programs, therefore we can not simply create a vtab for each derived type, but we only do that if a type is actually used as a CLASS. Another problem is that the vtab init code can be generated multiple times if there are multiple CLASS usage cases in a program (blowing up code size). It might be of advantage to put the vtab init code in a special subroutine. [Preferrably in the same module where the type is declared, but this only makes sense if the module contains polymorphic code.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-30 18:46 --- (In reply to comment #4) One observation: In case one does not have PRIVATE, one initializes seemingly the global variable __polynomial_MOD_vtab while with PRIVATE and failing, one uses the variables vtab$polynomD which is local in test_poly; Good point. Actually the test case is fixed by making the vtab public: Index: gcc/fortran/class.c === --- gcc/fortran/class.c (revision 162723) +++ gcc/fortran/class.c (working copy) @@ -343,6 +344,7 @@ vtab-attr.target = 1; vtab-attr.save = SAVE_EXPLICIT; vtab-attr.vtab = 1; + vtab-attr.access = ACCESS_PUBLIC; vtab-refs++; gfc_set_sym_referenced (vtab); sprintf (name, vtype$%s, derived-name); @@ -357,6 +359,7 @@ if (gfc_add_flavor (vtype-attr, FL_DERIVED, NULL, gfc_current_locus) == FAILURE) goto cleanup; + vtype-attr.access = ACCESS_PUBLIC; vtype-refs++; gfc_set_sym_referenced (vtype); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-30 18:54 --- (In reply to comment #6) Good point. Actually the test case is fixed by making the vtab public: Of course this does not fix the actual problem, but it limits the set of affected cases (and I guess it's a good idea in general). The test case still fails when adding an 'only' clause in the use statement: use polynomial, only: polynom -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug c++/45121] [4.6 Regression] c-c++-common/uninit-17.c
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-30 18:54 --- Fixed by revision 162720. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45121
[Bug middle-end/38002] gcc crash using -fvisibility-ms-compat
--- Comment #6 from binocs38149 at mypacks dot net 2010-07-30 19:01 ---
(In reply to comment #5)
Apple seems to have fixed it a different way:
http://www.opensource.apple.com/source/gcc/gcc-5659/gcc/cp/decl2.c
{
tree underlying_type = TREE_TYPE (DECL_NAME (decl));
int underlying_vis = type_visibility (underlying_type);
if (underlying_vis == VISIBILITY_ANON
/* APPLE LOCAL begin 6983171 */
|| (TREE_CODE (underlying_type) == RECORD_TYPE
CLASSTYPE_VISIBILITY_SPECIFIED (underlying_type)))
/* APPLE LOCAL end 6983171 */
constrain_visibility (decl, underlying_vis);
else
DECL_VISIBILITY (decl) = VISIBILITY_DEFAULT;
}
Im not sure which approach is better.
--
binocs38149 at mypacks dot net changed:
What|Removed |Added
CC||binocs38149 at mypacks dot
||net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30 19:20 --- Subject: Re: [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c I just tried the patch in comment #15 and successfully bootstrapped GCC on my 32 bit PA system (including building matmul_i1.c). This was on ToT (r162716). I had a dce problem on hppa2.0w-hp-hpux11.11 building libjava. On linux, there are a number of new fortran testsuite errors. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
[Bug bootstrap/45146] New: Bootstrap broken at -O3
tr...@162541 does not bootstrap with BOOT_CFLAGS=-g -O3. Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/dbxout.o differs -- Summary: Bootstrap broken at -O3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45146
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #8 from janus at gcc dot gnu dot org 2010-07-30 20:56 --- (In reply to comment #7) The test case still fails when adding an 'only' clause in the use statement: use polynomial, only: polynom This case can be fixed by the following patchlet: Index: module.c === --- module.c(revision 162723) +++ module.c(working copy) @@ -4370,6 +4370,11 @@ if (p == NULL strcmp (name, module_name) == 0) p = name; + /* Exception: Always import vtabs vtypes. */ + if (p == NULL (strcmp (strndup (name,5), vtab$) == 0 + || strcmp (strndup (name,6), vtype$) == 0)) + p = name; + /* Skip symtree nodes not in an ONLY clause, unless there is an existing symtree loaded from another USE statement. */ if (p == NULL) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #17 from ramana at gcc dot gnu dot org 2010-07-30 22:36 ---
Subject: Bug 43698
Author: ramana
Date: Fri Jul 30 22:35:40 2010
New Revision: 162725
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162725
Log:
Backport fix for PR target/43698.
2010-07-30 Ramana Radhakrishnan ramana.radhakrish...@arm.com
Backport from mainline.
2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/43698
* config/arm/arm.md: Split arm_rev into *arm_rev and *thumb1_rev.
Set *arm_rev to be predicable.
2010-07-30 Ramana Radhakrishnan ramana.radhakrish...@arm.com
Backport from mainline
2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/43698
* gcc.target/arm/pr43698.c: New test.
Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/arm/pr43698.c
- copied unchanged from r162404,
trunk/gcc/testsuite/gcc.target/arm/pr43698.c
Modified:
branches/gcc-4_5-branch/ (props changed)
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/arm/arm.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_5-branch/
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #18 from ramana at gcc dot gnu dot org 2010-07-30 22:38 --- And hence fixed. Thanks for allowing the backport. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #8 from dominiq at lps dot ens dot fr 2010-07-30 22:49 --- Closing. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-30 23:13 --- Someone might want to try this again after the fix for PR 38582. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug c/45147] New: Compiling net-snmp on FreeBSD 8.1 fails
Standard installation of FreeBSD 8.1 on 64 but AMD processor, building package net-mgmt/net-snmp from /usr/ports, command line is make install with the options MFD_REWRITES, PERL, PERL_EMBEDDED, and DUMMY selected. cc (GCC) 4.2.1 20070719 [FreeBSD] libtool: compile: cc -I../include -I. -I../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -DAPPLLIB_EXP=/usr/local/lib/perl5/5.10.1/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.10.1/mach/CORE -c snmp_client.c -fPIC -DPIC -o .libs/snmp_client.o snmp_client.c: In function 'snmp_varbind_len': snmp_client.c:642: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: Compiling net-snmp on FreeBSD 8.1 fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamescarmstrong at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45147
[Bug c++/45148] New: [C++0x] constexpr g++ issues
This is a meta-tracker for g++ issues with constexpr. It tracks the git branch of a href=http://gcc.gnu.org/wiki/Constexpr;contexpr/a. There is another bug for the libstdc++ component. As of 2010-07-30, x86_64/linux see: FAIL: abi_check Running /mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 20_util/duration/arithmetic/dr934-1.cc (test for excess errors) FAIL: 20_util/duration/cons/1.cc (test for excess errors) WARNING: 20_util/duration/cons/1.cc compilation failed to produce executable FAIL: 20_util/duration/cons/2.cc (test for excess errors) WARNING: 20_util/duration/cons/2.cc compilation failed to produce executable FAIL: 20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc (test for excess errors) FAIL: 20_util/duration/requirements/typedefs_neg1.cc (test for excess errors) FAIL: 20_util/duration/requirements/typedefs_neg3.cc (test for excess errors) FAIL: 20_util/time_point/requirements/explicit_instantiation/explicit_instantiation.cc (test for excess errors) === libstdc++ Summary === # of expected passes7875 # of unexpected failures8 # of expected failures 62 # of unsupported tests 11 -- Summary: [C++0x] constexpr g++ issues Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45148
[Bug libstdc++/45149] New: [C++0x] constexpr libstdc++ issues
This is a meta-tracker for libstdc++ issues with constexpr. It tracks the git branch of a href=http://gcc.gnu.org/wiki/Constexpr;contexpr/a. There is another bug for the g++ component (http://gcc.gnu.org/PR45148) Right now some of the static members of random have been made non-static. atomic is missing overloads. complex, io bitmasks, etc, are not done. -- Summary: [C++0x] constexpr libstdc++ issues Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45149
[Bug libstdc++/45149] [C++0x] constexpr libstdc++ issues
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com, gdr ||at gcc dot gnu dot org BugsThisDependsOn||45148 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-31 01:32:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45149
[Bug c++/45148] [C++0x] constexpr g++ issues
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:36 --- Created an attachment (id=21362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21362action=view) FAIL 01: 20_util/duration/arithmetic/dr934-1.cc Pre-processed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45148
[Bug libstdc++/45149] [C++0x] constexpr libstdc++ issues
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:41 --- As of 2010-07-30, x86_64/linux see: FAIL: abi_check Running /mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 20_util/duration/arithmetic/dr934-1.cc (test for excess errors) FAIL: 20_util/duration/cons/1.cc (test for excess errors) WARNING: 20_util/duration/cons/1.cc compilation failed to produce executable FAIL: 20_util/duration/cons/2.cc (test for excess errors) WARNING: 20_util/duration/cons/2.cc compilation failed to produce executable FAIL: 20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc (test for excess errors) FAIL: 20_util/duration/requirements/typedefs_neg1.cc (test for excess errors) FAIL: 20_util/duration/requirements/typedefs_neg3.cc (test for excess errors) FAIL: 20_util/time_point/requirements/explicit_instantiation/explicit_instantiation.cc (test for excess errors) === libstdc++ Summary === # of expected passes7875 # of unexpected failures8 # of expected failures 62 # of unsupported tests 11 Of these, the following are libstdc++ issues directly: FAIL: 20_util/duration/cons/1.cc (and warnings) FAIL: 20_util/duration/cons/2.cc (and warnings) FAIL: 20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc FAIL: 20_util/duration/requirements/typedefs_neg1.cc FAIL: 20_util/duration/requirements/typedefs_neg3.cc FAIL: 20_util/time_point/requirements/explicit_instantiation/explicit_instantiation.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45149
[Bug c++/45148] [C++0x] constexpr g++ issues
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-07-31 01:46 --- That dr-934-1 ICE is the only thing I see. On g++ testing, I see: FAIL: c-c++-common/uninit-17.c (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c (test for excess errors) === g++ Summary === # of expected passes12442 # of unexpected failures2 # of unexpected successes 1 # of expected failures 114 # of unsupported tests 130 So looks pretty good -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45148
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #17 from damian at rouson dot net 2010-07-31 02:30 --- Tobias, Thanks for your continued efforts on this. It will ultimately have a huge impact on the usability of gfortran for my purposes. I look forward to hearing more when you get back to it or when others do. Since there are regressions, I assume I won't get access to your patch just by doing an update using macports (my preferred method for building), but I look forward to trying it out once it's available. Damian (In reply to comment #16) Remove assignment. I think I won't work on this in the next weeks and New is better in allowing others to pick it up. If not, I will look at it again later. The patch of attachment 20714 [edit] plus the fix in comment 15 (plus the test cases at the bottom of attachment 20696 [edit]) mostly work OK - except for a handful regressions. The implementation was using DT-name as generic function and created the derived type gfc_symbol using the suffix @. It was suggested to do the following - which might be cleaner: - Create the dt name as generic function (as before) - Use ns-derived_types to save the derived types (instead of generating another symbol) I think one can mostly recycle the resolve.c part of the patch - and the gfc_convert_to_structure_constructor's part in primary.c (one can probably get rid of gfc_match_structure_constructor after some modifications). However, all the rest has to be adapted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug rtl-optimization/45137] [4.6 Regression] -g changes the generated code for gcc/sched-vis.c on SH
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-07-31 04:45 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
[Bug target/44761] sh.md warnings
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-07-31 04:46 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44761
