[Bug libfortran/50105] [4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 --- Comment #13 from Tobias Burnus 2012-01-10 08:45:21 UTC --- (In reply to comment #12) > Did any interpretation requests go in on this and did we get an answer back? No, but I just wrote one: http://j3-fortran.org/pipermail/j3/2012-January/004976.html The next J3 meeting will be #197, February 13-17, 2012, Las Vegas NV USA The IR should pop up soon at: http://j3-fortran.org/doc/meeting/197/ > I am leaning toward current 4.7 is OK and 4.6 has the regression. Sorry, that twists my mind. 4.6.0 *and* 4.7 produce "**". (While g77 and GCC 4.1 to 4.5 produce "**".) Any reason - in terms of the standard - why you "am leaning toward current 4.7"? I believe that Bob Corbett and Malcolm Cohen are right and "**" is the correct output - even if more compilers have six asterisks: "**": g77, gfortran < 4.6, g95, NAG f95, PGI "**": gfortran >= 4.6.0, ifort, crayftn, open64, pathf95, Sun/Oracle f95, IBM xlf
[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471 --- Comment #18 from vries at gcc dot gnu.org 2012-01-10 08:49:50 UTC --- Author: vries Revision: 183038 Modified property: svn:log Modified: svn:log at Tue Jan 10 08:49:45 2012 -- --- svn:log (original) +++ svn:log Tue Jan 10 08:49:45 2012 @@ -1,4 +1,5 @@ 2012-01-09 Tom de Vries Andrew Pinski +PR debug/51471 * reorg.c (fill_slots_from_thread): Don't speculate frame-related insns.
[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 --- Comment #18 from vries at gcc dot gnu.org 2012-01-10 08:50:45 UTC --- Author: vries Revision: 183052 Modified property: svn:log Modified: svn:log at Tue Jan 10 08:50:40 2012 -- --- svn:log (original) +++ svn:log Tue Jan 10 08:50:40 2012 @@ -1,4 +1,5 @@ 2012-01-10 Tom de Vries +PR rtl-optimization/51271 * dwarf2cfi.c (scan_trace): Save and restore cur_row->reg_save when handling annulled branch.
[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #19 from vries at gcc dot gnu.org 2012-01-10 08:53:43 UTC --- Patch committed in r183052.
[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51471 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from vries at gcc dot gnu.org 2012-01-10 08:54:45 UTC --- Patch committed in r183038.
[Bug fortran/48946] [OOP] Deferred Overloaded Assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48946 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus 2012-01-10 09:00:17 UTC --- FIXED on the trunk (4.7). Thanks for the report Andrew! I think it was done so by the following commit. Submitted patch: http://gcc.gnu.org/ml/fortran/2012-01/msg00026.html Author: pault Date: Thu Jan 5 21:15:52 2012 New Revision: 182929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182929 Log: 2012-01-05 Paul Thomas PR fortran/PR48946 * resolve.c (resolve_typebound_static): If the typebound procedure is 'deferred' try to find the correct specific procedure in the derived type operator space itself. 2012-01-05 Paul Thomas PR fortran/PR48946 * gfortran.dg/typebound_operator_9.f03: This is now a copy of the old typebound_operator_8.f03. * gfortran.dg/typebound_operator_8.f03: New version of typebound_operator_7.f03 with 'u' a derived type instead of a class object. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_9.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
[Bug bootstrap/51796] [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796 --- Comment #9 from Mikael Pettersson 2012-01-10 09:10:07 UTC --- (In reply to comment #8) > Ah, obviously s/REG_UNUSED/REG_NORETURN/g in the patch, sorry for that. With the above modification I can now build a cross successfully. I'll resume my native bootstrap now with it applied and see how it goes.
[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther 2012-01-10 09:15:11 UTC --- Fixed.
[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 --- Comment #9 from Richard Guenther 2012-01-10 09:14:57 UTC --- Author: rguenth Date: Tue Jan 10 09:14:51 2012 New Revision: 183055 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183055 Log: 2012-01-10 Richard Guenther PR tree-optimization/50913 * graphite-scop-detection.c (stmt_has_simple_data_refs_p): Require data-refs to be representable by Graphite with respect to any loop nest. * gcc.dg/graphite/interchange-16.c: New testcase. * gcc.dg/graphite/scop-20.c: XFAIL. * gfortran.dg/graphite/interchange-1.f: Likewise. * gfortran.dg/graphite/block-1.f90: Likewise. * gfortran.dg/graphite/block-2.f: Likewise. Added: trunk/gcc/testsuite/gcc.dg/graphite/interchange-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/scop-20.c trunk/gcc/testsuite/gfortran.dg/graphite/block-1.f90 trunk/gcc/testsuite/gfortran.dg/graphite/block-2.f trunk/gcc/testsuite/gfortran.dg/graphite/interchange-1.f
[Bug ada/51483] [4.7 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 --- Comment #6 from Andreas Schwab 2012-01-10 09:24:48 UTC --- > If I understand correctly, you're changing the interface to pass the object > size (Esize) instead of the precision (RM_Size). That is not correct. I'm just restoring previous behaviour. > Right now, we have the assumption that we can derive the Esize from the > RM_Size > rounded up to the alignment. That completely ignores padding. > If necessary, we can pass both Esize and RM_Size, but the current change seems > like it would break other targets. Those targets would have been broken before. Since nobody appeared to complain so far, those targets don't exit.
[Bug fortran/51197] [4.7 Regression] Backtrace information less useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 --- Comment #10 from Tobias Burnus 2012-01-10 09:32:34 UTC --- Author: burnus Date: Tue Jan 10 09:32:29 2012 New Revision: 183057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183057 Log: 2012-01-10 Tobias Burnus PR fortran/51197 * runtime/compile_options.c (show_signal): List more signals. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/compile_options.c
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #11 from Georg-Johann Lay 2012-01-10 09:42:14 UTC --- Author: gjl Date: Tue Jan 10 09:42:10 2012 New Revision: 183058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183058 Log: libgcc/ PR target/49868 Extend __pgmx semantics to linearize memory. * config/avr/t-avr (LIB1ASMFUNCS): Add _xload_1, _movmemx. * config/avr/lib1funcs.S (__xload_1): New function. (__movmemx_qi, __movmemx_hi): New functions. (__xload_2, __xload_3, __xload_4): Rewrite to fit new __pgmx semantics. gcc/ PR target/49868 Extend __pgmx semantics to linearize memory. * config/avr/avr.md (mov): Use avr_xload_libgcc_p to determine if code comes inline or from libgcc. (MOVMEM_r_d:HI): Add "w" to constraint for better preference. (movmem_qi, movmem_qi): Set constraint #2 to "n". (movmem_qi_elpm, movmem_hi_elpm): Remove insns. (movmemx_qi, movmemx_hi): New insns. (xload__libgcc): Rewrite to new insn condition. (xload_): Remove insns. * config/avr/avr.c (avr_out_xload): Rewrite: Only need to handle cases that don't satisfy avr_xload_libgcc_p(). (avr_addr_space_convert): Allow converting in any direction. (avr_addr_space_subset_p): Return always true. (avr_xload_libgcc_p): Rewrite to fit new __pgmx semantics. (avr_emit_movmemhi): Ditto. (avr_out_lpm): No need to handle ADDR_SPACE_PGMX any more. (avr_out_movmem): Ditto. (AVR_SYMBOL_FLAG_PROGMEM): New macro. (AVR_SYMBOL_SET_ADDR_SPACE): New macro. (AVR_SYMBOL_GET_ADDR_SPACE): New macro. (avr_encode_section_info): Encode 'progmem' in symbol flags. (output_reload_in_const): Don't zero-extend any 24-bit symbols. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S trunk/libgcc/config/avr/t-avr
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #4 from Richard Guenther 2012-01-10
09:43:16 UTC ---
(In reply to comment #3)
> > It says above them "In most cases, these
> > builtins are considered a full barrier." and only __sync_lock_test_and_set
> > and
> > __sync_lock_release specify different barrier semantics.
>
> The next sentence is:
>
> "That is, no memory operand will be moved across the operation, either forward
> or
> backward."
>
> Note that this refers to memory operands, not memory operations -- memory
> stores and memory loads referenced in documentation of the other sync
> builtins.
> In other words, one could interpret "full memory barrier" as:
>
> asm volatile ("" : : : "memory");
>
> that refers to a GCC scheduling barrier.
>
> The GCC documentation references Intel processors, which do not have have a
> distinction between instructions for RELEASE, ACQ_REL and SEQ_CST semantics.
>
> The basic problem is that the GCC builtins and atomic instruction semantics
> were designed for Intel processors that do not provide the level of
> granularity
> implemented in POWER processors. The POWER port implemented lighter weight
> ACQ_REL semantics. Retrofitting the original builtins on the new C++11 memory
> model semantics and imposing SEQ_CST interpretation has changed the behavior
> and performance on POWER, but not on other targets.
But for more precise semantics we now have the __atomic_* builtins, right?
And the __sync_* ones are deprecated. I don't see how we can preserve
old behavior for the __sync_* ones without adding a new target hook.
The documentation would need to be adjusted, of course, I'm not sure
that different atomic semantics are "useful" for these "portable"
synchronization primitives?
Thus, fixing the libstdc++ side seems worthwhile, but I'm not sure
with respect to the deprecated __sync builtins?
[Bug gcov-profile/51807] Fail to generate .gcno file when use libtool to compile la library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51807 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-01-10 09:44:49 UTC --- This is not a bug in GCC but a bug in either libtool/automake or your makefiles.
[Bug fortran/51808] New: Improve handling of ISO_C_BINDING binding names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51808 Bug #: 51808 Summary: Improve handling of ISO_C_BINDING binding names Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org Currently in gfc_symbol we have a field binding_label for the bind(C) binding name. It is a char[] array of size 127. This is suboptimal because 1) For the vast majority of symbols which are not bind(C, name="XXX"), this wastes memory. 2) It might be too short. Fortran limits the length of names to 63 characters, but the binding name is not a Fortran identifier. The C standard says that the implementation should support external identifiers with at least 31 characters, but an implementation is free to support arbitrarily long identifiers. Thus, we should get rid of the notion of limited binding label lengths, and use dynamically allocated storage. Also, slightly related, for .mod files a non-empty binding_label field is needed only if the default name is overridden, saving a bit of space. If time permits, I'm planning to look into this for the 4.8 cycle.
[Bug fortran/51809] New: [4.7 Regression] ICE (use statements order)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809 Bug #: 51809 Summary: [4.7 Regression] ICE (use statements order) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Created attachment 26289 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26289 reduced testcase Attached code ICEs with gfortran-4.7.0 (I've checked snapshots from 2026 till 20120106) Works fine with gcc-4.6.2
[Bug lto/51806] -flto ignores -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51806 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-10 CC||jsm28 at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-01-10 10:03:17 UTC --- Confirmed. It seems that -Werror is a C-family frontend specific option, despite being annotated as 'common'. Only c_common_handle_option has case OPT_Werror: global_dc->warning_as_error_requested = value; break; and thus properly adjusts the diagnostic machinery of the middle-end. But -Werror=... seems to be handled fine (thus, in your case -Werror=uninitialized). That seems inconsistent at least. It looks like the OPT_Werror handling above should move to common_handle_option instead. Joseph?
[Bug libfortran/51803] gfortran getcwd at startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803 --- Comment #2 from Richard Guenther 2012-01-10 10:04:17 UTC --- (In reply to comment #1) > Confirmed. I'll fix it for 4.8, while the patch is trivial we're already in > stage 4 for 4.7. It's certainly fine for 4.7. > Also, can you state your name so that you'll get the proper attribution in the > ChangeLog?
[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801 Richard Guenther changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org
[Bug tree-optimization/51799] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 Richard Guenther changed: What|Removed |Added CC||irar at gcc dot gnu.org --- Comment #1 from Richard Guenther 2012-01-10 10:07:13 UTC --- Did it work with 4.6.x? If so, please mark it as regression.
[Bug fortran/51809] [4.7 Regression][OOP] ICE (segfault) depending on USE statements order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org Target Milestone|--- |4.7.0 Summary|[4.7 Regression] ICE (use |[4.7 Regression][OOP] ICE |statements order) |(segfault) depending on USE ||statements order --- Comment #1 from Tobias Burnus 2012-01-10 10:40:59 UTC --- Unless I made a mistake when bisecting: Working 4.7.0 2009 - Rev. 181198 Failing 4.7.0 2009 - Rev. 181199 That's http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181199 2011-11-09 Janus Weil PR fortran/50960 * class.c (gfc_find_derived_vtab): Make the vtab symbols FL_PARAMETER. * expr.c (gfc_simplify_expr): Prevent vtabs from being replaced with their value. * resolve.c (resolve_values): Use-associated symbols do not need to be resolved again. (resolve_fl_parameter): Make sure the symbol has a value. Valgrind shows: ==2177== Invalid read of size 8 ==2177==at 0x553580: mio_pointer_ref(void*) (module.c:2463) ==2177==by 0xA8: mio_symbol_ref(gfc_symbol**) (module.c:2726) ==2177==by 0x5560E8: mio_expr(gfc_expr**) (module.c:3305) ==2177==by 0x55643D: mio_expr(gfc_expr**) (module.c:2855) ==2177==by 0x55703B: mio_symbol(gfc_symbol*) (module.c:3782) ==2177==by 0x5572B5: write_symbol(int, gfc_symbol*) (module.c:5027) ==2177==by 0x5591B5: write_symbol0(gfc_symtree*) (module.c:5067) ==2177==by 0x559158: write_symbol0(gfc_symtree*) (module.c:5046) ==2177==by 0x559158: write_symbol0(gfc_symtree*) (module.c:5046) ==2177==by 0x559158: write_symbol0(gfc_symtree*) (module.c:5046) ==2177==by 0x559804: gfc_dump_module(char const*, int) (module.c:5243) ==2177==by 0x564CCA: gfc_parse_file() (parse.c:4603)
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #9 from Richard Guenther 2012-01-10
11:18:32 UTC ---
Bootstrap/test seems to work for Andreas (and for my own internal testing) but
still no results from HJ on gcc-testresults.
Still the testcase is broken, reproducible with a bare cross to ia64-linux
and just -O2 (-fexceptions not needed). More reduced testcase:
typedef struct { unsigned long x[2]; } fpreg;
unsigned long
ffi_call(long i, void **avalue, fpreg *fpr)
{
asm ("stf.spill %0 = %1%P0"
: "=m" (*fpr) : "f"(*(double *)avalue[i]));;
return *(unsigned long *)avalue[i];
}
[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 --- Comment #4 from Tobias Burnus 2012-01-10 11:22:24 UTC --- Author: burnus Date: Tue Jan 10 11:22:16 2012 New Revision: 183061 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183061 Log: 2012-01-10 Tobias Burnus PR fortran/51652 * resolve.c (resolve_allocate_expr): For non-deferred char lengths, check whether type-spec matches declaration. 2012-01-10 Tobias Burnus PR fortran/51652 * gfortran.dg/allocate_with_typespec_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #15 from vries at gcc dot gnu.org 2012-01-10 11:31:55 UTC --- (In reply to comment #9) > You don't. We're supposed to prevent frame-related insns > from appearing in branch delay slots. Richard, do you mean this in general, or just for calls? Either way, we should be able to formulate an assert in scan_trace that checks this condition. Do you think that would be useful? Thanks, - Tom
[Bug rtl-optimization/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #10 from Richard Guenther 2012-01-10 12:11:31 UTC --- We are expanding from # BLOCK 5 freq:9100 # PRED: 5 [91.0%] (dfs_back,true,exec) 3 [91.0%] (true,exec) # outptr_89 = PHI # col_90 = PHI D.1396_32 = MEM[base: inptr0_14, index: col_90, offset: 0B]; y_33 = (int) D.1396_32; D.1398_35 = MEM[base: inptr1_19, index: col_90, offset: 0B]; < D.1400_38 = MEM[base: inptr2_24, index: col_90, offset: 0B]; cr.0_40 = (unsigned int) D.1400_38; D.1402_41 = cr.0_40 * 4; D.1403_43 = Crrtab_42(D) + D.1402_41; D.1404_44 = *D.1403_43; D.1405_45 = D.1404_44 + y_33; D.1406_46 = (sizetype) D.1405_45; D.1407_48 = range_limit_47(D) + D.1406_46; D.1408_49 = *D.1407_48; MEM[base: outptr_89, offset: 0B] = D.1408_49; cb.1_51 = (unsigned int) D.1398_35; <-- D.1411_52 = cb.1_51 * 4; D.1412_54 = Cbgtab_53(D) + D.1411_52; D.1413_55 = *D.1412_54; D.1414_59 = Crgtab_58(D) + D.1402_41; D.1415_60 = *D.1414_59; D.1416_61 = D.1413_55 + D.1415_60; D.1417_62 = D.1416_61 >> 16; D.1418_63 = D.1417_62 + y_33; D.1419_64 = (sizetype) D.1418_63; D.1420_65 = range_limit_47(D) + D.1419_64; D.1421_66 = *D.1420_65; MEM[base: outptr_89, offset: 1B] = D.1421_66; D.1423_71 = Cbbtab_70(D) + D.1411_52; D.1424_72 = *D.1423_71; D.1425_73 = D.1424_72 + y_33; D.1426_74 = (sizetype) D.1425_73; D.1427_75 = range_limit_47(D) + D.1426_74; D.1428_76 = *D.1427_75; MEM[base: outptr_89, offset: 2B] = D.1428_76; outptr_77 = outptr_89 + 3; col_78 = col_90 + 1; if (col_78 != num_cols.2_88) goto ; where you can see that we could reduce the lifetime of a QImode register in favor of a SImode register by moving the extension right after the load. This is what both -fschedule-insns and -fschedule-insns -fsched-pressure achieve (which have both good non-regressed code generation). On the tree level there isn't really an issue apart from the fact that after expansion combine sees ;; D.1398_35 = MEM[base: inptr1_19, index: col_90, offset: 0B]; (insn 47 46 0 (set (reg:QI 83 [ D.1398 ]) (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ]) (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90, offset: 0B]+0 S1 A8])) t.c:42 -1 (nil)) ... ;; MEM[base: outptr_89, offset: 0B] = D.1408_49; (insn 54 53 0 (set (mem:QI (reg/v/f:SI 116 [ outptr ]) [0 MEM[base: outptr_89, offset: 0B]+0 S1 A8]) (reg:QI 150)) t.c:45 -1 (nil)) ;; D.1411_52 = cb.1_51 * 4; (insn 55 54 56 (parallel [ (set (reg:SI 151) (zero_extend:SI (reg:QI 83 [ D.1398 ]))) (clobber (reg:CC 17 flags)) ]) t.c:47 -1 (nil)) thus there is a store between the load and the zero_extend (and combine only combines forward, not backward): /* Verify that I2 and I1 are valid for combining. */ if (! can_combine_p (i2, i3, i0, i1, NULL_RTX, NULL_RTX, &i2dest, &i2src) already fails. This is a missed optimization on the RTL level.
[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-10 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-01-10 12:21:53 UTC --- Hmm, works for me.
[Bug c++/51810] New: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810 Bug #: 51810 Summary: internal compiler error Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dtar...@redhat.com SSIA
[Bug c++/51810] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810 --- Comment #1 from David Tardon 2012-01-10 13:15:48 UTC --- Created attachment 26290 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26290 preprocessed source
[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf 2012-01-10 13:18:44 UTC --- It accidentally got fixed by rev.182984: commit 5dcaa6727678300dc8c97480b41a1a8717fd6dbe Author: hubicka Date: Sun Jan 8 00:16:18 2012 + PR tree-optimization/51600 * ipa-inline-analysis.c (estimate_edge_devirt_benefit): Disable code that benefits small functions.
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 Matthew Gretton-Dann changed: What|Removed |Added Known to work||4.6.2 Summary|Compiler ICE in |[4.7 Regression] Compiler |vect_is_simple_use_1|ICE in vect_is_simple_use_1 Known to fail||4.7.0 --- Comment #2 from Matthew Gretton-Dann 2012-01-10 13:27:39 UTC --- Doesn't ICE with GCC 4.6.2.
[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801 --- Comment #3 from Richard Guenther 2012-01-10 13:38:46 UTC --- Author: rguenth Date: Tue Jan 10 13:38:41 2012 New Revision: 183064 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183064 Log: 2012-01-10 Richard Guenther PR tree-optimization/51801 * gcc.dg/torture/pr51801.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr51801.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2012-01-10 13:38:54 UTC --- Fixed then.
[Bug c++/51810] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810 Richard Guenther changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code --- Comment #2 from Richard Guenther 2012-01-10 13:40:26 UTC --- Reducing.
[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 --- Comment #44 from Jason Merrill 2012-01-10 13:44:22 UTC --- There is a conflict between the FreeBSD headers and G++, and we can fix it with fixincludes. Let's do that and move on.
[Bug tree-optimization/51799] [4.7 Regression] Compiler ICE in vect_is_simple_use_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther 2012-01-10 14:03:21 UTC --- Thanks for checking.
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #13 from Tobias Burnus 2012-01-10 14:20:13 UTC --- Created attachment 26291 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26291 Another extensive test case (In reply to comment #12) > Draft patch. That patch unfortunately does not work for all of the tests in the attached file. (Assuming that the test cases are valid.) TODO: * Add also tests for polymorphic components as actual argument * Fix issues found by the test case (and/or fix the test cases)
[Bug libstdc++/51811] New: [C++0x] Incorrect incrementation/decrementation of atomic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51811
Bug #: 51811
Summary: [C++0x] Incorrect incrementation/decrementation of
atomic pointers
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t.schu...@web.de
Incrementation (decrementation) of atomic pointers does not work correctly. On
an x86-64 machine the piece of code given below produces the following output
(or something similar):
0x7fffbe6d082c
0x7fffbe6d082d
0x7fffbe6d0830
0x7fffbe6d082d
There are two problems here: Firstly, the pointer is incremented by 1 and not
by sizeof(int). Secondly, the last two lines of the output should be the same.
Note that the second problem seems to be fixed in gcc-4.7-20120107, while the
first one still occurs. Thanks for your help!
#include
#include
using namespace std;
int main(int argc, char* argv[]) {
int value = 42;
atomic my_pointer;
my_pointer = &value;
cout << my_pointer++ << endl;
cout << my_pointer << endl;
my_pointer = &value;
cout << ++my_pointer << endl;
cout << my_pointer << endl;
}
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #14 from Tobias Burnus 2012-01-10 14:29:39 UTC --- (In reply to comment #13) > TODO: > * Add also tests for polymorphic components as actual argument And a test case where the dummy argument is BT_CLASS.
[Bug c++/51812] New: Virtual public inheritance leads to "undefined reference" in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 Bug #: 51812 Summary: Virtual public inheritance leads to "undefined reference" in header files. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: brede...@ucla.edu Created attachment 26292 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26292 The c++ file that has linker errors. Hi, Using gcc 4.7 causes new linker errors that are not present in e.g. 4.5, 4.6, or clang. These linker errors make it impossible to use header files that do not fully define some classes entirely in the header file. The errors look like: % g++-4.7 all5.C /tmp/ccfEMWL0.o: In function `Object::print() const': all5.C:(.text._ZNK6Object5printEv[_ZNK6Object5printEv]+0x58): undefined reference to `demangle(std::string const&)' /tmp/ccfEMWL0.o: In function `alphabet::compare(Object const&) const': all5.C:(.text._ZNK8alphabet7compareERK6Object[_ZNK8alphabet7compareERK6Object]+0x81): undefined reference to `typeinfo for alphabet' all5.C:(.text._ZNK8alphabet7compareERK6Object[_ZNK8alphabet7compareERK6Object]+0xa5): undefined reference to `operator==(alphabet const&, alphabet const&)' /tmp/ccfEMWL0.o: In function `alphabet::~alphabet()': all5.C:(.text._ZN8alphabetD1Ev[_ZN8alphabetD1Ev]+0xe): undefined reference to `vtable for alphabet' all5.C:(.text._ZN8alphabetD1Ev[_ZN8alphabetD1Ev]+0x26): undefined reference to `vtable for alphabet' /tmp/ccfEMWL0.o: In function `Triplets::Triplets(Triplets const&)': all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x3d): undefined reference to `VTT for Triplets' all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x51): undefined reference to `vtable for Triplets' all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x69): undefined reference to `vtable for Triplets' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x30): undefined reference to `typeinfo for alphabet' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x30): undefined reference to `typeinfo for alphabet' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarray const&, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC3RNA0_11Nucleotides[_ZTV3RNA]+0x
[Bug c++/51812] Virtual public inheritance leads to "undefined reference" in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #1 from bredelin at ucla dot edu 2012-01-10 14:32:46 UTC --- Created attachment 26293 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26293 Preprocessed source
[Bug c++/51433] constexpr caching leads to incorrect dynamic initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51433 --- Comment #2 from Jason Merrill 2012-01-10 14:37:30 UTC --- Author: jason Date: Tue Jan 10 14:37:26 2012 New Revision: 183065 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183065 Log: PR c++/51433 * semantics.c (cxx_eval_call_expression): Always retry previously non-constant expressions. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cache1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51813] New: -fvisibility=hidden causes std::codecvt members to be undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Bug #: 51813
Summary: -fvisibility=hidden causes std::codecvt members to be
undefined
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following program causes undefined symbols when -fvisibility=hidden is
used:
#include
int main()
{
std::use_facet
>(std::locale());
}
g++-4.7 -fvisibility=hidden test.cpp
/tmp/cclBRkzy.o: In function `main':
test.cpp:(.text+0x1d): undefined reference to `std::codecvt const& std::use_facet
>(std::locale const&)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120107/../../../../x86_64-pc-linux-gnu/bin/ld:
a.out: hidden symbol
`_ZSt9use_facetISt7codecvtIwc11__mbstate_tEERKT_RKSt6locale' isn't defined
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha20120107/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status
It works with gcc-4.6.2.
use_facet is only an example. I had other functions like do_length, the
destructor, etc. reported as undefined as well.
[Bug c++/51433] constexpr caching leads to incorrect dynamic initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51433 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill 2012-01-10 14:39:03 UTC --- Fixed for 4.7.
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 --- Comment #5 from David Edelsohn 2012-01-10 14:39:16 UTC --- I understand that fixing __sync_* is a hassle. This is why I opened a separate bug for libstdc++. While __sync_* is deprecated in favor of __atomic_*, use of __sync_* for portability is fairly pervasive in FOSS applications that need it because of its implementation in GCC. Most programmers do not know about memory models and do not care about memory models. And it will take time for programmers to switch to __atomic_*, if they even bother to choose a memory model and don't introduce a bug. The basic problem is MEMMODEL_SEQ_CST only makes a performance difference for POWER and developers are going to continue to use __sync_* builtins for a while. This change in default behavior only hurts performance for applications on POWER relative to all other architectures, which sucks. :-(
[Bug c++/51810] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-10
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther 2012-01-10
14:42:13 UTC ---
Reduced testcase for the 4.6 branch:
template struct allocator_traits {
template static typename _Tp::pointer
_S_pointer_helper(_Tp*);
typedef decltype(_S_pointer_helper((_Alloc*)0)) __pointer;
};
namespace std __attribute__ ((__visibility__ ("default"))) {
template struct allocator;
typedef std::allocator _Alloc;
typedef typename allocator_traits<_Alloc>::template
rebind_traits<_Sp_cd_type> _Alloc_traits;
}
./cc1plus -quiet -std=c++0x t.3.ii
t.3.ii: In instantiation of ‘allocator_traits >’:
t.3.ii:8:46: instantiated from here
t.3.ii:3:53: error: no matching function for call to
‘allocator_traits
>::_S_pointer_helper(std::allocator*)’
t.3.ii:3:53: note: candidate is:
in dependent_type_p, at cp/pt.c:18102
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/51810] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810 --- Comment #4 from Richard Guenther 2012-01-10 14:43:12 UTC --- Created attachment 26294 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26294 autoreduced testcase Reduced testcase for trunk. Program received signal SIGSEGV, Segmentation fault. 0x00af5adb in fold_convert_loc (loc=0, type=0x7584fc78, arg=0x0) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:1856 1856 tree orig = TREE_TYPE (arg); (gdb) bt #0 0x00af5adb in fold_convert_loc (loc=0, type=0x7584fc78, arg=0x0) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:1856 #1 0x0073fbda in cp_fold_convert (type=0x7584fc78, expr=0x0) at /space/rguenther/src/svn/trunk/gcc/cp/cvt.c:585 #2 0x007297ae in build_static_cast_1 (type=0x7584fc78, expr=0x75830700, c_cast_p=0 '\000', valid_p=0x7fff4acf "\001", complain=3) at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:5869 #3 0x0072b3b5 in build_static_cast (type=0x7584fc78, expr=0x75830700, complain=3) at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:6044 #4 0x007d4b3e in move (expr=0x75830700) at /space/rguenther/src/svn/trunk/gcc/cp/tree.c:868
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 --- Comment #6 from Richard Guenther 2012-01-10 14:48:54 UTC --- (In reply to comment #5) > I understand that fixing __sync_* is a hassle. This is why I opened a > separate > bug for libstdc++. > > While __sync_* is deprecated in favor of __atomic_*, use of __sync_* for > portability is fairly pervasive in FOSS applications that need it because of > its implementation in GCC. Most programmers do not know about memory models > and do not care about memory models. And it will take time for programmers to > switch to __atomic_*, if they even bother to choose a memory model and don't > introduce a bug. > > The basic problem is MEMMODEL_SEQ_CST only makes a performance difference for > POWER and developers are going to continue to use __sync_* builtins for a > while. This change in default behavior only hurts performance for > applications > on POWER relative to all other architectures, which sucks. :-( Yes, I see that. But my question is - did a developer reading the documentation get _correct_ code on POWER (which uses a laxer memory model than documented!) in all cases? Or can you construct a testcase that works fine on IA64 while surprisingly (after reading docs) does not work on POWER? Thus, didn't we simply fix a wrong-code bug (albeit by producing slower code)?
[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-01-10 15:02:12 UTC --- No longer relevant.
[Bug lto/49677] GCC 4.6.0 LTO files not compatible with GCC 4.6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther 2012-01-10 15:05:16 UTC --- The issue was fixed differently for trunk. Dup. *** This bug has been marked as a duplicate of bug 44965 ***
[Bug lto/44965] lto option code breaks file format with each added option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965 Richard Guenther changed: What|Removed |Added CC||edwintorok at gmail dot com --- Comment #8 from Richard Guenther 2012-01-10 15:05:16 UTC --- *** Bug 49677 has been marked as a duplicate of this bug. ***
[Bug c/49934] gcc 4.6.1 messes up code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49934 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Richard Guenther 2012-01-10 15:06:34 UTC --- No response from reporter.
[Bug target/33123] internal compiler error: in decode_addr_const ( arm-linux-gcc 3.4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33123 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Richard Guenther 2012-01-10 15:07:36 UTC --- No response from reporter.
[Bug java/48515] [4.6] GCJ fails to compile jni.cc because of reflection errors on i686-w64-mingw32 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48515 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther 2012-01-10 15:08:40 UTC --- No (java is mostly unmaintained).
[Bug c++/51812] Virtual public inheritance leads to "undefined reference" in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #2 from bredelin at ucla dot edu 2012-01-10 15:09:09 UTC --- Also note that the bug report is based on a snapshot of 4.7 that was taken on Jan 7, 2012. $ g++-4.7 -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7-20120107-1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.0 20120107 (experimental) [trunk revision 182981] (Debian 4.7-20120107-1)
[Bug bootstrap/50103] gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50103 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Richard Guenther 2012-01-10 15:12:56 UTC --- Thus, not a GCC bug.
[Bug target/51330] Compiling issue that seems specific to i586 with gcc 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51330 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Richard Guenther 2012-01-10 15:13:34 UTC --- Thus, invalid.
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #15 from Mikael Morin 2012-01-10 15:15:47 UTC --- I'm having a look.
[Bug lto/47891] GCC 4.6/4.7 LTO not worked reliable on Windows target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Richard Guenther 2012-01-10 15:17:31 UTC --- binutils bug.
[Bug target/30826] alignment error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #11 from Richard Guenther 2012-01-10 15:23:35 UTC --- dup. *** This bug has been marked as a duplicate of bug 15087 ***
[Bug target/15087] IA64: Wrong alignment for structure > 8 byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15087 --- Comment #6 from Richard Guenther 2012-01-10 15:23:35 UTC --- *** Bug 30826 has been marked as a duplicate of this bug. ***
[Bug fortran/51809] [4.7 Regression][OOP] ICE (segfault) depending on USE statements order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug target/15087] IA64: Wrong alignment for structure > 8 byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15087 Richard Guenther changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #7 from Richard Guenther 2012-01-10 15:29:09 UTC --- (In reply to comment #3) > Subject: Re: New: IA64: Wrong alignment for structure > > 8 byte > > hjl at lucon dot org wrote: > > IA64 softwae runtime convention document, section 3.3.1 says that > > object greater that 8 bytes whould be aligned at 16 byte boundary. But > > gcc doesn't do it. > > This is a known problem, except it is much more complicated than what HJ > has stated. You really have to look at the documentation here to > properly understand what is going on. > > The Software Conventions and Runtime Architecure (SCRA), section 3.3.1 > Global Variables, says that dynamically allocated regions (e.g. malloc), > and external data items greater than 8 bytes must be aligned to 16-byte > boundaries. It also says that smaller objects must have alignment of > the nearest power of 2 equal to or larger than their size. So a global > structure object of 3 chars must have an alignment of 4. And the global > structure object in HJ's example must have an alignment of 16. > > The SCRA also says, in section 4.2 Aggregate Types, that an aggregate > type has the same alignment as the most strictly aligned field. There > is an example showing a 24-byte structure type which has 8-byte > alignment. A structure type of 3 bytes has alignment of 1, and the > structure type in HJ's example has alignment 8. > > So the tricky part here is that if an aggregate object is local, then > its alignment is only guaranteed to be as large as the alignment of its > most strictly aligned field. However, if an aggregate object is global > (extern), then its alignment is a power of 2 equal to or larger than its > size up to 16. This is an unusual convention I have never seen before, > and gcc currently has no support for it. I looked at this once a few > years ago and didn't see any easy way to implement it. I think we have > to add a new hook to implement it, and I never got around to that. > > Just assuming the larger alignment for an aggregate object is not safe. > If we have a local object in one module, take its address, and then > pass the address to another module, then we might segfault if we > dereference it assuming it has the larger alignment. So this means we > must assume objects have the smaller alignment when dereferencing > pointers to them, and we must assume they have the larger alignment when > creating them. > > We can do better if we had a reliable way to know if we were accessing a > local or global object. I am not sure if we have this info. Things are > probably easier now than when I first looked, what with cgraph, > functions-as-trees, and tree-ssa. In the simple case, if we are > directly accessing a decl, and the decl is global, then we should be > able to assume the larger alignment. This basically means that layout_type has to assume the object is local (thus, TYPE_ALIGN is the conservative low value - this value is also used when accessign the object via a pointer). layout_decl on the other hand does have the information whether the object is local or global and can properly specify DECL_ALIGN to be higher. > Gcc is currently self-consistent. The problem only arises when linking > gcc compiled code with icc compiled code, as icc implements the ABI as > specified. > > Fixing gcc means introducing a minor ABI change, which makes this more > complicated. Once we start increasing alignment for global objects, we > can't immediately assume such larger alignments when derefencing them, > as that fails if linked with code compiled by an older gcc version. If > we just continue assuming the smaller alignments on dereference for a > gcc version or two, then we can spread the ABI breakage over a few > years, and it will be less likely to affect anyone. So we fix the > alignments in version X, and then wait until version X+2 before using > the new alignments for optimization purposes. This means versions X-1 > and X+2 will be incompatible, but presumably few people would try > cross-linking code compiled by two gcc versions which are 4 versions apart. So, I am suspending this bug since the architecture in question lingers in a semi-dead state and thus any ABI breakage is probably unwanted.
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 --- Comment #7 from Jonathan Wakely 2012-01-10 15:29:09 UTC --- (In reply to comment #3) > > It says above them "In most cases, these > > builtins are considered a full barrier." and only __sync_lock_test_and_set > > and > > __sync_lock_release specify different barrier semantics. > > The next sentence is: > > "That is, no memory operand will be moved across the operation, either forward > or > backward." It continues: "Further, instructions will be issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation." Doesn't that rule out lwsync, which allows loads to be moved to before the store preceding the lwsync? Isn't the fact users will continue to use the __sync builtins all the more reason they should work as documented?
[Bug java/19325] Invoking gcj -C on a list of source files consumes insane amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19325 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-01-10 15:29:54 UTC --- More than 200MB is no longer insane and the issue might have been fixed. Closing.
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #27 from Richard Guenther 2012-01-10 15:31:09 UTC --- Should be fixed in at least 4.6.
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #10 from Richard Guenther 2012-01-10 15:32:40 UTC --- Hosting/building GCC on a platform without a 64bit integer type is not really supported.
[Bug tree-optimization/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #13 from Richard Guenther 2012-01-10 15:42:47 UTC --- We can't optimize this because System.out.println can change args[]. Thus the testcase is too simple to be useful (and no, we are not treating program arguments special - I doubt that would be useful, nor would it be easily possible).
[Bug rtl-optimization/23168] [OOM] GCC 4.0.1 OOM's while compiling VBA (works with 3.4.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23168 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 --- Comment #9 from Richard Guenther 2012-01-10 15:43:46 UTC --- Global alloc is gone since we have IRA.
[Bug libgcj/23216] IncompatibleClassChangeError when Using Java-Gnome
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23216 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther 2012-01-10 15:44:52 UTC --- No testcase, ancient Java (and now gnome) version.
[Bug fortran/51809] [4.7 Regression][OOP] ICE (segfault) depending on USE statements order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809 --- Comment #2 from Tobias Burnus 2012-01-10 15:49:52 UTC --- Some debugging. To make it easier, I split the test case into two files and I look at the one which only consists of "module merry_ICE". The ICE occurs for writing the .mod file of module merry_ICE. However, the actual issue already occurs with reading. If one sets a break point in mio_symbol, one sees that GCC reads the following symbols: $1 = 0x2cbf01e0 "__vtab_foo_Foo_t" $2 = 0x2cbf01c8 "__def_init_foo_Foo_t" $3 = 0x2cbf0258 "__vtab_bar_Bar_t" $4 = 0x2cbf0240 "__def_init_bar_Bar_t" The issue is for the PARAMETER "__vtab_bar_Bar_t": its initializer (sym->value) is a structure constructor consisting of _hash, _size, _extends etc. However, during read in the _extends gets only a c->expr->symtree == NULL. Thus, during write out, it crashes in mio_symtree_ref as that tries to access symtree->n.sym. If one reverts the order of the USE statements, one first reads the __vtab of "bar" - again with symtree == NULL - and only then one reads __vtab of "foo". Seemingly, only if the order is reversed the symtree fixing (fixup/pointer_info) works. The main change of the patch in comment 1 is that it changes FL_VARIABLE to FL_PARAMETER. If one looks at mio_symbol, one sees: if (sym->attr.flavor == FL_PARAMETER) mio_expr (&sym->value); One possibility is to revert the patch of comment 1 - and use the other variant to set TREE_READONLY: http://gcc.gnu.org/ml/fortran/2011-11/msg00099.html Alternatively - or additionally [as it can also affect other code] - one should find out why the symtree is not fixed up.
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #20 from Richard Guenther 2012-01-10 15:49:29 UTC --- Invalid.
[Bug target/25249] inconsistent code for template function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25249 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-01-10 15:50:20 UTC --- No answer, assuming fixed.
[Bug target/25372] Aligned args on IA64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25372 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #8 from Richard Guenther 2012-01-10 15:51:59 UTC --- Not a bug.
[Bug middle-end/25622] undefined reference to `_gfortran_st_set_nml_var_dim'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25622 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2012-01-10 15:53:19 UTC --- Assuming fixed.
[Bug bootstrap/25511] bootstrap-lean fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25511 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-01-10 15:52:38 UTC --- It does.
[Bug tree-optimization/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 Andrew Haley changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|INVALID | --- Comment #14 from Andrew Haley 2012-01-10 15:52:07 UTC --- (In reply to comment #13) > We can't optimize this because System.out.println can change args[]. That's the whole point: System.out.println cannot change args[], which is a java array, and the length of a Java array is constant. It is not an invalid test case.
[Bug gcov-profile/26313] arm-elf-gcc with gcov option do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26313 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-01-10 15:55:20 UTC --- No answer.
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #15 from Richard Guenther 2012-01-10 15:57:03 UTC --- Assuming fixed.
[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther 2012-01-10 15:58:01 UTC --- Fixed then.
[Bug other/27043] building Ada rts does not find 'as'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27043 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Kai Tietz 2012-01-10 16:00:33 UTC --- Hmm, I assume this issue is already fixed for newer versions. I know that for more recent version native Ada builds were done successful in msys. Therefore closing it
[Bug c/28233] internal compiler error: in make_decl_rtl, at varasm.c:752
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28233 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Richard Guenther 2012-01-10 16:02:23 UTC --- Confirmed.
[Bug debug/28547] Large compile time regression with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Richard Guenther 2012-01-10 16:15:18 UTC --- No response.
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 Richard Guenther changed: What|Removed |Added Status|WAITING |NEW Component|tree-optimization |java --- Comment #15 from Richard Guenther 2012-01-10 16:20:13 UTC --- (In reply to comment #14) > (In reply to comment #13) > > We can't optimize this because System.out.println can change args[]. > > That's the whole point: System.out.println cannot change args[], which is a > java array, and the length of a Java array is constant. It is not an invalid > test case. I suppose public static void main(String[] args) is passing args by value (but the implementation detail uses reference passing for efficiency?). In this case the Java frontend should do like the C++ frontend and tell this to the middle-end by properly marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified pointer for the reference. Then we would optimize this case. Java frontend issue.
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #16 from Andrew Haley 2012-01-10 16:26:51 UTC --- (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > We can't optimize this because System.out.println can change args[]. > > > > That's the whole point: System.out.println cannot change args[], which is a > > java array, and the length of a Java array is constant. It is not an > > invalid > > test case. > > I suppose > > public static void main(String[] args) > > is passing args by value (but the implementation detail uses reference > passing for efficiency?). args is indeed a reference to a Java array. The length field of a Java array is immutable. The elements of an array are not immutable. > In this case the Java frontend should do > like the C++ frontend and tell this to the middle-end by properly > marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified > pointer for the reference. Then we would optimize this case. If we could mark the length field as immutable that would fix it. Is there any way to do that?
[Bug lto/51806] -flto ignores -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51806 --- Comment #2 from Richard Guenther 2012-01-10 16:28:07 UTC --- Author: rguenth Date: Tue Jan 10 16:27:55 2012 New Revision: 183069 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183069 Log: 2012-01-10 Richard Guenther PR middle-end/51806 c-family/ * c-opts.c (c_common_handle_option): Move -Werror handling to language independent code. * opts.c (common_handle_option): Handle -Werror. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/opts.c
[Bug lto/51806] -flto ignores -Werror
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51806 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther 2012-01-10 16:31:09 UTC --- Fixed for 4.7.
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #17 from Richard Guenther 2012-01-10 16:30:30 UTC --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > (In reply to comment #13) > > > > We can't optimize this because System.out.println can change args[]. > > > > > > That's the whole point: System.out.println cannot change args[], which is > > > a > > > java array, and the length of a Java array is constant. It is not an > > > invalid > > > test case. > > > > I suppose > > > > public static void main(String[] args) > > > > is passing args by value (but the implementation detail uses reference > > passing for efficiency?). > > args is indeed a reference to a Java array. The length field of a Java > array is immutable. The elements of an array are not immutable. You mean that System.out.println could change the elements of the array (well, it doesn't, but theoretically it could)? > > In this case the Java frontend should do > > like the C++ frontend and tell this to the middle-end by properly > > marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified > > pointer for the reference. Then we would optimize this case. > > If we could mark the length field as immutable that would fix it. Is there > any > way to do that? No. What you can do is, via the method I outlined, tell GCC that args is to be treated similar to a local automatic variable - thus it cannot be refered to from other functions (unless you pass them its address of course).
[Bug c++/51810] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51810
--- Comment #5 from Markus Trippelsdorf
2012-01-10 16:32:23 UTC ---
Created attachment 26295
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26295
another reduced testcase
The testcase from Comment 4 doesn't work on my machine.
Here is another one.
% g++ -std=c++0x test.ii
test.ii: In instantiation of ‘boost::unordered::detail::table_impl<
>::emplace_return
boost::unordered::detail::table_impl<
>::emplace(Args&& ...) [with Args = {std::pair}; Types =
boost::unordered::detail::map >, rtl::OUString, std::equal_to,
std::equal_to >; boost::unordered::detail::table_impl<
>::emplace_return =
std::pair*, std::pair >, bool>; typename
boost::unordered::detail::table::iterator =
boost::unordered::iterator_detail::iterator*, std::pair >]’:
test.ii:416:9: required from ‘std::pair >::type, K, H, P>::table::iterator, bool>
boost::unordered::unordered_map,
, >::emplace(Args&& ...) [with
Args = {std::pair}; K =
rtl::OUString; T = {anonymous}::CommandInfo; H = std::equal_to;
P = std::equal_to; A = std::allocator >; typename
boost::unordered::detail::map >::type, K, H, P>::table::iterator =
boost::unordered::iterator_detail::iterator*, std::pair >]’
test.ii:420:9: required from ‘std::pair >::type, K, H, P>::table::iterator, bool>
boost::unordered::unordered_map,
,
>::insert(boost::unordered::unordered_map,
, >::value_type&&) [with K =
rtl::OUString; T = {anonymous}::CommandInfo; H = std::equal_to;
P = std::equal_to; A = std::allocator >; typename
boost::unordered::detail::map >::type, K, H, P>::table::iterator =
boost::unordered::iterator_detail::iterator*, std::pair >; boost::unordered::unordered_map, ,
>::value_type = std::pair]’
test.ii:536:69: required from here
test.ii:432:10: internal compiler error: Segmentation fault
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
--- Comment #18 from Richard Guenther 2012-01-10
16:35:46 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > (In reply to comment #13)
> > > > > We can't optimize this because System.out.println can change args[].
> > > >
> > > > That's the whole point: System.out.println cannot change args[], which
> > > > is a
> > > > java array, and the length of a Java array is constant. It is not an
> > > > invalid
> > > > test case.
> > >
> > > I suppose
> > >
> > > public static void main(String[] args)
> > >
> > > is passing args by value (but the implementation detail uses reference
> > > passing for efficiency?).
> >
> > args is indeed a reference to a Java array. The length field of a Java
> > array is immutable. The elements of an array are not immutable.
>
> You mean that System.out.println could change the elements of the array
> (well, it doesn't, but theoretically it could)?
>
> > > In this case the Java frontend should do
> > > like the C++ frontend and tell this to the middle-end by properly
> > > marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified
> > > pointer for the reference. Then we would optimize this case.
> >
> > If we could mark the length field as immutable that would fix it. Is there
> > any
> > way to do that?
>
> No. What you can do is, via the method I outlined, tell GCC that
> args is to be treated similar to a local automatic variable - thus
> it cannot be refered to from other functions (unless you pass them
> its address of course).
Thus, similar to the C++ case with
struct Array { int length; void data[]; }
void foo (Array args)
{
...
}
foo cannot change the callers args.length (only its own copy) but it
can change the callers args.data[] contents. If the C++ frontend
decides to pass args by reference then it sets DECL_BY_REFERENCE
and uses a TYPE_RESTRICT qualified pointer. This way the optimization
will be the same as if it was passed "really" by value.
Not sure if the Java situation is similar enough.
[Bug libfortran/51803] gfortran getcwd at startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803 --- Comment #3 from mrs at gcc dot gnu.org 2012-01-10 16:39:33 UTC --- Mike Stump
[Bug libfortran/51803] gfortran getcwd at startup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803 --- Comment #4 from mrs at gcc dot gnu.org 2012-01-10 16:44:24 UTC --- Oh, a related, but different bug would be, if getcwd isn't on the system, or fails, I think "." might be better than "", as we form getcwd '/' argv[0], and that doesn't make any sense as "" really. ./a.out seems better than /a.out for example. I merely copied the bug from the other code path for uniformity, not because I thought it was the right value.
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #19 from Andrew Haley 2012-01-10 16:44:16 UTC --- (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > (In reply to comment #13) > > > > > We can't optimize this because System.out.println can change args[]. > > > > > > > > That's the whole point: System.out.println cannot change args[], which > > > > is a > > > > java array, and the length of a Java array is constant. It is not an > > > > invalid > > > > test case. > > > > > > I suppose > > > > > > public static void main(String[] args) > > > > > > is passing args by value (but the implementation detail uses reference > > > passing for efficiency?). > > > > args is indeed a reference to a Java array. The length field of a Java > > array is immutable. The elements of an array are not immutable. > > You mean that System.out.println could change the elements of the array > (well, it doesn't, but theoretically it could)? In theory yes, it could. > > > In this case the Java frontend should do > > > like the C++ frontend and tell this to the middle-end by properly > > > marking args as 1) DECL_BY_REFERENCE, 2) use a TYPE_RESTRICT qualified > > > pointer for the reference. Then we would optimize this case. > > > > If we could mark the length field as immutable that would fix it. Is there > > any > > way to do that? > > No. What you can do is, via the method I outlined, tell GCC that > args is to be treated similar to a local automatic variable - thus > it cannot be refered to from other functions (unless you pass them > its address of course). But that doesn't help. args *can* potentially be referred to by other functions. The special property we need to make use of its that fact that once an array is created, its length can never change.
[Bug middle-end/51516] [trans-mem] problem with TM clone aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51516 --- Comment #1 from Aldy Hernandez 2012-01-10 16:50:56 UTC --- Author: aldyh Date: Tue Jan 10 16:50:41 2012 New Revision: 183070 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183070 Log: PR middle-end/51516 * trans-mem.c (get_cg_data): Traverse aliases if requested. (ipa_tm_scan_calls_block): Update parameters to get_cg_data. (ipa_tm_note_irrevocable): Same. (ipa_tm_scan_irr_block): Same. (ipa_tm_decrement_clone_counts): Same. (ipa_tm_scan_irr_function): Same. (ipa_tm_create_version_alias): Same. (ipa_tm_create_version): Same. (ipa_tm_transform_calls_redirect): Same. (ipa_tm_transform_calls): Same. (ipa_tm_transform_transaction): Same. (ipa_tm_execute): Same. Added: trunk/gcc/testsuite/g++.dg/tm/pr51516.C Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/51516] [trans-mem] problem with TM clone aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51516 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez 2012-01-10 16:52:52 UTC --- fixed
[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782 --- Comment #14 from Joseph S. Myers 2012-01-10 16:55:44 UTC --- Author: jsm28 Date: Tue Jan 10 16:55:40 2012 New Revision: 183071 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183071 Log: Revert: 2008-09-18 Andrew Pinski PR rtl-opt/37451 * loop-doloop.c (doloop_modify): New argument zero_extend_p and zero extend count after the correction to it is done. (doloop_optimize): Update call to doloop_modify, don't zero extend count before call. 2008-11-03 Andrew Pinski PR rtl-opt/37782 * loop-doloop.c (doloop_modify): Add from_mode argument that says what mode count is in. (doloop_optimize): Update call to doloop_modify. testsuite: * gcc.c-torture/execute/doloop-1.c, gcc.c-torture/execute/doloop-2.c: New tests. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/doloop-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/doloop-2.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/loop-doloop.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/37451] Extra addition for doloop in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451 --- Comment #8 from Joseph S. Myers 2012-01-10 16:55:44 UTC --- Author: jsm28 Date: Tue Jan 10 16:55:40 2012 New Revision: 183071 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183071 Log: Revert: 2008-09-18 Andrew Pinski PR rtl-opt/37451 * loop-doloop.c (doloop_modify): New argument zero_extend_p and zero extend count after the correction to it is done. (doloop_optimize): Update call to doloop_modify, don't zero extend count before call. 2008-11-03 Andrew Pinski PR rtl-opt/37782 * loop-doloop.c (doloop_modify): Add from_mode argument that says what mode count is in. (doloop_optimize): Update call to doloop_modify. testsuite: * gcc.c-torture/execute/doloop-1.c, gcc.c-torture/execute/doloop-2.c: New tests. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/doloop-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/doloop-2.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/loop-doloop.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #21 from Richard Guenther 2012-01-10 16:57:36 UTC --- The Java frontend could handle this by performing loads of the length field via a SAVE_EXPR and sharing this across a function. That way CSE would happen automagically.
[Bug java/47456] internal compiler error: Segmentation fault while using jna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456 Kai Tietz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #15 from Kai Tietz 2012-01-10 16:57:02 UTC --- Hmm, neither an new report about this, nor confirmation that issue still happens. We waited long enough. Closing it.
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #20 from Richard Guenther 2012-01-10 16:55:52 UTC --- (In reply to comment #19) > > > No. What you can do is, via the method I outlined, tell GCC that > > args is to be treated similar to a local automatic variable - thus > > it cannot be refered to from other functions (unless you pass them > > its address of course). > > But that doesn't help. args *can* potentially be referred to by other > functions. The special property we need to make use of its that fact that > once > an array is created, its length can never change. That is something we cannot express at the moment, and I think it would be hard to implement reliably (thinking of the RTX_UNCHANGING saga - we do have to exclude the stmts that initialize the length field).
[Bug java/21855] array bounds checking elimination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855 --- Comment #22 from Andrew Haley 2012-01-10 17:08:30 UTC --- (In reply to comment #21) > The Java frontend could handle this by performing loads of the length field > via a SAVE_EXPR and sharing this across a function. That way CSE would > happen automagically. Now that's a nice idea. In this specific case it should be easy, because array.length is used in the control expression for the loop. So. we can create the SAVE_EXPR when the loop is initialized. The problem with doing this in general is that we don't have a CFG, so we don't always know when to create that SAVE_EXPR. If we can find an initial use of an array that dominates all other uses we can create the SAVE_EXPR at that point.
