[Bug target/43052] [4.7/4.8/4.9 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug middle-end/39838] [4.7/4.8/4.9 regression] unoptimal code for two simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/44281] [4.7/4.8/4.9 Regression] Global Register variable pessimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/55342] [4.8/4.9 Regression] [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/57676] [4.8/4.9 Regression] ICE: Maximum number of LRA constraint passes is achieved (30)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/60770] disappearing clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #1 from Marc Glisse ---
int f(int n){
int*p;
{
int q=n;
p=&q;
}
return *p;
}
Here CCP turns:
q = n_2(D);
p_4 = &q;
q ={v} {CLOBBER};
_6 = *p_4;
into:
q_5 = n_2(D);
_6 = q_5;
I guess relying on clobbers in the middle-end for warnings is a bit
optimistic...
[Bug tree-optimization/60766] [4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 netheril96 at gmail dot com changed: What|Removed |Added CC||netheril96 at gmail dot com --- Comment #3 from netheril96 at gmail dot com --- The bug is easily reproducible. It has the same behavior with gcc 4.7.3 on my Ubuntu. I hope this bug can be fixed soon, since the source code is so simple, and hence the bug may affect a lot of innocent programs.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 Marc Glisse changed: What|Removed |Added Attachment #32549|0 |1 is obsolete|| --- Comment #11 from Marc Glisse --- Created attachment 32551 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32551&action=edit first try With clobber removal now. It isn't so great, the statements before the clobber have already been removed as dead code, so by removing the clobber we produce an uninitialized read for which we get a warning later.
[Bug tree-optimization/60770] disappearing clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #1) > I guess relying on clobbers in the middle-end for warnings is a bit > optimistic... If I interpret the dump correctly, this is a valid optimization because the original code is undefined, but it is hiding the fact that the original code is buggy. CCP does this kind of thing for uninitialized warnings (PR18501), and it would be nice to find a way to warn for it.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #12 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #11) > Created attachment 32551 [details] > first try > > With clobber removal now. Why do you want to remove the clobber? I understood your idea to avoid duplicated warnings was to add __builtin_unreachable and replace the value. Could be possible to have a special var/value that is marked as artificial such that the warning code never warns for statements containing this variable? We already have DECL_ARTIFICIAL in the FE but I am not sure whether that survives to the middle-end.
[Bug fortran/56674] [4.7/4.8/4.9 Regression] ICE in check_sym_interfaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56674 --- Comment #7 from Dominique d'Humieres --- Slightly reduced test MODULE realspace_grid_types PUBLIC :: realspace_grid_input_type CONTAINS SUBROUTINE rs_grid_create_descriptor ( ) TYPE(realspace_grid_input_type), END SUBROUTINE END MODULE realspace_grid_types pr56674_red.f90:5.35: TYPE(realspace_grid_input_type), 1 Error: Derived type 'realspace_grid_input_type' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault: 11
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #12 from lailavrazda1979 at gmail dot com --- Bug still a problem with latest trunk.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #13 from Marc Glisse --- (In reply to Manuel López-Ibáñez from comment #12) > Why do you want to remove the clobber? I am in the DSE pass, so removing the clobber as a dead store is the easiest thing to do ;-) Ok, it might not be such a good idea. > I understood your idea to avoid duplicated warnings was to add > __builtin_unreachable and replace the value. adding __builtin_unreachable seems doable. I am not sure what to replace the value with though, as the variable could have any type. Note that I also posted: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html (hmm, OPT_Wreturn_local_addr is a C/C++ FE flag, I should move it or pick a different one) where I do replace the pointer by zero as you suggested. I am not adding __builtin_unreachable, because if nothing uses the return value, I am not sure it would be right to break the code. > Could be possible to have a special var/value that is marked as artificial > such that the warning code never warns for statements containing this > variable? We already have DECL_ARTIFICIAL in the FE but I am not sure > whether that survives to the middle-end. There is probably some unused bit somewhere...
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #24 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sun Apr 6 10:38:16 2014 New Revision: 209161 URL: http://gcc.gnu.org/viewcvs?rev=209161&root=gcc&view=rev Log: 2014-04-06 Dominique d'Humieres Iain Sandoe PR target/54083 * gcc.dg/attr-weakref-1.c: Allow the test on darwin with the additional options -Wl,-undefined,dynamic_lookup and -Wl,-flat_namespace * gcc.dg/torture/pr53922.c: Additional option -Wl,-flat_namespace for darwin[89]. Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/attr-weakref-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #25 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sun Apr 6 11:43:38 2014 New Revision: 209162 URL: http://gcc.gnu.org/viewcvs?rev=209162&root=gcc&view=rev Log: 2014-04-06 Dominique d'Humieres Iain Sandoe PR target/54083 * gcc.dg/attr-weakref-1.c: Allow the test on darwin with the additional options -Wl,-undefined,dynamic_lookup and -Wl,-flat_namespace * gcc.dg/torture/pr53922.c: Additional option -Wl,-flat_namespace for darwin[89]. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/attr-weakref-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Dominique d'Humieres --- Closing as FIXED.
[Bug tree-optimization/60766] [4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #4 from Mikael Pettersson --- Created attachment 32552 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32552&action=edit self-contained test case, compilable as C and C++ The wrong-code reproduces for me with gcc 4.7 and 4.8 on x86_64-linux. For trunk it was fixed by r204515, which doesn't appear to be a wrong-code fix. Backporting r204515 to 4.8 fixes the wrong-code there too, but I haven't tested it beyond this test case.
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 --- Comment #9 from John David Anglin --- Author: danglin Date: Sun Apr 6 15:17:41 2014 New Revision: 209163 URL: http://gcc.gnu.org/viewcvs?rev=209163&root=gcc&view=rev Log: PR debug/55794 * config/pa/pa.c (pa_output_function_epilogue): Skip address and code size accounting for thunks. (pa_asm_output_mi_thunk): Use final_start_function() and final_end_function() to output function start and end directives. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from John David Anglin --- Fixed on trunk.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #9 from Walter Spector --- Harald and Steve: I am quite aware of the std= options, thanks. My main point is that the default situation violates the Principle of Least Astonishment. I don't have a problem with gfortran offering such an extension (though I think providing it in the first place was a waste of time). But since it offers no desireable new capability, and allows gratuitous incompatibility with other compilers, it would at least be worth a warning. The ideal would be to only allow it under a -f option - but don't do that on my account. In fact the gfortran man page for the -std= argument states: "...The default value for std is gnu, which specifies a superset of the Fortran 95 standard that includes all of the extensions supported by GNU Fortran, although warnings will be given for obsolete extensions not recommended for use in new code..." I would opine that this extension is obsolete and not recommeded for use in new code. Therefore a warning should be given.
[Bug testsuite/60672] FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672 --- Comment #3 from John David Anglin --- Author: danglin Date: Sun Apr 6 16:31:38 2014 New Revision: 209165 URL: http://gcc.gnu.org/viewcvs?rev=209165&root=gcc&view=rev Log: PR testsuite/60672 * g++.dg/cpp1y/auto-fn25.C: Require lto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn25.C
[Bug testsuite/60672] FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from John David Anglin --- Fixed.
[Bug target/60772] New: [4.9 regression] FAIL: gcc.target/powerpc/direct-move-float1.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60772 Bug ID: 60772 Summary: [4.9 regression] FAIL: gcc.target/powerpc/direct-move-float1.c (internal compiler error) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc64-*-* configure flags: --prefix=/usr --build=powerpc64-linux --enable-checking=release --enable-shared --with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' --with-cpu-64=power4 --enable-secureplt --with-long-double-128 $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/direct-move-float1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O2 -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -ffat-lto-objects -S -m64 -o direct-move-float1.s In file included from ../gcc/testsuite/gcc.target/powerpc/direct-move-float1.c:18:0: ../gcc/testsuite/gcc.target/powerpc/direct-move.h: In function ‘load_gpr_to_vsx’: ../gcc/testsuite/gcc.target/powerpc/direct-move.h:66:1: error: unrecognizable insn: (insn 22 21 23 2 (set (subreg:DI (reg:SF 32 0 [orig:129 d ] [129]) 0) (reg:DI 10 10)) ../gcc/testsuite/gcc.target/powerpc/direct-move.h:64 -1 (nil)) ../gcc/testsuite/gcc.target/powerpc/direct-move.h:66:1: internal compiler error: in extract_insn, at recog.c:2202 0x104ffbdb _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:109 0x104ffc47 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.c:117 0x104ca3ef extract_insn(rtx_def*) ../../gcc/recog.c:2202 0x104ca4b7 extract_insn_cached(rtx_def*) ../../gcc/recog.c:2105 0x102fc97b cleanup_subreg_operands(rtx_def*) ../../gcc/final.c:3063 0x104c6a57 split_insn ../../gcc/recog.c:2920 0x104cd72b split_all_insns() ../../gcc/recog.c:2974 0x104cd863 rest_of_handle_split_after_reload ../../gcc/recog.c:3923 0x104cd863 execute ../../gcc/recog.c:3952
[Bug target/60772] [4.9 regression] FAIL: gcc.target/powerpc/direct-move-float1.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60772 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|ICE in extract_insn |[4.9 Regression] ICE in |starting with rev 208984|extract_insn starting with ||rev 208984
[Bug target/60772] [4.9 regression] FAIL: gcc.target/powerpc/direct-move-float1.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60772 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 60763. *** This bug has been marked as a duplicate of bug 60763 ***
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Andrew Pinski changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #2 from Andrew Pinski --- *** Bug 60772 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-06 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed due to the dup bug.
[Bug testsuite/60671] FAIL: g++.dg/pr49718.C -std=gnu++98 scan-assembler-times __cyg_profile_func_enter 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60671 --- Comment #1 from John David Anglin --- Author: danglin Date: Sun Apr 6 16:44:21 2014 New Revision: 209166 URL: http://gcc.gnu.org/viewcvs?rev=209166&root=gcc&view=rev Log: PR testsuite/60671 g++.dg/pr49718.C: Adjust scan-assembler-times for hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pr49718.C
[Bug testsuite/60671] FAIL: g++.dg/pr49718.C -std=gnu++98 scan-assembler-times __cyg_profile_func_enter 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60671 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Fixed.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #10 from Steve Kargl --- On Sun, Apr 06, 2014 at 03:45:08PM +, w6ws at earthlink dot net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 > > --- Comment #9 from Walter Spector --- > Harald and Steve: I am quite aware of the std= options, thanks. > > My main point is that the default situation violates the Principle of Least > Astonishment. And my point is that the feature/bug is there solely for backwards compatibility with g77. A POLA issue back when gfortran first replaced g77 in GCC. Just last week in c.l.f there was a long thread from someone who could not use gfortran to build his legacy code, because gfortran does not support a number of g77's old -fugly-* options. In hindsight, I now regret contributing a number of patches to implement g77 compatibility and common vendor extensions. In fact, I think the default should be -std=f95+f2003+f2008. If the feature isn't in one of the standards, an error should be issued without an explicit option to permit the feature. Unfortrunately, the horse left the barn years ago.
[Bug c++/60768] Excessive C++ compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60768 --- Comment #3 from David Binderman --- >I'll try --enable-checking=release and see if the times are reasonable. For trunk 20140406 I got real0m47.473s user0m46.415s sys0m0.526s which seems pretty reasonable to me. Output from -ftime-report shows phase opt and generate : 45.37 (99%) usr 0.48 (54%) sys 46.34 (98%) wall 136380 kB (60%) ggc df reaching defs: 5.77 (13%) usr 0.02 ( 2%) sys 5.85 (12%) wall 0 kB ( 0%) ggc df live regs: 4.41 (10%) usr 0.00 ( 0%) sys 4.47 ( 9%) wall 0 kB ( 0%) ggc df live&initialized regs: 5.76 (13%) usr 0.02 ( 2%) sys 5.79 (12%) wall 0 kB ( 0%) ggc I am not sure if further tuning of these routines is required or not.
[Bug target/60773] New: FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Bug ID: 60773 Summary: FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target: powerpc64-*-* configure flags: --prefix=/usr --build=powerpc64-linux --enable-checking=release --enable-shared --with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' --with-cpu-64=power4 --enable-secureplt --with-long-double-128 $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/vect/pr60656.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -m64 -o ./pr60656.exe $ grep vectorized pr60656.c.114t.vect ../gcc/testsuite/gcc.dg/vect/pr60656.c:12:3: note: === vect_mark_stmts_to_be_vectorized === ../gcc/testsuite/gcc.dg/vect/pr60656.c:12:3: note: not vectorized: relevant stmt not supported: P_6 = (long int) _5; ../gcc/testsuite/gcc.dg/vect/pr60656.c:6:1: note: vectorized 0 loops in function. ../gcc/testsuite/gcc.dg/vect/pr60656.c:27:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed ../gcc/testsuite/gcc.dg/vect/pr60656.c:21:1: note: vectorized 0 loops in function. ../gcc/testsuite/gcc.dg/vect/pr60656.c:27:3: note: not vectorized: loop contains function calls or data references that cannot be analyzed ../gcc/testsuite/gcc.dg/vect/pr60656.c:36:5: note: vectorized 0 loops in function.
[Bug target/60773] FAIL: gcc.dg/vect/pr60656.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60773 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/60763] [4.9 Regression] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #4 from rsandifo at gcc dot gnu.org --- Created attachment 32553 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32553&action=edit Patch for 60772 testcase OK, I could reproduce it with Andreas's instructions after configuring with a real powerpc64-linux-gnu assembler. I think the lack of an assembler was causing some important configure test to fail. One fix for the PR60772 case is attached. It takes the same approach as rs6000_split_multireg_move and IMO is preferable to allowing the subreg in the movdi pattern. The output is the same as before the general_operand change.
[Bug fortran/55789] [4.7 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #16 from Dominique d'Humieres --- > No, it does not work on 4.7. Paul, Do you remember what was not working. I have applied the patches of r195492 and r195815 to 4.7.4 r209162 without regression (see http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg00483.html). If deemed suitable I can do the back port (I think it is now or never: 4.7.4 will likely be the last 4.7 release).
[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #10 from Bernd Edlinger --- Created attachment 32554 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32554&action=edit possible fix Hi, this is probably what Tobias proposed in Comment#8. What do you think of this patch?
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #11 from Jerry DeLisle --- We could just change this to a -std=legacy or a warning that would not appear with -w.
[Bug fortran/60774] New: f951: internal compiler error: Segmentation fault: 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774 Bug ID: 60774 Summary: f951: internal compiler error: Segmentation fault: 11 Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kevinecahill at gmail dot com Created attachment 32555 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32555&action=edit A fortran program I wrote. gfortran -Wall -O3 -o $1 $2 energy.f95:180.3: 123 1 Warning: Ignoring statement label in empty statement at (1) f951: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate.
[Bug lto/50679] [meta-bug] Linux kernel LTO tracking bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679 Andi Kleen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andi Kleen --- No open bugs for kernel LTO in 4.8+
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #3 from Alexey Merzlyakov --- Thank you very much! Reg. test - no changes. http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00195.html
[Bug target/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #22 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Apr 7 06:40:18 2014 New Revision: 209175 URL: http://gcc.gnu.org/viewcvs?rev=209175&root=gcc&view=rev Log: 2014-04-03 Dominique d'Humieres Backport from mainline 2013-09-14 Iain Sandoe gcc: PR target/48094 * config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen. (darwin_objc1_section): Likewise. (darwin_file_end): Emit Image Info section when required. gcc/c-family: PR target/48094 * c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version, fobjc-gc, freplace-objc-classes): Accept for LTO. gcc/objc: PR target/48094 * objc-next-runtime-abi-01.c (generate_objc_image_info): Remove. (objc_generate_v1_next_metadata): Remove generation of ImageInfo. * objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove. (objc_generate_v2_next_metadata): Remove generation of ImageInfo. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c.opt branches/gcc-4_8-branch/gcc/config/darwin.c branches/gcc-4_8-branch/gcc/objc/ChangeLog branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-01.c branches/gcc-4_8-branch/gcc/objc/objc-next-runtime-abi-02.c
