[Bug middle-end/45422] [4.6 Regression] compile time increases 8x.
--- Comment #10 from davidxl at gcc dot gnu dot org 2010-08-28 06:00 --- fixed in r163610. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug fortran/45435] Automatically generate C interop interface blocks from C code
--- Comment #1 from domob at gcc dot gnu dot org 2010-08-28 07:26 --- I agree, this is also something I thought about in the past. And to be complete, we could also just do the other way round? -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-28 07:26:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45435
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-08-28 07:35 --- Subject: Bug 45436 Author: fxcoudert Date: Sat Aug 28 07:35:10 2010 New Revision: 163611 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163611 Log: PR fortran/45436 * trans-types.c (gfc_init_kinds): Disable TFmode. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
[Bug fortran/45438] New: [OOP] ICE with -fcheck=pointer
Hello, Trying to debug another issue, I have found this ICE, trunk at r163595 [sfili...@localhost bug22]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100827 (experimental) (GCC) [sfili...@localhost bug22]$ gfortran -ggdb -c bug22.f03 [sfili...@localhost bug22]$ gfortran -ggdb -fcheck=pointer -c bug22.f03 bug22.f03: In function 'base_get_nz_row': bug22.f03:58:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [OOP] ICE with -fcheck=pointer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [OOP] ICE with -fcheck=pointer
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 09:04 --- Created an attachment (id=21581) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21581action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45430] segfault in OMP code with threadprivate and copyin
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-28 10:02 --- This is invalid. See OpenMP 3.0, 2.9.4.1, COPYIN restrictions on page 102, lines 17-18: An array with the ALLOCATABLE attribute must be in the allocated state. Each thread's copy of that array must be allocated with the same bounds. In the testcase pb isn't in allocated state. See also http://openmp.org/forum/viewtopic.php?f=5t=7start=10#p292 for more details. I hope this is going to be changed for OpenMP 3.1, when its draft is released, we'll implement it the way it is written there. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45430
[Bug fortran/45438] [OOP] ICE with -fcheck=pointer
-- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-28 10:27:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug fortran/45438] [OOP] ICE with -fcheck=pointer
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-28 10:29 --- Confirmed as a regression appearing between revisions 158215 and 158921, the seg fault is: Reason: KERN_INVALID_ADDRESS at address: 0x0048 gfc_conv_procedure_call (se=0x7fff5fbfd6b0, sym=0x141921b10, arg=0x1419266f0, expr=0x0, append_args=0x0) at ../../work/gcc/fortran/trans-expr.c:3171 3171 if (attr-optional) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #10 from rakdver at gcc dot gnu dot org 2010-08-28 10:37 --- Created an attachment (id=21582) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21582action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #11 from rakdver at gcc dot gnu dot org 2010-08-28 10:38 --- Does the patch fix your problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #12 from rguenther at suse dot de 2010-08-28 11:09 --- Subject: Re: Number of iteration analysis bogus On Sat, 28 Aug 2010, rakdver at gcc dot gnu dot org wrote: --- Comment #11 from rakdver at gcc dot gnu dot org 2010-08-28 10:38 --- Does the patch fix your problem? Yes, that fixes it. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug fortran/45439] New: [OOP] SELECT TYPE bogus complaint about INTENT
With trunk at r163595, I get an error message which is totally bogus: = [sfili...@localhost bug21]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.6.0 20100827 (experimental) (GCC) [sfili...@localhost bug21]$ gfortran -c bug21.f03 bug21.f03:91.11: call aa%mv_to_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT bug21.f03:92.33: if (info == success_) call aa%mv_from_coo(actmp,info) 1 Error: Actual argument at (1) must be definable as the dummy argument 'a' is INTENT = OUT/INOUT == -- Summary: [OOP] SELECT TYPE bogus complaint about INTENT Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 11:15 --- Created an attachment (id=21583) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21583action=view) test case The code compiles cleanly with XLF. If I switch the commented lines in the CLASS DEFAULT clause, it compiles cleanly (but I am not sure about the runtime behaviour, as I have seen other problems down the road in the original application). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45440] New: [OOP] ALLOCATE with SOURCE gives an ICE (segfault)
The following segfaults with the current trunk, a 20100701 trunk, and a 4.5.1 build. type t integer :: x real :: y(5) logical, allocatable :: z(:) end type t type(t) :: mt mt%x = 1 mt%y = [1,2,3,4,5] allocate ( mt%z, source = [ .true., .false., .true.]) ! ICE(segfault) print *, mt%x print *, mt%y print *, mt%z !print *, mt ! Invalid - ultimate allocatable component end Expected: As with ifort and crayftn: It compiles and ./a.out prints 1 1., 2., 3., 4., 5. T, F, T -- Summary: [OOP] ALLOCATE with SOURCE gives an ICE (segfault) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code 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=45440
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
-- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-08-28 11:27:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45440] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-28 11:34 --- Confirmed. One does not even need allocatable components for this. The following also fails: logical, allocatable :: z(:) allocate ( z, source = [ .true., .false., .true.]) ! ICE(segfault) print *, z end -- janus 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-08-28 11:34:22 date|| Summary|[OOP] ALLOCATE with SOURCE |ALLOCATE with SOURCE gives |gives an ICE (segfault) |an ICE (segfault) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug c++/45437] Loses reference during update
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-28 11:40 --- Note that internally there is no such thing as an operator|= for fundamental types, but things are treated like in C. If you were in C, sz.b |= f (sz, sz, sz, 3); there is no sequence point before |= as it's not a function call - and I am not sure your reading of C++ is correct that there is a function call to operator|= and thus a sequence point before it. In fact 5.17/7 says that E1 op= E2 is equal to E1 = E1 op E2 except that E1 is evaluated only once. I can confirm though that EDG returns 1 for your example (which by our reading would be an as valid result). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
-- 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=45436
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 11:46 --- valgrind says: ==29743== Invalid read of size 4 ==29743==at 0x52B37DB: __gmpz_set (in /usr/lib/libgmp.so.3.5.2) ==29743==by 0x532C37: conformable_arrays (resolve.c:6525) ==29743==by 0x533175: resolve_allocate_expr (resolve.c:6679) ==29743==by 0x533EA6: resolve_allocate_deallocate (resolve.c:6990) ==29743==by 0x537AB4: resolve_code (resolve.c:9017) ==29743==by 0x541422: resolve_codes (resolve.c:13320) ==29743==by 0x54151D: gfc_resolve (resolve.c:13347) ==29743==by 0x51E86A: resolve_all_program_units (parse.c:4187) ==29743==by 0x51EEE5: gfc_parse_file (parse.c:4416) ==29743==by 0x562C6E: gfc_be_parse_file (f95-lang.c:241) ==29743==by 0xA35DA8: compile_file (toplev.c:971) ==29743==by 0xA38051: do_compile (toplev.c:2321) ==29743== Address 0x7c is not stack'd, malloc'd or (recently) free'd -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Known to fail||4.5.2 4.6.0 Summary|ALLOCATE with SOURCE gives |[F03] ALLOCATE with SOURCE |an ICE (segfault) |gives an ICE (segfault) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 11:51 --- The following variant segfaults as well (same backtrace): logical, allocatable :: z(:) logical, dimension(1:3) :: src = (/ .true., .false., .true. /) allocate ( z, source = src) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-28 11:55 --- It works though when explicitly specifying the size of z to allocate: logical, allocatable :: z(:) allocate ( z(3), source = [ .true., .false., .true. ] ) print *, z end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 12:18 --- Reduced test case: module d_base_mat_mod implicit none type :: d_base_sparse_mat contains procedure, pass(a) :: mv_to_coo = d_base_mv_to_coo end type d_base_sparse_mat interface subroutine d_base_mv_to_coo(a) import d_base_sparse_mat class(d_base_sparse_mat), intent(inout) :: a end subroutine d_base_mv_to_coo end interface type :: d_sparse_mat class(d_base_sparse_mat), allocatable :: a end type d_sparse_mat contains subroutine bug21(ax) type(d_sparse_mat), intent(inout) :: ax select type(aa= ax%a) class default call aa%mv_to_coo() end select end subroutine bug21 end module d_base_mat_mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug fortran/45439] [OOP] SELECT TYPE bogus complaint about INTENT
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 12:49 --- Here's the fix: Index: match.c === --- match.c (revision 163612) +++ match.c (working copy) @@ -4532,6 +4532,7 @@ gfc_match_select_type (void) expr1-symtree-n.sym-attr.untyped = 1; else expr1-symtree-n.sym-ts = expr2-ts; + expr1-symtree-n.sym-attr.flavor = FL_VARIABLE; expr1-symtree-n.sym-attr.referenced = 1; expr1-symtree-n.sym-attr.class_ok = 1; } I'll commit as obvious after a regtest. -- 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-08-28 11:27:22 |2010-08-28 12:49:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45439
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #13 from rakdver at gcc dot gnu dot org 2010-08-28 13:39 --- Created an attachment (id=21584) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21584action=view) a new version of the patch There were some problems with the previous patch (that could only manifest for some rather weird loops, but anyway). This one fixes them as well as extends the comments and restructures the function somewhat, which should hopefully make it clearer what's going on. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Attachment #21582|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-28 13:58 --- The same fix is needed on the 4.5 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45353
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #7 from uros at gcc dot gnu dot org 2010-08-28 14:02 --- Subject: Bug 41484 Author: uros Date: Sat Aug 28 14:02:18 2010 New Revision: 163613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163613 Log: PR target/41484 * config/i386/sse.md (sse4_1_extendv8qiv8hi2): Also accept memory operands for operand 1. (sse4_1_extendv4qiv4si2): Ditto. (sse4_1_extendv2qiv2di2): Ditto. (sse4_1_extendv4hiv4si2): Ditto. (sse4_1_extendv2hiv2di2): Ditto. (sse4_1_extendv2siv2di2): Ditto. (sse4_1_zero_extendv8qiv8hi2): Ditto. (sse4_1_zero_extendv4qiv4si2): Ditto. (sse4_1_zero_extendv2qiv2di2): Ditto. (sse4_1_zero_extendv4hiv4si2): Ditto. (sse4_1_zero_extendv2hiv2di2): Ditto. (sse4_1_zero_extendv2siv2di2): Ditto. (*sse4_1_extendv8qiv8hi2): Remove insn pattern. (*sse4_1_extendv4qiv4si2): Ditto. (*sse4_1_extendv2qiv2di2): Ditto. (*sse4_1_extendv4hiv4si2): Ditto. (*sse4_1_extendv2hiv2di2): Ditto. (*sse4_1_extendv2siv2di2): Ditto. (*sse4_1_zero_extendv8qiv8hi2): Ditto. (*sse4_1_zero_extendv4qiv4si2): Ditto. (*sse4_1_zero_extendv2qiv2di2): Ditto. (*sse4_1_zero_extendv4hiv4si2): Ditto. (*sse4_1_zero_extendv2hiv2di2): Ditto. (*sse4_1_zero_extendv2siv2di2): Ditto. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-28 14:05 --- (In reply to comment #4) It works though when explicitly specifying the size of z to allocate: logical, allocatable :: z(:) allocate ( z(3), source = [ .true., .false., .true. ] ) Congratulation - you have found another bug: C633 (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr shall appear [...] In your example both appear. (source-expr is either SOURCE= or MOLD=.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #8 from uros at gcc dot gnu dot org 2010-08-28 14:27 --- Subject: Bug 41484 Author: uros Date: Sat Aug 28 14:27:33 2010 New Revision: 163614 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163614 Log: PR target/41484 * config/i386/sse.md (sse4_1_extendv8qiv8hi2): Also accept memory operands for operand 1. (sse4_1_extendv4qiv4si2): Ditto. (sse4_1_extendv2qiv2di2): Ditto. (sse4_1_extendv4hiv4si2): Ditto. (sse4_1_extendv2hiv2di2): Ditto. (sse4_1_extendv2siv2di2): Ditto. (sse4_1_zero_extendv8qiv8hi2): Ditto. (sse4_1_zero_extendv4qiv4si2): Ditto. (sse4_1_zero_extendv2qiv2di2): Ditto. (sse4_1_zero_extendv4hiv4si2): Ditto. (sse4_1_zero_extendv2hiv2di2): Ditto. (sse4_1_zero_extendv2siv2di2): Ditto. (*sse4_1_extendv8qiv8hi2): Remove insn pattern. (*sse4_1_extendv4qiv4si2): Ditto. (*sse4_1_extendv2qiv2di2): Ditto. (*sse4_1_extendv4hiv4si2): Ditto. (*sse4_1_extendv2hiv2di2): Ditto. (*sse4_1_extendv2siv2di2): Ditto. (*sse4_1_zero_extendv8qiv8hi2): Ditto. (*sse4_1_zero_extendv4qiv4si2): Ditto. (*sse4_1_zero_extendv2qiv2di2): Ditto. (*sse4_1_zero_extendv4hiv4si2): Ditto. (*sse4_1_zero_extendv2hiv2di2): Ditto. (*sse4_1_zero_extendv2siv2di2): Ditto. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #9 from ubizjak at gmail dot com 2010-08-28 14:34 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug c++/986] g++ misses warning for on temporary
--- Comment #29 from redi at gcc dot gnu dot org 2010-08-28 14:39 --- that's why EDG only gives a remark not a warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
--- Comment #2 from schaub-johannes at web dot de 2010-08-28 14:39 ---
(In reply to comment #1)
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
This code is equivalent and is valid. At least, I don't see the Standard
forbidding it. GCC is the only compiler I tested (comeau/edg, clang) that
rejects it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
[Bug c++/986] g++ misses warning for on temporary
--- Comment #30 from redi at gcc dot gnu dot org 2010-08-28 14:42 --- Can we change the summary to mention references? It looks to me as though it's talking about the address-of operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity
--- Comment #4 from chxanders at gmail dot com 2010-08-28 15:03 --- Same problem on 64 bits, but it is one of the -O1 optimisations that does it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-28 15:40 --- The error message is generated in gfc_conv_array_ref it's called via gfc_trans_where_3 - gfc_conv_loop_setup - gfc_add_loop_ss_code - gfc_conv_variable Thus, the condition (mask) ends up at gfc_add_ss_to_loop (loop, css); and the bounds check is added via gfc_conv_loop_setup (loop, tdst-where); Thus, it ends up at loop-pre which comes before the actual loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug target/45299] Dwarf information is wrong with optimised code.
--- Comment #7 from hariharans at picochip dot com 2010-08-28 16:14 --- picochip is a vliw processor and reorder_var_tracking_notes tries to move debug instructions from middle of vliw instructions out. There was a bug in that which resulted in this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299
[Bug target/45299] Dwarf information is wrong with optimised code.
--- Comment #8 from hariharans at picochip dot com 2010-08-28 16:15 --- Created an attachment (id=21585) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21585action=view) Patch to fix the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299
[Bug target/45299] Dwarf information is wrong with optimised code.
--- Comment #9 from hariharans at picochip dot com 2010-08-28 17:17 --- Fixed on mainline. -- hariharans at picochip dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-28 17:42 ---
Ouch!
We need some sort of lazy evaluation.
Like (pseudo-code)
bool scalar_ever_evaluated = false;
whatever_type scalar_value;
while(1)
{
/* loop handling stuff */
if (scalar_ever_evaluated)
{
scalar_value = whatever complicated expression;
scalar_ever_evaluated = true;
}
/* normal code using scalar_value */
}
We have to move back se-pre into se-expr so that it is not moved outside the
loop. Or move it outside the loop conditionally and conditionally add se-pre
inside the loop while evaluating the scalar.
BTW I thought there was already some where-specific code generation for scalar
values.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug c++/45437] Loses reference during update
--- Comment #6 from igodard at pacbell dot net 2010-08-28 17:49 --- Thank you. Don't know about C, but this is C++ in which operators are function. BTW, even in C the standard goes to some lengths in places to make things that look like functions but have odd semantics be defined as macros so as to avoid the semantic guarantees. If the standard says that C++ argument evaluation semantics is different for the arguments of a pre-defined function vs the arguments of a user-declared overload of the same function then this report is invalid. And I would be very surprised :-) Is Gabe still with you guys? I'd guess he'd know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
-- tkoenig 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-08-28 19:51:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug c++/45437] Loses reference during update
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-28 23:48 --- (In reply to comment #6) Thank you. Don't know about C, but this is C++ in which operators are function. Builtin operators are not functions. See e.g. footnote 12 on 1.9p18 in C++ 2003 which makes it clear that builtin operators have very different effects wrt sequence points from user-defined functions: 12) The operators indicated in this paragraph are the built-in operators, as described in clause 5. When one of these operators is over-loaded (clause 13) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation, and the operands form an argument list, without an implied sequence point between them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug target/44309] ../../gcc-4.5/gcc/config/t-darwin:25: warning: overriding commands for target `darwin.o'
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-28 23:59 --- I believe this was fixed by r159979... 2010-05-28 Iain Sandoe ia...@gcc.gnu.org * config.gcc (*-*-darwin*): Adjust t-make fragments for Darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44309
[Bug c++/45437] Loses reference during update
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-29 00:55 --- The sequencing rules have changed in C++0x, but G++ doesn't implement them yet AFAIK, and I'm not sure if the new rules affect this example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #11 from jv244 at cam dot ac dot uk 2010-08-29 05:09 --- After David's patch (thanks!), the testcase requires 240s, that's still a 5x slowdown. I paste the new timing profile below, and reopen the bug. There is no obvious candidate for the slowdown. gfortran -c -ftime-report -cpp -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form test.f90 Execution times (seconds) garbage collection: 12.55 ( 5%) usr 0.03 ( 2%) sys 12.57 ( 5%) wall 0 kB ( 0%) ggc callgraph construction: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 5736 kB ( 0%) ggc callgraph optimization: 0.40 ( 0%) usr 0.02 ( 1%) sys 0.41 ( 0%) wall 725 kB ( 0%) ggc ipa cp: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 1347 kB ( 0%) ggc ipa function splitting: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.07 ( 0%) usr 0.01 ( 1%) sys 0.15 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 2.28 ( 1%) usr 0.00 ( 0%) sys 2.35 ( 1%) wall 4726 kB ( 0%) ggc CFG verifier : 5.54 ( 2%) usr 0.03 ( 2%) sys 5.73 ( 2%) wall 0 kB ( 0%) ggc trivially dead code : 0.67 ( 0%) usr 0.00 ( 0%) sys 0.65 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.28 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 2.00 ( 1%) usr 0.00 ( 0%) sys 2.12 ( 1%) wall 0 kB ( 0%) ggc df live regs : 9.80 ( 4%) usr 0.01 ( 1%) sys 10.18 ( 4%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.62 ( 1%) usr 0.00 ( 0%) sys 3.08 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.22 ( 0%) usr 0.00 ( 0%) sys 1.26 ( 1%) wall 0 kB ( 0%) ggc df live reg subwords : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.27 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.67 ( 2%) usr 0.00 ( 0%) sys 4.44 ( 2%) wall 8317 kB ( 0%) ggc register information : 2.10 ( 1%) usr 0.00 ( 0%) sys 1.97 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 1.73 ( 1%) usr 0.00 ( 0%) sys 1.87 ( 1%) wall 47018 kB ( 3%) ggc alias stmt walking: 0.61 ( 0%) usr 0.07 ( 4%) sys 0.61 ( 0%) wall 6938 kB ( 0%) ggc register scan : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.32 ( 0%) wall 202 kB ( 0%) ggc rebuild jump labels : 0.72 ( 0%) usr 0.00 ( 0%) sys 0.67 ( 0%) wall 0 kB ( 0%) ggc parser: 0.90 ( 0%) usr 0.09 ( 5%) sys 0.99 ( 0%) wall 55368 kB ( 3%) ggc inline heuristics : 0.17 ( 0%) usr 0.01 ( 1%) sys 0.26 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.51 ( 0%) usr 0.01 ( 1%) sys 0.57 ( 0%) wall 48405 kB ( 3%) ggc tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.02 ( 0%) usr 0.01 ( 1%) sys 0.03 ( 0%) wall 11974 kB ( 1%) ggc tree CFG cleanup : 1.30 ( 1%) usr 0.02 ( 1%) sys 1.21 ( 0%) wall 3530 kB ( 0%) ggc tree VRP : 2.50 ( 1%) usr 0.03 ( 2%) sys 2.44 ( 1%) wall 67364 kB ( 4%) ggc tree copy propagation : 0.16 ( 0%) usr 0.05 ( 3%) sys 0.15 ( 0%) wall 1384 kB ( 0%) ggc tree find ref. vars : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.05 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.34 ( 0%) usr 0.00 ( 0%) sys 0.33 ( 0%) wall 5198 kB ( 0%) ggc tree PHI insertion: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.39 ( 0%) usr 0.00 ( 0%) sys 0.35 ( 0%) wall 14011 kB ( 1%) ggc tree SSA other: 0.10 ( 0%) usr 0.04 ( 2%) sys 0.10 ( 0%) wall 432 kB ( 0%) ggc tree SSA incremental : 1.18 ( 0%) usr 0.14 ( 8%) sys 1.44 ( 1%) wall 7441 kB ( 0%) ggc tree operand scan : 0.47 ( 0%) usr 0.33 (19%) sys 0.78 ( 0%) wall 58289 kB ( 3%) ggc dominator optimization: 0.52 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 8527 kB ( 0%) ggc tree SRA : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 1.05 ( 0%) usr 0.05 ( 3%) sys 1.28 ( 1%) wall 4845 kB ( 0%) ggc tree PHI const/copy prop: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 106 kB ( 0%) ggc tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 2014 kB ( 0%) ggc tree reassociation: 0.27 ( 0%) usr 0.03 ( 2%) sys 0.27 ( 0%) wall 6030 kB ( 0%) ggc tree PRE : 0.85 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 7164 kB ( 0%) ggc tree FRE : 0.47 ( 0%) usr 0.02 ( 1%) sys 0.56 ( 0%) wall 5411 kB ( 0%) ggc tree code sinking : 0.11 ( 0%) usr
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-08-29 05:13 --- Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #13 from jv244 at cam dot ac dot uk 2010-08-29 05:20 --- (In reply to comment #12) Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. The comparison is actually against the branches, not releases. However, I'm rebuilding gcc and will report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-08-29 05:23 --- (In reply to comment #12) Extra diagnostic checks enabled; compiler may run slowly. Make sure you configure the trunk with --enable-checking=release to get the same timing results as what a release would be. s/release/release branch/ :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
[Bug middle-end/45422] [4.6 Regression] compile time increases 5x.
--- Comment #15 from jv244 at cam dot ac dot uk 2010-08-29 05:31 --- Similar times (a bit faster) with release checking: Execution times (seconds) garbage collection: 1.17 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.04 ( 0%) usr 0.01 ( 1%) sys 0.04 ( 0%) wall 5670 kB ( 0%) ggc callgraph optimization: 0.32 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 599 kB ( 0%) ggc ipa cp: 0.07 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 1345 kB ( 0%) ggc ipa function splitting: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.11 ( 0%) usr 0.02 ( 1%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 2.67 ( 2%) usr 0.02 ( 1%) sys 2.59 ( 2%) wall 4726 kB ( 0%) ggc trivially dead code : 0.74 ( 0%) usr 0.00 ( 0%) sys 0.72 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.48 ( 0%) usr 0.01 ( 1%) sys 0.35 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 1.73 ( 1%) usr 0.00 ( 0%) sys 2.12 ( 1%) wall 0 kB ( 0%) ggc df live regs : 10.78 ( 7%) usr 0.01 ( 1%) sys 11.16 ( 7%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.60 ( 2%) usr 0.00 ( 0%) sys 3.87 ( 2%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.52 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall 0 kB ( 0%) ggc df live reg subwords : 0.33 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 5.27 ( 3%) usr 0.00 ( 0%) sys 5.42 ( 3%) wall 7568 kB ( 0%) ggc register information : 2.24 ( 1%) usr 0.00 ( 0%) sys 2.19 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 2.33 ( 1%) usr 0.00 ( 0%) sys 2.30 ( 1%) wall 47018 kB ( 3%) ggc alias stmt walking: 0.48 ( 0%) usr 0.05 ( 3%) sys 0.44 ( 0%) wall 6938 kB ( 0%) ggc register scan : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall 394 kB ( 0%) ggc rebuild jump labels : 0.73 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 0 kB ( 0%) ggc parser: 0.85 ( 1%) usr 0.13 ( 7%) sys 0.98 ( 1%) wall 55365 kB ( 3%) ggc inline heuristics : 0.24 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.40 ( 0%) usr 0.06 ( 3%) sys 0.47 ( 0%) wall 48405 kB ( 3%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.03 ( 0%) usr 0.02 ( 1%) sys 0.08 ( 0%) wall 11971 kB ( 1%) ggc tree CFG cleanup : 1.02 ( 1%) usr 0.03 ( 2%) sys 1.14 ( 1%) wall 3522 kB ( 0%) ggc tree VRP : 2.25 ( 1%) usr 0.05 ( 3%) sys 2.18 ( 1%) wall 67051 kB ( 4%) ggc tree copy propagation : 0.24 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 1384 kB ( 0%) ggc tree find ref. vars : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 3806 kB ( 0%) ggc tree PTA : 0.36 ( 0%) usr 0.00 ( 0%) sys 0.26 ( 0%) wall 5193 kB ( 0%) ggc tree PHI insertion: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3194 kB ( 0%) ggc tree SSA rewrite : 0.40 ( 0%) usr 0.02 ( 1%) sys 0.53 ( 0%) wall 14011 kB ( 1%) ggc tree SSA other: 0.09 ( 0%) usr 0.01 ( 1%) sys 0.13 ( 0%) wall 428 kB ( 0%) ggc tree SSA incremental : 1.40 ( 1%) usr 0.09 ( 5%) sys 1.50 ( 1%) wall 7431 kB ( 0%) ggc tree operand scan : 0.45 ( 0%) usr 0.33 (18%) sys 0.82 ( 0%) wall 58289 kB ( 3%) ggc dominator optimization: 0.41 ( 0%) usr 0.04 ( 2%) sys 0.60 ( 0%) wall 8526 kB ( 0%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 1.05 ( 1%) usr 0.02 ( 1%) sys 1.16 ( 1%) wall 4845 kB ( 0%) ggc tree PHI const/copy prop: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 88 kB ( 0%) ggc tree split crit edges : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 2014 kB ( 0%) ggc tree reassociation: 0.25 ( 0%) usr 0.05 ( 3%) sys 0.23 ( 0%) wall 6023 kB ( 0%) ggc tree PRE : 0.81 ( 0%) usr 0.00 ( 0%) sys 0.82 ( 0%) wall 7164 kB ( 0%) ggc tree FRE : 0.43 ( 0%) usr 0.03 ( 2%) sys 0.51 ( 0%) wall 5410 kB ( 0%) ggc tree code sinking : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1311 kB ( 0%) ggc tree linearize phis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.33 ( 0%) usr 0.00 ( 0%) sys 0.30 ( 0%) wall 11812 kB ( 1%) ggc tree phiprop : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 575 kB ( 0%) ggc tree aggressive DCE :
