[Bug target/67946] Function multiversioning ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946 --- Comment #1 from Uroš Bizjak --- You should compile this with -mavx, otherwise x, y and z global variables get expanded in BLKmode. So, we get: (gdb) p code $1 = PLUS_EXPR (gdb) p op0 $2 = (rtx) 0x2aaab05a4918 (gdb) p debug_rtx (op0) (mem/c:BLK (symbol_ref:DI ("z") [flags 0x2] ) [1 z+0 S32 A256]) $3 = void (gdb) p debug_rtx (op1) (mem/c:BLK (symbol_ref:DI ("y") [flags 0x2] ) [1 y+0 S32 A256])
[Bug fortran/67938] ICE on using assumed rank character with some intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67938 --- Comment #2 from Gerhard Steinmetz --- As meanwhile noticed, example z1.f90 from comment #1 overlaps with PR66833. Examples z2.f90 (comment #0) and z1s.f90 are describing additional effects.
[Bug target/67946] Function multiversioning ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946 --- Comment #2 from Stupachenko Evgeny --- I see, but shouldn't compiler generate en error on this instead of ICE?
[Bug tree-optimization/67945] Testsuite failures starting with revision 228616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945 Alexander Fomin changed: What|Removed |Added CC||afomin.mailbox at gmail dot com --- Comment #2 from Alexander Fomin --- At least x86-64 also regressed ont SPEC2006 410.bwaves because of the same folding problem.
[Bug fortran/67938] ICE on using assumed rank character with some intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67938 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #3 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). The code compiles and executes if 'character' is replaced with 'integer' or 'real'. Also related to pr67894.
[Bug debug/63135] [4.9 regression] Infinite loop in var-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63135 Maxim Kuvyrkov changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mkuvyrkov at gcc dot gnu.org --- Comment #5 from Maxim Kuvyrkov --- This is likely a DUP of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 . Assigning to myself.
[Bug lto/67923] [6 Regression] ICEs in the gfortran test suite with -flto after r228680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominique d'Humieres --- The ICEs appeared after an incremental update, but disappeared after a clean bootstrap (missing dependencies?). Sorry for the noise, closing as INVALID.
[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 Alexandros Syrakos changed: What|Removed |Added CC||alexandros.syrakos@outlook. ||com --- Comment #2 from Alexandros Syrakos --- The bug is still present in gfortran 5.2.0. It makes it impossible to modify a substring of a unicode string; it has to be treated as a whole.
[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 --- Comment #3 from Dominique d'Humieres --- > Confirmed and the problem is in the front end side. Yes, if I remove 'parameter' in the definition of 'string', I get the correct KIND for the section. > The bug is still present in gfortran 5.2.0. It makes it impossible > to modify a substring of a unicode string; it has to be treated as a whole. Still on trunk (6.0)!-(usual answer: "what did you do to fix the PR?").
[Bug fortran/67939] ICE on using data with negative substring range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67939 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #2 from Dominique d'Humieres --- On x86_64-apple-darwin14, the tests mostly hang after the warning from 4.8 up to trunk (6.0).
[Bug other/62279] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 Stanislav Angelovic changed: What|Removed |Added CC||stanislav.angelovic@kistler ||.com --- Comment #3 from Stanislav Angelovic --- GDB 7.7.1 demangler crashes upon this symbol in our binary: _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTaskC4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt16remove_referenceISC_E4typeE We have tried the patch at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html , but to no avail.
[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 --- Comment #17 from Ramana Radhakrishnan --- (In reply to Fredrik Hederstierna from comment #16) > Could this fix also possibly improve: > Bug 67507 - "Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM > thumb1", which also seems related to alignment on ARM targets? > Thanks, Fredrik No I don't think so ...
[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67947 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|wrong code at -O3 on|[6 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
[Bug middle-end/67946] Function multiversioning ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Component|target |middle-end Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I don't think compiling with -mavx is desired here. The "bug" is that DECL_MODE doesn't have the same special-casing of vectors as TYPE_MODE has and ... /* Holds the machine mode corresponding to the declaration of a variable or field. Always equal to TYPE_MODE (TREE_TYPE (decl)) except for a FIELD_DECL. */ #define DECL_MODE(NODE) (DECL_COMMON_CHECK (NODE)->decl_common.mode) ... the comment also is wrong here. Not sure if we really want to change the above to sth like #define DECL_MODE(NODE) \ (VECTOR_TYPE_P (TREE_TYPE (NODE)) \ ? vector_type_mode (TREE_TYPE (NODE)) \ : DECL_COMMON_CHECK (NODE)->decl_common.mode) though. Maybe changing references to DECL_MODE to use TYPE_MODE in some selected places would be enough ...
[Bug other/62279] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #4 from Mikhail Maltsev --- (In reply to Stanislav Angelovic from comment #3) > GDB 7.7.1 demangler crashes upon this symbol in our binary: > > _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTask > C4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt1 > 6remove_referenceISC_E4typeE Whis works fine with binutils 2.25 and gives: std::allocator(int, bool, void (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&& std::forward(int, bool, std::allocator(int, bool, void (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&, WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const>(std::remove_reference(int, bool, void (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const>::type&) Could you try a newer version of GDB?
[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|Testsuite failures starting |[6 Regression] Testsuite |with revision 228616|failures starting with ||revision 228616 --- Comment #3 from Richard Biener --- Was this maybe fixed by 2015-10-13 Richard Sandiford * real.h (real_isinteger): Declare. * real.c (real_isinteger): New function. * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y) if y is an even integer. ?
[Bug c++/67935] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67935 Yi Qingliang changed: What|Removed |Added Attachment #36484|0 |1 is obsolete|| CC||niqingliang2003 at gmail dot com --- Comment #2 from Yi Qingliang --- Created attachment 36492 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36492&action=edit the array version the array version compile result: $ gcc -v -save-temps -std=c++11 main.cpp Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o main.ii ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed main.ii -quiet -dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -std=c++11 -version -o main.s GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9ed1d81099b98de89457560501a9ea0c main.cpp: In substitution of ‘template void base_t::serialize(_T&) [with _T = packer_rp]’: main.cpp:16:3: required from ‘void packer_rp::pack_data(const _T&) [with _T = base_t]’ main.cpp:6:3: required from ‘void packer_rp::operator()(const _T&) [with _T = base_t]’ main.cpp:45:3: required from ‘void test::serialize(_T&) const [with _T = packer_rp]’ main.cpp:53:30: required from here main.cpp:34:22: error: invalid use of ‘restrict’ void serialize(_T & o)
[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 --- Comment #3 from Richard Biener --- Most interesting would be a C testcase that produces the CFG with the bogus counters ;)
[Bug c++/67935] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67935 --- Comment #3 from Yi Qingliang --- Created attachment 36493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36493&action=edit the array version 'save-temps' result the array version 'save-temps' result
[Bug fortran/67933] [4.9/5/6 Regression] ICE for array of a derived type with allocatable class in derived type object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67933 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4 Summary|[4.9/5/Trunk Regression]|[4.9/5/6 Regression] ICE |ICE for array of a derived |for array of a derived type |type with allocatable class |with allocatable class in |in derived type object |derived type object
[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945 --- Comment #4 from Thomas Preud'homme --- (In reply to Richard Biener from comment #3) > Was this maybe fixed by > > 2015-10-13 Richard Sandiford > > * real.h (real_isinteger): Declare. > * real.c (real_isinteger): New function. > * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y) > if y is an even integer. > > ? It does for builtins-10.c on arm-none-eabi at least. Thanks Richard S for the quick fix.
[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67915 --- Comment #2 from Richard Biener --- So sth like the following (ISTR some missed foldings that way, it's not too long ago that I tested this) Index: gcc/tree-cfgcleanup.c === --- gcc/tree-cfgcleanup.c (revision 228706) +++ gcc/tree-cfgcleanup.c (working copy) @@ -110,10 +110,9 @@ cleanup_control_expr_graph (basic_block switch (gimple_code (stmt)) { case GIMPLE_COND: - val = fold_binary_loc (loc, gimple_cond_code (stmt), -boolean_type_node, -gimple_cond_lhs (stmt), -gimple_cond_rhs (stmt)); + val = const_binop (gimple_cond_code (stmt), +boolean_type_node, +gimple_cond_lhs (stmt), gimple_cond_rhs (stmt)); break; case GIMPLE_SWITCH: Or alternatively try to go down Index: gcc/passes.c === --- gcc/passes.c(revision 228750) +++ gcc/passes.c(working copy) @@ -1909,7 +1909,16 @@ execute_function_todo (function *fn, voi push_cfun (fn); - /* Always cleanup the CFG before trying to update SSA. */ + if (flags & TODO_update_ssa_any) +{ + /* Always delete unreachable blocks before trying to update SSA. */ + if (!dom_info_available_p (CDI_DOMINATORS)) + delete_unreachable_blocks (); + + unsigned update_flags = flags & TODO_update_ssa_any; + update_ssa (update_flags); +} + if (flags & TODO_cleanup_cfg) { cleanup_tree_cfg (); @@ -1930,10 +1939,9 @@ execute_function_todo (function *fn, voi still need to do one. */ if (!(flags & TODO_update_ssa_any) && need_ssa_update_p (cfun)) flags |= TODO_update_ssa; -} - if (flags & TODO_update_ssa_any) -{ + /* ??? We want to fix the above issue by keeping SSA for up-to-date + which might be easier when we have updated SSA before CFG cleanup. */ unsigned update_flags = flags & TODO_update_ssa_any; update_ssa (update_flags); } with all the consequences of even after fixing ??? the probably more expensive SSA update (on a not cleaned up CFG). I'm re-testing the first hunk (without instrumenting for regressions...)
[Bug tree-optimization/67949] New: Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67949 Bug ID: 67949 Summary: Regression in GCC-6.0.0's optimizer Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ishiura-compiler at ml dot kwansei.ac.jp Target Milestone: --- We compiled a program (A.c) by GCC-5.1.0 and GCC-6.0.0 with -O3 option. GCC-5.1.0 performed better optimization than GCC-6.0.0. (A.c) #include int x110 = 0; int main (void) { volatile int x129 = 1; int t0 = 1; t0 = (x129==1)<=(2U^(-(1-x110<<2))); if (t0 == 1) { } else { __builtin_abort(); } return 0; } +-+-+ |gcc-5.1.0.s (gcc-5.1.0 A.c -O3 -S) | gcc-6.0.0.s (gcc-6.0.0 A.c -O3 -S)| +-+-+ |.globl main |.globl main | |.type main, @function |.type main, @function | |main:|main: | |.LFB23: |.LFB11: | |.cfi_startproc |.cfi_startproc | |movl$1, -4(%rsp) |subq$24, %rsp | |movl-4(%rsp), %eax |.cfi_def_cfa_offset 32 | | |xorl%edx, %edx | | |movl$1, 12(%rsp) | | |movl12(%rsp), %eax | | |cmpl$1, %eax | | |movl$1, %eax | | |sete%dl | | |sublx110(%rip), %eax | | |sall$2, %eax | | |negl%eax | | |xorl$2, %eax | | |cmpl%eax, %edx | | |ja .L5 | |xorl%eax, %eax |xorl%eax, %eax | | |addq$24, %rsp | | |.cfi_remember_state | | |.cfi_def_cfa_offset 8 | |ret |ret | | |.L5: | | |.cfi_restore_state | | |callabort | |.cfi_endproc |.cfi_endproc | |.LFE23: |.LFE11: | |.size main, .-main |.size main, .-main | |.section.text.unlikely |.section .text.unlikely | |.LCOLDE0:|.LCOLDE0: | |.size x110, 4 |.size x110, 4 | |x110:|x110: | |.zero 4|.zero 4 | +-+-+ Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-a
[Bug fortran/67933] [4.9/5/6 Regression] ICE for array of a derived type with allocatable class in derived type object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67933 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Known to work||4.8.5 Ever confirmed|0 |1 Known to fail||4.9.3, 5.2.0, 6.0 --- Comment #1 from Dominique d'Humieres --- Confirmed. The ICE appeared between revisions r206362 (2014-01-06, compiles) and r206567 (2014-01-12, ICE): usual suspect r206379 (pr59589).
[Bug rtl-optimization/67814] cmp instruction register allocation error (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67814 Uroš Bizjak changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Uroš Bizjak --- (In reply to Jameson from comment #4) > I couldn't find any generic linux binaries for 5.2 (or 6) to test. The > downlink link from the download page to > https://gcc.gnu.org/wiki/GFortranBinaries seems to go to a non-existant site > gfortran.com > > I tested with the mingw64-gcc v5.2.0 compiler and, like you, was not able to > reproduce the issue (I had originally noticed the issue on mingw64-gcc). So > it seems like either the issue got resolved, or some other optimization is > hiding it (it was pretty sensitive to the set of flags passed to gcc in > 4.9.1 and 5.1.1). Is there any chance the fix will be backported to the > major binary distribution channels such as Ubuntu? It is up to the distribution to update releases or backport specific patches from the master repository. I have checked all active branches (gcc-4.9, gcc-5 and gcc-6) and all latest revisions fail to generate problematic instruction with the provided compile flags. So, WORKSFORME.
[Bug tree-optimization/67476] Add --param parloops-schedule=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67476 --- Comment #11 from vries at gcc dot gnu.org --- Author: vries Date: Tue Oct 13 10:08:40 2015 New Revision: 228754 URL: https://gcc.gnu.org/viewcvs?rev=228754&root=gcc&view=rev Log: Handle original loop tree in expand_omp_for_generic 2015-10-13 Tom de Vries PR tree-optimization/67476 * omp-low.c (expand_omp_for_generic): Handle original loop tree. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
[Bug tree-optimization/67476] Add --param parloops-schedule=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67476 --- Comment #12 from vries at gcc dot gnu.org --- Author: vries Date: Tue Oct 13 10:08:59 2015 New Revision: 228756 URL: https://gcc.gnu.org/viewcvs?rev=228756&root=gcc&view=rev Log: Add param parloops-schedule 2015-10-13 Tom de Vries PR tree-optimization/67476 * doc/invoke.texi (@item parloops-schedule): New item. * params.def (PARAM_PARLOOPS_SCHEDULE): New DEFPARAMENUM5. * tree-parloops.c: Include params-enum.h. (create_parallel_loop): Handle PARAM_PARLOOPS_SCHEDULE. * testsuite/libgomp.c/autopar-3.c: New test. * testsuite/libgomp.c/autopar-4.c: New test. * testsuite/libgomp.c/autopar-5.c: New test. * testsuite/libgomp.c/autopar-6.c: New test. * testsuite/libgomp.c/autopar-7.c: New test. * testsuite/libgomp.c/autopar-8.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/autopar-3.c trunk/libgomp/testsuite/libgomp.c/autopar-4.c trunk/libgomp/testsuite/libgomp.c/autopar-5.c trunk/libgomp/testsuite/libgomp.c/autopar-6.c trunk/libgomp/testsuite/libgomp.c/autopar-7.c trunk/libgomp/testsuite/libgomp.c/autopar-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/tree-parloops.c trunk/libgomp/ChangeLog
[Bug c++/67950] New: AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 Bug ID: 67950 Summary: AIX: Illegal instruction in accept() Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: streibel.2003 at gmx dot net Target Milestone: --- Created attachment 36494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36494&action=edit Output of the GCC build process (make) I compiled GCC, Version 4.9.3 on an AIX 7.1 machine. The output of the build process (make) is in the appendix. A C test program which calls accept() works fine when compiled with gcc. However it crashes within the accept() function when compiled with g++. The crash happens as soon as a client connects to the server: [root@dev71 tmp]# uname -a AIX dev71 1 7 00F6C0A94C00 [root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -o tcpserver tcpserver.c [root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver tcpserver.c ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept: The branch at address 0x8a8 is not followed by a recognized no-op or TOC-reload instruction. The unrecognized instruction is 0x7C691B78. ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept: The branch at address 0x8a8 is not followed by a recognized no-op or TOC-reload instruction. The unrecognized instruction is 0x7C691B78. [root@dev71 tmp]# ./tcpserver 1234 --> before accept() <-- Illegal instruction (core dumped) [root@dev71 tmp]# A self compiled GCC, Version 4.9.1 Shows the same behaviour. A GCC, Version 4.8.3 which we installed via an RPM package works fine.
[Bug c++/67951] New: Wshadow for type inferenced (auto) lambda parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67951 Bug ID: 67951 Summary: Wshadow for type inferenced (auto) lambda parameters Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.auer at cgi dot com Target Milestone: --- int f() { auto l = [](int i) {}; int i=0; l(i); return i; } void h() { auto l = [](auto i) {}; int i=0; l(i); } If compiled with "g++ -std=c++1y -Wshadow", I get a warning in h: shadow.cpp:15:23: warning: declaration of ‘i’ shadows a previous local [-Wshadow] auto l = [](auto i) {}; ^ shadow.cpp:17:9: note: shadowed declaration is here int i=0; I think this is wrong. If it is not wrong, it is inconsistent because there is no warning in f().
[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67947 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r228599, I think there's a dup somewhere... likely PR67920.
[Bug tree-optimization/67920] [6 Regression] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- This should be the same as PR67947 which has a testcase.
[Bug tree-optimization/67916] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67916 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r228599 as well.
[Bug tree-optimization/67949] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67949 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I can't reproduce, with the current trunk I see .p2align 4,,15 .globl main .type main, @function main: .LFB11: .cfi_startproc movl$1, -4(%rsp) movl-4(%rsp), %eax xorl%eax, %eax ret .cfi_endproc .LFE11: .size main, .-main .globl x110 .bss .align 4 .type x110, @object .size x110, 4 x110: .zero 4
[Bug c++/67950] AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The output of building GCC is not very helpful, please see https://gcc.gnu.org/bugs/
[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921 Marek Polacek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r224020.
[Bug c++/67952] New: Compilation error with boost::signals2 and generic lambda: cannot call member function without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67952 Bug ID: 67952 Summary: Compilation error with boost::signals2 and generic lambda: cannot call member function without object Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.auer at cgi dot com Target Milestone: --- Created attachment 36495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36495&action=edit Preprocessed source code The following code doesn't compile with boost 1.59 and gcc 5.1, but with clang 3.6: #include class A { public: A() { // these two work sig2.connect( [this]() {f();} ); sig.connect( [this](auto x) {this->g(x);} ); // this does not work sig.connect( [this](auto x) {g(x);} ); } private: void f(); void g(int); boost::signals2::signal sig; boost::signals2::signal sig2; }; The error message is shadow.cpp: In instantiation of ‘A::A():: [with auto:2 = int]’: /lhome1/auerj/opt/include/boost/function/function_template.hpp:153:11: required from ‘static void boost::detail::function::void_function_obj_invoker1::invoke(boost::detail::function::function_buffer&, T0) [with FunctionObj = A::A()::; R = void; T0 = int]’ /lhome1/auerj/opt/include/boost/function/function_template.hpp:934:38: required from ‘void boost::function1::assign_to(Functor) [with Functor = A::A()::; R = void; T0 = int]’ /lhome1/auerj/opt/include/boost/function/function_template.hpp:722:7: required from ‘boost::function1::function1(Functor, typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), int>::type) [with Functor = A::A()::; R = void; T0 = int; typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), int>::type = int]’ /lhome1/auerj/opt/include/boost/function/function_template.hpp:1071:16: required from ‘boost::function::function(Functor, typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), int>::type) [with Functor = A::A()::; R = void; T0 = int; typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), int>::type = int]’ /lhome1/auerj/opt/include/boost/function/function_template.hpp:1126:5: required from ‘typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), boost::function&>::type boost::function::operator=(Functor) [with Functor = A::A()::; R = void; T0 = int; typename boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value), boost::function&>::type = boost::function&]’ /lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:160:24: required from ‘void boost::signals2::slot::init_slot_function(const F&) [with F = A::A()::; SlotFunction = boost::function; R = void; Args = {int}]’ /lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:85:27: required from ‘boost::signals2::slot::slot(const F&) [with F = A::A()::; SlotFunction = boost::function; R = void; Args = {int}]’ shadow.cpp:13:45: required from here shadow.cpp:13:38: error: cannot call member function ‘void A::g(int)’ without object sig.connect( [this](auto x) {g(x);} ); I think it is a compiler bug because adding the implicit this-> solves the problem (see second connect). My gcc version: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/lhome1/auerj/opt/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-5.1.0/configure --prefix=/lhome1/auerj/opt --enable-languages=c,c++ Thread model: posix gcc version 5.1.0 (GCC) I have attached the preprocessed output so it should be easy to reproduce the issue. It is probably a duplicate of 61636, but I such that it can be tracked as such. I guess boost::signals2 is a popular library, so it may be worth to have it in the database explicitly.
[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67952 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Summary|Compilation error with |[C++14] Compilation error |boost::signals2 and generic |with boost::signals2 and |lambda: cannot call member |generic lambda: cannot call |function without object |member function without ||object Ever confirmed|0 |1 Known to fail||4.9.3, 5.2.0, 6.0 --- Comment #1 from Jonathan Wakely --- Nothing to do with Boost, so it doesn't need thousands of lines of Boost headers to reproduce it: template struct signal; template struct signal { template void connect(F f) { f( Args{}... ); } }; class A { public: A() { // these two work sig2.connect( [this]() {f();} ); sig.connect( [this](auto x) {this->g(x);} ); // this does not work sig.connect( [this](auto x) {g(x);} ); } private: void f(); void g(int); signal sig; signal sig2; };
[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67952 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Does look like another dup. *** This bug has been marked as a duplicate of bug 61636 ***
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636 Jonathan Wakely changed: What|Removed |Added CC||jens.auer at cgi dot com --- Comment #14 from Jonathan Wakely --- *** Bug 67952 has been marked as a duplicate of this bug. ***
[Bug other/62279] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 --- Comment #5 from Stanislav Angelovic --- (In reply to Mikhail Maltsev from comment #4) > (In reply to Stanislav Angelovic from comment #3) > > GDB 7.7.1 demangler crashes upon this symbol in our binary: > > > > _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTask > > C4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt1 > > 6remove_referenceISC_E4typeE > > Whis works fine with binutils 2.25 and gives: > > std::allocator :AsyncTask WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void > (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, > WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&& > std::forward Utils::AsyncTask::AsyncTask const, WIM_DL::Hardware::FpgaWatchdog*>(int, bool, > std::allocator :AsyncTask WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void > (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, > WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&, > WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > > const>(std::remove_reference _Bind_simple (WIM_DL::Hardware::FpgaWatchdog::*)() const, > WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void > (WIM_DL::Hardware::FpgaWatchdog::*&&)() const, > WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const>::type&) > > Could you try a newer version of GDB? Thanks for the fast response, Mikhail. We use tools shipped with Yocto, so our hands are tied to some extent. But I tried binutils 2.25 and there it works. Thank you!
[Bug c++/67950] AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 --- Comment #2 from Hans Streibel --- Ok, here is the missing Information: [root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc-4.9.3-hans/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc-4.9.3-hans/libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/lto-wrapper Target: powerpc-ibm-aix7.1.0.0 Configured with: ./configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --prefix=/opt/gcc-4.9.3-hans --enable-languages=c,c++ --enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd --host=powerpc-ibm-aix7.1.0.0 Thread model: aix gcc version 4.9.3 (GCC) Compiler warnings: Beside the warnings that where already in the original post, there are no warnings, even None with -W and -Wall Preprocessed files: - tcpserver.i (produced by gcc) - tcpserver.ii (produced by g++)
[Bug c++/67950] AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 --- Comment #3 from Hans Streibel --- Created attachment 36496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36496&action=edit gcc preprocessed result
[Bug c++/67950] AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 --- Comment #4 from Hans Streibel --- Created attachment 36497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36497&action=edit g++ preprocessed result
[Bug c++/67950] AIX: Illegal instruction in accept()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950 --- Comment #5 from Hans Streibel --- Just noticed: Adding an optimization flag -O1 or -O2 to g++ removes this bug (-O0 does not help): [root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver.4.9.3++ -O1 -Wall tcpserver.c [root@dev71 tmp]# ./tcpserver.4.9.3++ 1234 --> before accept() <-- --> accept() returned: 4 <-- fd after accept(): 4 abc read 0 bytes from the socket. Socket is closed --> before accept() <--
[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67909 --- Comment #3 from Yuri Rumyantsev --- Check that guard edge is around the inner loop was missed. After adding it 416.gamess run successfully. I sent the fix for review.
[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67909 --- Comment #4 from Yuri Rumyantsev --- Created attachment 36498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36498&action=edit proposed patch This patch cures run-time error for 416.gamess.
[Bug tree-optimization/67953] New: [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67953 Bug ID: 67953 Summary: [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org CC: mpolacek at gcc dot gnu.org Target Milestone: --- $ cat z.c #include unsigned f(signed a){ return (unsigned)a-((a/3)*3); } unsigned g(signed a){ return a-((a/3)*3); } int main(){ printf("%d %d\n", f(-5), g(-5)); } $ gcc-5 z.c && ./a.out -2 -2 $ clang z.c && ./a.out -2 -2 $ gcc-snapshot z.c && ./a.out 2 -2
[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67953 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r225195 :(.
[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67915 --- Comment #3 from Richard Biener --- Index: gcc/tree-cfgcleanup.c === --- gcc/tree-cfgcleanup.c (revision 228753) +++ gcc/tree-cfgcleanup.c (working copy) @@ -103,17 +103,22 @@ cleanup_control_expr_graph (basic_block edge e; edge_iterator ei; bool warned; - location_t loc; fold_defer_overflow_warnings (); - loc = gimple_location (stmt); switch (gimple_code (stmt)) { case GIMPLE_COND: - val = fold_binary_loc (loc, gimple_cond_code (stmt), -boolean_type_node, -gimple_cond_lhs (stmt), -gimple_cond_rhs (stmt)); + val = const_binop (gimple_cond_code (stmt), +boolean_type_node, +gimple_cond_lhs (stmt), gimple_cond_rhs (stmt)); + if (!val) + { + tree tem = fold_binary (gimple_cond_code (stmt), + boolean_type_node, + gimple_cond_lhs (stmt), + gimple_cond_rhs (stmt)); + gcc_assert (!tem || TREE_CODE (tem) != INTEGER_CST); + } break; case GIMPLE_SWITCH: fails in configuring stage2 gcc/ on if (_12 < 0) but probably because of your earlier patch now ... and with that disabled on if (base.96 != base.96) which is during CFG build in stage2 libcpp lex.c. It's the GIMPLIFIERs "CSE" producing : base.96 = base; base.96 = base; if (base.96 != base.96) (see gimplify.c:lookup_tmp_var) and us not folding that stmt during gimplification (the thing to fix). Let's see how far I get with that ;)
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment #8 from Matthijs Kooijman --- Seems not - just tried with avr-gcc 5.1 and it is still broken: $ avr-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null test.i: In function 'rtems_fdisk_recycle_segment': test.i:107:1: error: unable to find a register to spill in class 'POINTER_REGS' } ^ test.i:107:1: error: this is the insn: (insn 30 29 31 2 (set (reg:HI 26 r26) (reg/v/f:HI 51 [ dpd ])) /home/matthijs/test.i:95 83 {*movhi} (nil)) test.i:107: confused by earlier errors, bailing out $ avr-gcc --version avr-gcc (GCC) 5.1.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On the Arduino bugtracker [1], another testcase with the same symptoms was reported. I'm attaching that here. This testcase works with -O2, but breaks when -Os is used. $ avr-gcc -c -Os -mmcu=atmega328p test2.c -o /dev/null test2.c: In function 'getSlope': test2.c:22:1: error: unable to find a register to spill in class 'POINTER_REGS' } ^ test2.c:22:1: error: this is the insn: (insn 40 38 42 3 (set (reg:SF 63 [ D.1613 ]) (mem:SF (post_inc:HI (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73])) [1 MEM[base: _27, offset: 0B]+0 S4 A8])) /home/matthijs/test.c:15 100 {*movsf} (expr_list:REG_INC (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73]) (nil))) test2.c:22: confused by earlier errors, bailing out [1]: https://github.com/arduino/Arduino/issues/3972
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 --- Comment #9 from Matthijs Kooijman --- Created attachment 36499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36499&action=edit Second testcase, needs -Os to break
[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58002 --- Comment #1 from Dominique d'Humieres --- The test Module m200c2 Integer,Target :: x = 42 Contains Function fx() Integer,Pointer :: fx fx => x End Function End Module Program q1 Use m200c2 Call test(x,fx()) ! The call. Contains Subroutine test(a,b) Integer :: a,b a = a*10 ! The assignment. Print *,a,b End Subroutine End Program outputs 420 420 Am I correct to understand that this answer is OK for Fortran 2008, but should be 420 42 for Fortran 2003 and older? Note that if I replace the line Call test(x,fx()) ! The call. with Call test(x,(fx())) ! The call. I get the later answer.
[Bug fortran/67936] Off-by-one column for some caret locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67936 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for 5.2 and 6.0 (trunk).
[Bug tree-optimization/67949] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67949 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Seems to be fixed if it was ever broken.
[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945 --- Comment #5 from Alexander Fomin --- Created attachment 36500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36500&action=edit Folding regression reproducer Unfortunately, it does not for x86-64. Please take a look at the attached reproducer. When compiling with -m64 -O2 -ffast-math -S it does not perform expected folding. r228614 : y.1_2 = y; _3 = __builtin_sqrt (y.1_2); *x_4(D) = _3; powroot_18 = __builtin_sqrt (_3); powroot_19 = _3 * powroot_18; powroot_20 = y.1_2 * powroot_19; y = powroot_20; r228616 : y.1_2 = y; _3 = __builtin_sqrt (y.1_2); *x_4(D) = _3; powroot_18 = __builtin_pow (y.1_2, 2.5e-1); powroot_19 = _3 * powroot_18; powroot_20 = y.1_2 * powroot_19; y = powroot_20;
[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67909 --- Comment #5 from Ilya Enkovich --- Author: ienkovich Date: Tue Oct 13 13:08:31 2015 New Revision: 228760 URL: https://gcc.gnu.org/viewcvs?rev=228760&root=gcc&view=rev Log: gcc/ 2014-10-13 Yuri Rumyantsev PR tree-optimization/67909, 67947 * tree-ssa-loop-unswitch.c (find_loop_guard): Add check that GUARD_EDGE really skip the inner loop. gcc/testsuite/ 2014-10-13 Yuri Rumyantsev PR tree-optimization/67909, 67947 * gcc.dg/torture/pr67947.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr67947.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c
[Bug fortran/67743] Associating entity is not auto-typed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67743 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.8 up to trunk (6.0). Probably related to pr67744.
[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67944 --- Comment #3 from Segher Boessenkool --- Your expectation is not in line with what the compiler actually promises you: the only guarantee is that the local register variable will be in (in your case) ebx _where used in an asm statement_. Other than that, it is just a local variable. You get a save/restore sequence in the prologue and epilogue because ebx is a non-volatile register and this function uses that register. Scheduling later moves the push later in the code. If you want to simply grab what is in ebx, you can use asm, like long reg; asm("mov %%ebx,%0" : "=r"(reg));
[Bug tree-optimization/67920] [6 Regression] wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920 --- Comment #8 from Yuri Rumyantsev --- Please check that revision 228760 will cure your issue.
[Bug fortran/67744] polymorphic associating entity is refused TBP invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Dominique d'Humieres --- > The first sentence, I think, implies that my code example is valid. IMO everything is in the "if", but I don't know the answer. Note that this may be related to pr67743.
[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67947 --- Comment #2 from Yuri Rumyantsev --- revision 228760 must fix this bug.
[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67696 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- On x86_64-apple-darwin14 with lldb I get frame #5: 0x00010e95 a.out`__foo_MOD_cp__b + 14 at pr67696.f90:4 frame #6: 0x00010e9e a.out`test + 9 at pr67696.f90:10 frame #7: 0x00010ed7 a.out`main(argc=1, argv="/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out") + 54 at pr67696.f90:9 and with gdb #5 0x00010e95 in cp__b () at pr67696.f90:4 #6 0x00010e9e in test () at pr67696.f90:10 #7 0x00010ed7 in main (argc=1, argv=0x7fff5fbff5b0) at pr67696.f90:9
[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58002 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1
[Bug rtl-optimization/67954] New: [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67954 Bug ID: 67954 Summary: [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1281 Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dbaryshkov at gmail dot com Target Milestone: --- Created attachment 36501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36501&action=edit Preprocessed source file Since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210824 GCC fails with ICE when generating ARM Thumb1 code: /tmp/test.i: In function 'ubidi_writeReordered_55': /tmp/test.i:4748:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1303 } ^ 0x63700e patch_jump_insn ../../gcc/gcc/cfgrtl.c:1303 0x63715b redirect_branch_edge ../../gcc/gcc/cfgrtl.c:1329 0x6376e2 rtl_redirect_edge_and_branch ../../gcc/gcc/cfgrtl.c:1462 0x629889 redirect_edge_and_branch(edge_def*, basic_block_def*) ../../gcc/gcc/cfghooks.c:376 0xd0be1d try_forward_edges ../../gcc/gcc/cfgcleanup.c:621 0xd0be1d try_optimize_cfg ../../gcc/gcc/cfgcleanup.c:2835 0xd0be1d cleanup_cfg(int) ../../gcc/gcc/cfgcleanup.c:3049 0xd0d318 execute ../../gcc/gcc/cfgcleanup.c:3178 The following commands fail: * gcc -march=armv4t -mthumb /tmp/test.i -S -o /tmp/test.o -O1 -fcrossjumping * gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o -O1 -fcrossjumping * gcc -march=armv6 -mthumb /tmp/test.i -S -o /tmp/test.o -O1 -fcrossjumping The following work: * gcc -march=armv6t2 -mthumb /tmp/test.i -S -o /tmp/test.o -O1 -fcrossjumping * gcc -march=armv5te -marm /tmp/test.i -S -o /tmp/test.o -O1 -fcrossjumping * gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o -O1 The log was produced using clear gcc from gcc-5_1_0-release tag. The following configure options were passed to gcc: ../gcc/configure --build=x86_64-linux --host=x86_64-linux --target=arm-linux-gnueabi --enable-languages=c --enable-checking=all --disable-nls
[Bug fortran/52265] [OOP] TREE dump confusing with nested SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Still present at r228753.
[Bug fortran/51380] ASSIGNMENT(=): Reject ALLOCATABLE/POINTER dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51380 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still no error/warning at r228753 (trunk 6.0).
[Bug fortran/48997] Don't use allocatable arrays for function elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48997 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Thomas, what is the status of this? PING!
[Bug fortran/49590] ENTRY: Reject combining USE associated variable with RESULT variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49590 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Still present at r228753 (trunk 6.0).
[Bug fortran/47495] .mod files: File modification time - Makefile build issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #13 from Dominique d'Humieres --- Is this still of interest?
[Bug fortran/51820] [doc] underscoring documentation incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Any interest for this?
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- On trunk (6.0 r228753) this has been changed to /* Functions returning pointers or allocatables need temporaries. */ c = expr2->value.function.esym ? (expr2->value.function.esym->attr.pointer || expr2->value.function.esym->attr.allocatable) : (expr2->symtree->n.sym->attr.pointer || expr2->symtree->n.sym->attr.allocatable); if (c) return true; Any point to keep this PR opened?
[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #39 from Christopher Torres --- (In reply to Alexandre Oliva from comment #36) > Created attachment 36472 [details] > backported patch for the 4.9 branch > > Chris, > > retbnd is of no concern, nothing equivalent existed back then. > > call_stmt was called gimple_call. > > Here's a backported patch, barely tested. Please let me know how it goes > for you. Thank you. Looking at the diff it doesn't look like this will actually compile since redbnd and call_stmt is still in there. Did you maybe upload the wrong patch file? Thanks
[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67696 Joost VandeVondele changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Status|WAITING |UNCONFIRMED CC||Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|1 |0 --- Comment #2 from Joost VandeVondele --- so seemingly target specific ?
[Bug tree-optimization/67955] New: tree-dse does not use pointer info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955 Bug ID: 67955 Summary: tree-dse does not use pointer info Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider this testcase, with dead store '*p = 1': ... int f () { int a; int *p = &a; *p = 1; a = 2; return a; } ... We compile with -O2 -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre. At dse1 we have ... f () { int * p; int a; int _5; : p_1 = &a; *p_1 = 1; a = 2; _5 = a; a ={v} {CLOBBER}; return _5; } ... So, the dead store '*p_1 = 1' has not been eliminated. However, at ealias we already know: ... Alias information for f Aliased symbols a, UID D.1757, int, is addressable Call clobber information ESCAPED, points-to non-local, points-to vars: { } Flow-insensitive points-to information p_1, points-to vars: { D.1757 } ... So, we could use points-to info in dce.
[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67915 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Taking.
[Bug tree-optimization/67955] tree-dse does not use pointer info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955 --- Comment #1 from Richard Biener --- We use "must point to" nowhere because we don't compute it ;) The same points-to set results from int *p = (int *)((char *)&a + 2); or even int *p = &a + 1; so you can't use points-to info that way (to derive a must-alias).
[Bug rtl-optimization/67954] [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67954 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3
[Bug c/67930] segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67930 --- Comment #2 from BENAÏSSA --- Thank you for your reply. Comments:: I am not convinced by your point of view. 1- the compilation step does not deliver any message. 2- I modify the string by address and this is permitted by C for any entity not private in its context. 3- if the compiler gcc allows segmentation fault for basic operations on pointers, I think that this is a severe bug and in consequence the compiler must be modified to remedie for such situations. This is my point of view. A.Benaïssa Le Lundi 12 octobre 2015 13h16, mpolacek at gcc dot gnu.org a écrit : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67930 Marek Polacek changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- You're trying to modify a string literal. That's no-no.
[Bug libstdc++/67932] Incorrect conversion to hexfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932 --- Comment #9 from R Copley --- For information, this has already been entered on the mingw-w64 issue tracker (months ago) (see http://sourceforge.net/p/mingw-w64/bugs/459/).
[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937 --- Comment #4 from Joshua Cranmer --- (In reply to Richard Biener from comment #3) > Most interesting would be a C testcase that produces the CFG with the bogus > counters ;) Yeah, I know, but doing the minimization on a 5MLOC program takes time.
[Bug c/67930] segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67930 --- Comment #3 from Andrew Pinski --- Try adding -W -Wall and also -WWrite-string
[Bug libstdc++/67932] Incorrect conversion to hexfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://sourceforge.net/p/mi ||ngw-w64/bugs/459/ Resolution|--- |MOVED --- Comment #10 from Jonathan Wakely --- Thanks for the link.
[Bug c/67925] docs lie about being unable to inline function call before definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67925 Arkadiusz Drabczyk changed: What|Removed |Added Attachment #36488|0 |1 is obsolete|| --- Comment #7 from Arkadiusz Drabczyk --- Created attachment 36502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36502&action=edit better suggested patch
[Bug c/67925] docs lie about being unable to inline function call before definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67925 --- Comment #8 from Arkadiusz Drabczyk --- I attach a new patch with an extra whitespace after dot to keep up with an existing convention.
[Bug c/67956] New: gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956 Bug ID: 67956 Summary: gcc's printf attribute accepts %m as a format character Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: christos at zoulas dot com Target Milestone: --- Created attachment 36503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36503&action=edit patch According to TOG (http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is not a legal formatting character for printf(3) like functions. Some implementations (glibc) accept this formatting character as an extension and expand it to the error string via strerror(3) that errno currently points to. Most other c library implementations do not expand %m. Attached is a patch that makes printf warn when %m is present and adds a "syslog" attribute that accepts %m. I recognize that this is an incompatible change, and I welcome suggestions how to do this in a less intrusive way. I tried to mininize the size of the patch; there are better ways to do this, but require more refactoring.
[Bug c/67957] New: gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67957 Bug ID: 67957 Summary: gcc's printf attribute accepts %m as a format character Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: christos at zoulas dot com Target Milestone: --- According to TOG (http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is not a legal formatting character for printf(3) like functions. Some implementations (glibc) accept this formatting character as an extension and expand it to the error string via strerror(3) that errno currently points to. Most other c library implementations do not expand %m. Attached is a patch that makes printf warn when %m is present and adds a "syslog" attribute that accepts %m. I recognize that this is an incompatible change, and I welcome suggestions how to do this in a less intrusive way. I tried to mininize the size of the patch; there are better ways to do this, but require more refactoring.
[Bug c/67957] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67957 --- Comment #1 from Christos Zoulas --- Created attachment 36504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36504&action=edit patch
[Bug c/67957] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67957 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andreas Schwab --- . *** This bug has been marked as a duplicate of bug 67956 ***
[Bug c/67956] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956 --- Comment #1 from Andreas Schwab --- *** Bug 67957 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/67955] tree-dse does not use pointer info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955 --- Comment #2 from vries at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > The same points-to set results from > > int *p = (int *)((char *)&a + 2); > > or even > > int *p = &a + 1; > I see, I didn't realize that. But AFAICT, in both these cases, storing to *p is illegal (if 'a' is a scalar int). > so you can't use points-to info that way (to derive a must-alias). I see your point related to an array object, there pointers to different array elements would have identical points-to sets. I wonder though: if we have a store '*p = 0', and the size of the store is the same as the size of the pointed-to object of pointer p, can't we conclude that pointer p points to the start of the object?
[Bug c/67956] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956 --- Comment #2 from Christos Zoulas --- something is wrong with the bug tracking system, when posting a bug with an attachment as the first post; this is how the dup got created.
[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 --- Comment #4 from Alexandros Syrakos --- Dominique, thanks for the quick reply. Your answer is just, but I'm afraid that due to lack of appropriate skills I can't be much more help than reporting bugs. Concerning the present bug, let me add some more information: Your suggestion of removing the "parameter" keyword is nice as a workaround but it doesn't work for arrays of strings. Consider for example the following modification of the original code: program ISO_CONST_SUBST_PR implicit none integer, parameter :: UNICODE=selected_char_kind('ISO_10646') integer, parameter :: DEFAULT=selected_char_kind('DEFAULT') !character(kind=UNICODE,len=*),parameter :: string='my string' character(kind=UNICODE,len=9) :: string='my string' character(kind=UNICODE,len=9), dimension(2) :: page page = string write(*,'(A, I0, A, I0)') 'Unicode and default character kinds are: ',UNICODE,', ',DEFAULT write(*,'(A, I0)') 'kind(string) should be UNICODE and is UNICODE for me: ',kind(string) write(*,'(A, I0)') 'kind(string(2:4)) should be UNICODE and is UNICODE for me: ',kind(string(2:4)) write(*,'(A, I0)') 'kind(page) should be UNICODE and is UNICODE for me: ',kind(page) write(*,'(A, I0)') 'kind(page(1)) should be UNICODE and is UNICODE for me: ',kind(page(1)) write(*,'(A, I0)') 'kind(page(1)(2:4)) should be UNICODE and is DEFAULT for me: ',kind(page(1)(2:4)) end program ISO_CONST_SUBST_PR With gfortran 5.2.0 I get kind(page(1)(2:4)) == DEFAULT instead of UNICODE, although no parameters are involved. Let me include another sample code: program test use iso_fortran_env implicit none integer, parameter ::ucs4 = selected_char_kind( 'ISO_10646' ) character(kind=ucs4) :: a character(kind=ucs4, len=8), dimension(2) :: page a = char( int(z'f17c'), ucs4 ) open (output_unit, encoding='UTF-8') page(1) = repeat(a,8) print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ", page(1) page(1)(2:4) = a print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ", page(1) end program test You can see that, once substring page(1)(2:4) has been modified, although the kind of page(1) is unaltered, printing page(1) to the screen gives rubbish. This practically makes it impossible to use arrays of unicode strings.
[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945 --- Comment #6 from Pat Haugen --- (In reply to Richard Biener from comment #3) > Was this maybe fixed by > > 2015-10-13 Richard Sandiford > > * real.h (real_isinteger): Declare. > * real.c (real_isinteger): New function. > * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y) > if y is an even integer. > > ? That did not fix the powerpc64 failures, they still fail with r228762.
[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-13 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- No warning at r228753.
[Bug c/67956] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956 --- Comment #3 from joseph at codesourcery dot com --- The gnu_printf format attribute is specifically supposed to accept %m; you can use -pedantic to disallow it. Targets can override what the printf attribute maps to; see config/i386/msformat-c.c for example; other OSes should do likewise so the correct set of formats for each target is accepted. The desire for a syslog format is bug 15338.
[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Dominique d'Humieres --- > Note that, in a way, this 'double mangling' is not a bug but a feature. > ... No feedback for more than three years. Closing as WONTFIX.
[Bug middle-end/67912] [6 Regression] ICE in gen_lowpart_common, at emit-rtl.c:1399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912 --- Comment #5 from Alexandre Oliva --- Author: aoliva Date: Tue Oct 13 16:34:29 2015 New Revision: 228774 URL: https://gcc.gnu.org/viewcvs?rev=228774&root=gcc&view=rev Log: support BLKmode inputs for store_bit_field Revision 228586 changed useless_type_conversion_p and added mode changes for MEM:BLKmode inputs in store_expr_with_bounds, but it missed store_bit_field. This caused ada/rts/s-regpat.ads to fail compilation on x86_64-linux-gnu. for gcc/ChangeLog PR middle-end/67912 * expmed.c (store_bit_field_1): Adjust mode of BLKmode inputs. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug middle-end/67912] [6 Regression] ICE in gen_lowpart_common, at emit-rtl.c:1399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912 Alexandre Oliva changed: What|Removed |Added Status|NEW |RESOLVED CC||aoliva at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #6 from Alexandre Oliva --- Mine. Fixed.
[Bug fortran/54082] Program name shadows other entities with the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54082 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Dominique d'Humieres --- As said by Tobias, the code is invalid and, although the error message could be improved, nobody tried to do it during the past three years. IMO it is more realistic to close this PR as WONTFIX rather to let it rot for the next decade.
[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67953 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- So mine.