[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- What command line options are used? With explicit -ftemplate-depth=25 (or even 27) it indeed fails, succeeds with 28, but the default is 900 AFAIK. Have those command line options changed in any way since the compilation with the older g++?
[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org Component|c++ |libstdc++ --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Verified that even with 2.5 years old cc1plus we still trigger the instantiation limit, so it indeed is some changes in libstdc++. Guess you can try -ftemplate-depth=20 etc. in 4.9 to see how close to the limit you were before.
[Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 12 18:09:59 2015 New Revision: 220650 URL: https://gcc.gnu.org/viewcvs?rev=220650root=gccview=rev Log: PR debug/55541 * cp-tree.h (BLOCK_OUTER_CURLY_BRACE_P): Define. * decl.c (poplevel): If functionbody, try not to create an extra BLOCK for function body and use subblocks as that, if it is non-NULL and doesn't have siblings. Set BLOCK_OUTER_CURLY_BRACE_P flag. (outer_curly_brace_block): Use BLOCK_OUTER_CURLY_BRACE_P flag. * g++.dg/debug/dwarf2/localclass3.C: Adjust for the extraneous DW_TAG_lexical_block removal. * g++.dg/debug/dwarf2/redeclaration-1.C: Likewise. * g++.dg/guality/pr55541.C: New test. Added: trunk/gcc/testsuite/g++.dg/guality/pr55541.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/localclass3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/redeclaration-1.C
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 --- Comment #5 from Bin Fan bin.x.fan at oracle dot com --- (In reply to Jason Merrill from comment #3) (In reply to Bin Fan from comment #0) 2. g++ tries to make lock-free property per-type, but the libatomic.so implementation does not match. This. We always pass a null pointer to libatomic and do not pass any information about the alignment of the type. rth suggested that we might try passing a fake, minimally-aligned pointer instead of null as a way of communicating the alignment without adding a new entry point. So after the fix, atomic_is_lock_free will always return 0 for size=3,align=1 atomic struct objects? I understand currently libatomic tries to make an atomic object lock-free if its memory location fit in a certain sized window. So for atomic operations such as atomic_store where the actual address is passed in, the operation can be still either lock-free or locked, right? I'm wondering if it's standard conforming since the lock-free property is still per-object, or it can be seen as an optimization, i.e. atomic_is_lock_free query for the object returns 0, but atomic operations on the object could be lock-free.
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org --- Comment #4 from Richard Henderson rth at gcc dot gnu.org --- Mine.
[Bug debug/55541] [4.8/4.9 Regression] unable to see local variables due extra lexical block was generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] unable |unable to see local |to see local variables due |variables due extra lexical |extra lexical block was |block was generated |generated --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk.
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-12 CC||jason at gcc dot gnu.org, ||rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Bin Fan from comment #0) 2. g++ tries to make lock-free property per-type, but the libatomic.so implementation does not match. This. We always pass a null pointer to libatomic and do not pass any information about the alignment of the type. rth suggested that we might try passing a fake, minimally-aligned pointer instead of null as a way of communicating the alignment without adding a new entry point.
[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 --- Comment #2 from Matěj Cepl mcepl at cepl dot eu --- Created attachment 34741 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34741action=edit preprocessed file
[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, the default is 900. (C++11 recommends 1024 AFAIK.) From what I can see they used /usr/lib64/ccache/g++ -v -save-temps -g3 -O0 -DDEBUG -ftemplate-depth-25 -DHAVE_CONFIG_H -pthread -Idefault/src/main -I../src/main -Idefault -I.. -Idefault/src -I../src -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gconf/2 -I/usr/include/libgsf-1 -I/usr/include/libglade-2.0 -I/usr/include/webkitgtk-1.0 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/sword -I/usr/include/biblesync/bibleysnc -I/usr/include/uuid ../src/main/modulecache.cc -c -o default/src/main/modulecache_1.o I don't know if those command-line options have changed.
[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Note that the package explicitly uses -ftemplate-depth=25 (without that the .ii files compiles fine). So maybe just some changes in libstdc++ that trigger the limit?
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 --- Comment #6 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Bin Fan from comment #5) So after the fix, atomic_is_lock_free will always return 0 for size=3,align=1 atomic struct objects? Yes. I understand currently libatomic tries to make an atomic object lock-free if its memory location fit in a certain sized window. So for atomic operations such as atomic_store where the actual address is passed in, the operation can be still either lock-free or locked, right? Yes. I'm wondering if it's standard conforming since the lock-free property is still per-object, or it can be seen as an optimization, i.e. atomic_is_lock_free query for the object returns 0, but atomic operations on the object could be lock-free. My understanding is that it's valid to optimize the operation to lock-free, but since there may exist objects for which we will have to use the lock, the atomic_is_lock_free query must return false.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #12 from Ian Lance Taylor ian at airs dot com --- I should add that for purposes of Go, it's not all that important that libbacktrace does not yet handle sibling calls, because the Go compiler turns on -fno-optimize-sibling-calls by default (https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01643.html in gcc/go/go-lang.c).
[Bug fortran/64932] [4.9/5 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 --- Comment #5 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Thu Feb 12 19:30:53 2015 New Revision: 220654 URL: https://gcc.gnu.org/viewcvs?rev=220654root=gccview=rev Log: 2015-02-12 Paul Thomas pa...@gcc.gnu.org PR fortran/64932 * trans-stmt.c (gfc_trans_deallocate): If a component array expression is not a descriptor type and it is a derived type that has allocatable components and is not finalizable, then deallocate the allocatable components. 2015-02-12 Paul Thomas pa...@gcc.gnu.org PR fortran/64932 * gfortran.dg/finalize_28.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/finalize_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug target/65030] [5 Regression] ICE (RTL flag check) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65030 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Works with r220637 - may well be a dup of PR65003. Checking.
[Bug target/64979] [4.8 Regression] stdarg optimization not able to find escape sites in phi nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 12 12:17:41 2015 New Revision: 220645 URL: https://gcc.gnu.org/viewcvs?rev=220645root=gccview=rev Log: Backported from mainline 2015-02-09 Jakub Jelinek ja...@redhat.com PR target/64979 * tree-stdarg.c (pass_stdarg::execute): Scan phi node args for va_list escapes. * gcc.dg/tree-ssa/stdarg-7.c: New test. * gcc.c-torture/execute/pr64979.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr64979.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-stdarg.c
[Bug lto/64837] lto plugin doesn't call ld_plugin_release_input_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64837 --- Comment #19 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #18) (In reply to H.J. Lu from comment #17) (In reply to Markus Trippelsdorf from comment #16) (In reply to H.J. Lu from comment #15) (In reply to Markus Trippelsdorf from comment #14) Well, at least your patch survives a Firefox LTO build using gold on a ppc64 test machine. Does it build without my patch? Yes. So all I've tested is that it doesn't crash. Can you lower file descriptor limit such that GCC crashes without my patch and works with my patch? Martin is currently running these tests with Chromium... (Also Carry apparently thinks that the https://sourceware.org/bugzilla/show_bug.cgi?id=15660 issue is caused by archives and not by normal object files.) Hello. I can confirm that following patch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=gold/archive.cc;h=6d259803185368ccbe3b71cda4040d90105b66d3;hp=69107f5fc072ecce25df57cbe22464f74d2cc6da;hb=2cfbf2fece582c29df348104b28677c38a8301f4;hpb=8265ef950202a4bf0d3444802ad5d7087b4b185d works for me. Before the patch was applied, ulimit -n 1 wasn't enough to survive chrome link. With the patch, even 100 is enough. Thanks, Martin
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- And another way to fix this is add a new library entrypoint, that would have the same semantics as memcpy, but would allow full overlap (dst == src). When we e.g. expand this without a library call, we could do exactly what we do for memcpy, because we know we do handle the dst == src case fine. Similarly, e.g. in glibc it could very well be just another alias to memcpy, because we know it handles that too. On targets which would not have the library function we'd use the #c10 approach. Of course, this would require coordination in between glibc, gcc, valgrind, libsanitizer, memstomp etc.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #38 from Terry Guo terry.guo at arm dot com --- (In reply to Kai Tietz from comment #37) I confirm that in libgcc we still have an issue ... Could you please make a new report for libgcc's libgcov-util.c for it. Thanks in advance Reported it at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038. Not sure we can mark them as duplication.
[Bug target/65036] [5 Regression] ICE (RTL flag check) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65036 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Another dup of PR65003 ?
[Bug c++/65017] valgrind error in get_constraint_for_address_of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65017 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Thans for checking.
[Bug target/65031] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65031 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Appears to work with r220637. Checking if dup of PR65003.
[Bug tree-optimization/65014] [5 Regression] ice with error: type mismatch in shift expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65014 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/65035] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65035 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Works with r220637 - may well be
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Marek Polacek from comment #2) Taking. I think check_format_types needs a small tweak to look thru NOP_EXPRs. Well, more like do some lame VR computation and not warn if the signedness doesn't really matter.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
Mark Wielaard mark at gcc dot gnu.org changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5 from Mark Wielaard mark at gcc dot gnu.org ---
Note that this also triggers for code that looks just fine to the user:
#include stdio.h
#include inttypes.h
int
main (int argc, char **argv)
{
uint8_t u = 16;
printf (u = %02 PRIx8 \n, u);
return 0;
}
m.c: In function ‘main’:
m.c:8:11: warning: format ‘%x’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘int’ [-Wformat=]
printf (u = %02 PRIx8 \n, u);
^
Which is somewhat surprising since the user explicitly matched the type and
format specifier.
This is caused by the definition of the PRIx format specifiers all mapping back
to x in inttypes.h
/* lowercase hexadecimal notation. */
# define PRIx8 x
# define PRIx16 x
# define PRIx32 x
[Bug ipa/65039] [5 Regression] g++ 5 segmentation fault when compiling with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65039 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I reproduced this with an out-of-date trunk build, but using today's trunk it compiles OK, so seems to be fixed.
[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- Any updates regarding this problem?
[Bug sanitizer/65019] [5 Regression] Compare debug failure with -fsanitize=alignment,object-size,vptr -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65019 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Marek Polacek mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org --- Taking. I think check_format_types needs a small tweak to look thru NOP_EXPRs.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r209328.
[Bug ipa/65039] [5 Regression] g++ 5 segmentation fault when compiling with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65039 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed by r220531.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c/65040] New: [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
Bug ID: 65040
Summary: [5 Regression] gcc-5 -Wformat broken
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
$ cat | gcc-5 -x c - -c -o /dev/null -Wformat=2
#include stdio.h
void x(unsigned short arg)
{
printf(%x\n, arg);
}
^D
gives:
stdin: In function ‘x’:
stdin:5:16: warning: format ‘%x’ expects argument of type ‘unsigned int’, but
argument 2 has type ‘int’ [-Wformat=]
but we know the range of (int)arg is [0, USHORT_MAX] so the warning isn't
helpful - it is technically true but there is no reason to warn here.
[Bug target/65036] [5 Regression] ICE (RTL flag check) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65036 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- May well be - works with r220637
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-12 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c/65040] [5 Regression] gcc-5 -Wformat broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #6 from Frank Ch. Eigler fche at redhat dot com --- Note that printf is a varargs function, and is defined to widen smaller-than-int parameters to at least int. unsigned short is subsumed in int.
[Bug target/64979] [4.8 Regression] stdarg optimization not able to find escape sites in phi nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #12 from Jeffrey A. Law law at redhat dot com --- *** Bug 64966 has been marked as a duplicate of this bug. ***
[Bug c++/64884] [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 12 21:33:37 2015 New Revision: 220664 URL: https://gcc.gnu.org/viewcvs?rev=220664root=gccview=rev Log: PR c++/64884 * g++.dg/tm/pr47573.C: Only run on comdat_group effective targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tm/pr47573.C
[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64898 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||ABI Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 --- Comment #5 from Jeffrey A. Law law at redhat dot com --- Kirill, you are correct WRT propagation of b for i. Prior to DOM1 we have: ;; basic block 3, loop depth 1, count 0, freq 9100, maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE) ;;pred: 7 [91.0%] (TRUE_VALUE,EXECUTABLE) if (i_1 == b_6(D)) goto bb 4; else goto bb 5; ;;succ: 4 [0.0%] (TRUE_VALUE,EXECUTABLE) ;;5 [100.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 4, loop depth 1, count 0, freq 2, maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE) ;;pred: 3 [0.0%] (TRUE_VALUE,EXECUTABLE) g_x[i_1] = *x1_7(D); goto bb 6; ;;succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 5, loop depth 1, count 0, freq 9098, maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE) ;;pred: 3 [100.0%] (FALSE_VALUE,EXECUTABLE) g_x[i_1] = *x2_9(D); ;;succ: 6 [100.0%] (FALLTHRU,EXECUTABLE) DOM records that i_1 and b_6 are equivalent on the edge bb3-bb4. So in bb4 it replaces i_1 with b_6. Presumably that's causing problems downstream in the optimization pipeline. The easiest way to think about this is we record that i_1 can be legitimately replaced with b_6 in that context. We could just have easily recorded that b_6 can be replaced with i_1. I don't think we have any heuristics for which of those two equivalences to record, it's strictly based on the order of appearance (which is likely determined elsewhere by canonicalization rules). If you want to propose some heuristics, I'm all ears. One might be to put the object with the least number of references on the lhs. THe idea would be to try and ultimately get that use count to 0/1 which may allow that object to die at the comparison. There may be some reasonable heuristic around loop depth of the names as well.ie, do we want to replace uses of a non-loop object with a loop object or vice versa? Anyway, open to suggestions here...
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #13 from Jeffrey A. Law law at redhat dot com --- Created attachment 34742 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34742action=edit Additional testcase Additional testcase. For x86_64 $ gcc -O -fschedule-insns --param=max-sched-ready-insns=0 -fcompare-debug testcase.c gcc: error: testcase.c: -fcompare-debug failure
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Mikael Morin from comment #5) (In reply to Mikael Morin from comment #4) This cures it: Another way to cure it: Index: trans-expr.c === --- trans-expr.c (révision 220514) +++ trans-expr.c (copie de travail) @@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface expr-symtree = sym-new_sym; else if (sym-expr) gfc_replace_expr (expr, gfc_copy_expr (sym-expr)); - /* Replace base type for polymorphic arguments. */ - if (expr-ref expr-ref-type == REF_COMPONENT - sym-expr sym-expr-ts.type == BT_CLASS) - expr-ref-u.c.sym = sym-expr-ts.u.derived; } /* ...and to subexpressions in expr-value. */ unfortunately this would make class_41.f03 fail. class_41.f03 is very similar to this test case. Both do deliberately pass a subclass to the base class, just class_41.f03 uses identical pointer/allocatable attributes, while this test case uses different pointer/allocatable attributes, and this satisfies the condition in r218584. However the intention of r214584 was to avoid aliasing violations between class objects of the _same_ class type and different pointer/allocatable attributes. Additionally to cause problems (at least on ARM, but in theory on any target too...) the class with the wrong attributes must be passed to a subroutine. See PR60718 for details. I see no aliasing problems in this example if we avoid to cast the class type to the destination class type. And the value is not passed to a subroutine. So I would add the following to the condition that make the new block only execute if both objects are of the same class. Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 220543) +++ gcc/fortran/trans-expr.c(working copy) @@ -4539,6 +4539,8 @@ } else if (e-ts.type == BT_CLASS fsym fsym-ts.type == BT_CLASS +CLASS_DATA (fsym)-ts.u.derived + == CLASS_DATA (e)-ts.u.derived !CLASS_DATA (fsym)-as !CLASS_DATA (e)-as (CLASS_DATA (fsym)-attr.class_pointer With this patch all fortran test cases pass on x86_64. And the ICE goes away in the reduced test example. Does it work for you?
[Bug target/65044] New: ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044 Bug ID: 65044 Summary: ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34743 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34743action=edit reduced testcase Compiler output: $ gcc -fsanitize=address -fcheck-pointer-bounds -mmpx testcase.c testcase.c:7:1: internal compiler error: Segmentation fault } ^ 0xc43f1f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:383 0xcee191 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/tree.h:2959 0xcee191 chkp_walk_pointer_assignments /mnt/svn/gcc-trunk/gcc/tree-chkp.c:3591 0xcee06a chkp_walk_pointer_assignments /mnt/svn/gcc-trunk/gcc/tree-chkp.c:3645 0xcf0396 chkp_finish_file() /mnt/svn/gcc-trunk/gcc/tree-chkp.c:3701 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r220566 - ICE
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #8 from Jeffrey A. Law law at redhat dot com --- And for GCC 5, ISTM the question that hasn't been answered, particularly with regard to the second reproducer is whether or this is a regression for the overall performance of that code. It's certainly possible that IRA determined that %ebx was better used to hold a different value and that the PIC register might end up in a call-clobbered register. If the object in %ebx is heavily used, the benefits of keeping that value in %ebx may outweigh the cost of having the PIC value in a different register (say perhaps one that is call-clobbered).
[Bug sanitizer/65000] ICE in in expand_builtin_eh_common, at except.c:2072
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 12 21:30:56 2015 New Revision: 220663 URL: https://gcc.gnu.org/viewcvs?rev=220663root=gccview=rev Log: PR sanitizer/65000 * g++.dg/ubsan/pr65000.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr65000.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/32089] Winline reports bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32089 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||rth at gcc dot gnu.org Known to work||5.0 Resolution|--- |FIXED --- Comment #10 from Richard Henderson rth at gcc dot gnu.org --- We no longer produce the warning. It does appear that the symbol in question is indeed not inlined, so I don't think the problem has gone latent and it really has been fixed somewhere in the previous 7 years.
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law law at redhat dot com --- Of particular interest is this PHI node at the start of BB6: # mw_1 = PHI mw_9(D)(2), h_33(5) I vaguely remember that we had code that would optimize this case, specifically we would ignore PHI alternatives associated with undefined uses. If we did that, then we'd create an equivalence mw_1 = h33 which would then propagate to the use of mw_1 and replace it with h33 and avoid the false positive. I thought that was in the vrp/ccp propagation engine.
[Bug c++/64959] SFINAE in UDLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64959 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Feb 12 20:21:34 2015 New Revision: 220656 URL: https://gcc.gnu.org/viewcvs?rev=220656root=gccview=rev Log: PR c++/64959 * parser.c (lookup_literal_operator): Return all candidates. (cp_parser_userdef_char_literal): Simplify error handling. (cp_parser_userdef_numeric_literal): Pass tf_warning_or_error. (cp_parser_userdef_string_literal): Pass tf_warning_or_error. Also give higher priority to standard string UDL operator. Added: trunk/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-ambiguous.C trunk/gcc/testsuite/g++.dg/cpp0x/udlit-namespace-using-directive.C trunk/gcc/testsuite/g++.dg/cpp0x/udlit-sfinae-neg.C trunk/gcc/testsuite/g++.dg/cpp0x/udlit-sfinae.C trunk/gcc/testsuite/g++.dg/cpp1y/udlit-char-template-sfinae-neg.C trunk/gcc/testsuite/g++.dg/cpp1y/udlit-char-template-sfinae.C trunk/gcc/testsuite/g++.dg/cpp1y/udlit-char-template-vs-std-literal-operator.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.dg/cpp0x/udlit-resolve.C
[Bug fortran/64932] [4.9/5 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 --- Comment #6 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Thu Feb 12 21:06:41 2015 New Revision: 220659 URL: https://gcc.gnu.org/viewcvs?rev=220659root=gccview=rev Log: 2015-02-12 Paul Thomas pa...@gcc.gnu.org PR fortran/64932 * trans-stmt.c (gfc_trans_deallocate): If a component array expression is not a descriptor type and it is a derived type that has allocatable components and is not finalizable, then deallocate the allocatable components. 2015-02-12 Paul Thomas pa...@gcc.gnu.org PR fortran/64932 * gfortran.dg/finalize_28.f90: New test Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/finalize_28.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/trans-stmt.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/64932] [4.9/5 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas pault at gcc dot gnu.org --- Fixed on 4.9 and 5.0. Thanks for the report. Paul
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law law at redhat dot com --- Vlad, What's the rationale behind the 50% probability cutoff for forming an EBB? For the purposes of inheritance, ISTM you want the biggest EBBs possible to give you a maximal window in which to find an insn to inherit from? Or is it the case that EBB formation impacts both spilling and inheritance in IRA/LRA?
[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64898 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Feb 12 22:44:38 2015 New Revision: 220666 URL: https://gcc.gnu.org/viewcvs?rev=220666root=gccview=rev Log: PR c++/64898 * mangle.c (write_mangled_name): Fix test for variable template instantiation. Added: trunk/gcc/testsuite/g++.dg/abi/mangle65.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c
[Bug fortran/65045] New: ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045 Bug ID: 65045 Summary: ICE Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: walt.brainerd at gmail dot com Created attachment 34744 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34744action=edit Tried to use i as variable and construct name gfortran exit_if.f90 exit_if.f90:3.6: if (i7.7) then 1 Error: Symbol at (1) is not appropriate for an expression exit_if.f90:5.7: else 1 Error: Unexpected ELSE statement at (1) exit_if.f90:6.6: i = 2.2 1 Error: 'i' at (1) is not a variable exit_if.f90:7.6: end if 1 Error: Expecting END BLOCK statement at (1) f951.exe: internal compiler error: Segmentation fault
[Bug middle-end/64966] [5 Regression] -fcompare-debug failure with -O -fschedule-insns --param=max-sched-ready-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64966 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Confirmed that the prototype patch in 64935 fixes this problem. Will attach the testcase from this BZ to 64935. *** This bug has been marked as a duplicate of bug 64935 ***
[Bug driver/20705] -pthread should enable all options required to use pthreads on all platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705 Bug 20705 depends on bug 14300, which changed state. Bug 14300 Summary: -pthread doesn't define _REENTRANT in preprocessor on alpha-linux https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14300 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/14300] -pthread doesn't define _REENTRANT in preprocessor on alpha-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14300 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||rth at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- Fixed in 2007, for gcc 4.3, r123888.
[Bug tree-optimization/49316] ICE in in function_and_variable_visibility, at ipa.c:926 with g++.dg/tls/diag-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49316 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Target|alpha-dec-osf5.1b | Status|NEW |RESOLVED CC||rth at gcc dot gnu.org Host|alpha-dec-osf5.1b | Resolution|--- |WORKSFORME Build|alpha-dec-osf5.1b | --- Comment #8 from Richard Henderson rth at gcc dot gnu.org --- Removing the osf5.1b target because that's no longer supported. There's an error in rs6000.c when attempting to cross-compile to rs6000-ibm-aix5.3.0; I didn't spend too much time looking at it. But I reasoned that if this is really any target using emutls, I ought to be able to replicate it with --disable-tls on any host. I don't see the ICE, so I'm willing to believe that the problem has been fixed somewhere in the last 3 years.
[Bug c++/64898] [5 Regression] qtgui-4.8.6 build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64898 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks.
[Bug target/65048] New: [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048
Bug ID: 65048
Summary: [5 Regression] ICE in add_phi_args_after_copy_edge, at
tree-cfg.c on arm-linux-gnueabihf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
seen with 20150205 on arm-linux-gnueabihf, configured with --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
$ gcc -c -g -O3 -Wno-implicit-int -Wno-implicit-function-declaration
translate.i
translate.i:1:1: warning: data definition has no type or storage class
a, b, c, d;
^
translate.i: In function 'fn2':
translate.i:11:1: internal compiler error: in add_phi_args_after_copy_edge, at
tree-cfg.c:5913
fn2() {
^
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat translate.i
a, b, c, d;
fn1(p1) {
switch (p1) {
case 'A':
return 'T';
case 'U':
return 'A';
}
}
fn2() {
for (;;) {
b = fn1();
a = fn1();
fn3(b, a);
}
}
fn3(p1, p2) {
switch (c)
case 'U':
switch (p1) {
default:
fn4();
case 'G':
switch (p2)
case 'A':
d = 7;
}
}
[Bug bootstrap/49242] Bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49242 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||rth at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #5 from Richard Henderson rth at gcc dot gnu.org --- This has been fixed sometime in the past 4 years. I certainly haven't had a problem bootstrapping.
[Bug target/44251] integer constant is too large for ‘long’ type in alpha.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44251 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rth at gcc dot gnu.org Known to work||4.8.0 Resolution|--- |FIXED --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- Fixed in r188535.
[Bug c++/65047] New: [c++17] Add support for nested namespace defintions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65047
Bug ID: 65047
Summary: [c++17] Add support for nested namespace defintions.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrea.azzarone at canonical dot com
Gcc should support nested namespace defintions as per N4230. Basically it
allows to do stuff like this:
namespace A::B {
...
}
[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
--- Comment #11 from Jeffrey A. Law law at redhat dot com ---
Sigh. We can't do the propagation, even if we recognize the mw_9 default
definition represents an undefined value -- because doing so would result in a
use that is not dominated by its def.
We could do duplication and essentially create
if (mini_p)
{
long int a = make_window ();
if (!PSEUDOVECTORP (a)) return rw;
mw = (void*) a - 5;
rw-pixel_width = ((rw-text_cols * (rw-column_width))
+ (rw-left_fringe_width + (rw-right_fringe_width)) + 2 *
(rw-internal_border_width));
rw-pixel_height = ((rw-text_cols * (rw-line_height)));
mw-pixel_height = rw-pixel_height;
}
else
{
rw-pixel_width = ((rw-text_cols * (rw-column_width))
+ (rw-left_fringe_width + (rw-right_fringe_width)) + 2 *
(rw-internal_border_width));
rw-pixel_height = ((rw-text_cols * (rw-line_height)));
}
And in fact, that's precisely what the code to handle joiner blocks in the jump
threader is supposed to do... Hmmm, this might be mine...
[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Richard Henderson rth at gcc dot gnu.org --- Tru64 has been deprecated. Since this has been fixed for HPUX, there are no more live systems with the problem.
[Bug preprocessor/65037] New: cpp inserts spurious newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65037 Bug ID: 65037 Summary: cpp inserts spurious newlines Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jsynacek at redhat dot com The db.h here is a header file from libdb (Berkeley DB). $ cat conftest.c #include db.h __db_version DB_VERSION_MAJOR The new version: $ cpp --version cpp (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.9) $ cpp conftest.c ...snip... # 2 conftest.c 2 # 2 conftest.c __db_version # 2 conftest.c 3 4 5 The older version: $ cpp --version cpp (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1) $ cpp conftest.c ...snip... # 2 conftest.c 2 __db_version 5 Running cpp with -P doesn't generate the spurious line breaks.
[Bug lto/65015] LTO produces randomly ordered debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 --- Comment #5 from conchur at web dot de --- Thanks for the patches. I've rebuild the gcc package (which took the whole afternoon + night on my machine) and can verify that the mini testcases are now working perfectly fine. I've also tried this with some other projects (shared objects and executables) and it now seems to work even without -flto-partition=none Is there any problem with the uncommitted patch that I should know about? Could this patch theoretically be applied in Debian or there problems which the Debian gcc-4.9 maintainers should know about?
[Bug preprocessor/65037] cpp inserts spurious newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65037 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- See PR64864 and PR60723 for more details.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #36 from Kai Tietz ktietz at gcc dot gnu.org --- Well, I guess that you missed to reconfigure gcc. By checking current source is the include of ftw.h guarded by HAVE_FTW_H check, which get defined by configure if header is found.
[Bug target/65030] [5 Regression] ICE (RTL flag check) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65030 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup of PR65003 ?
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- One way to fix this is to emit the memcpy as if (p != q) memcpy (p, q, ...); but of course that comes at a cost in code-size and runtime for no obvious good reason (in practice).
[Bug preprocessor/65037] cpp inserts spurious newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65037 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is by design as we are marking now where macros are located in system headers.
[Bug ipa/65034] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65034 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34738 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34738action=edit gcc5-pr65034.patch Untested fix.
[Bug libgcc/65038] New: Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Bug ID: 65038 Summary: Unable to find ftw.h for libgcov-util.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: terry.guo at arm dot com I am doing a clean trunk build for mingw and facing below issue: /home/build/work/GCC-5-0-build/src/gcc/gcc/../libgcc/libgcov-util.c:55:17: fatal error: ftw.h: No such file or directory compilation terminated. make[1]: *** [libgcov-util.o] Error 1 This looks very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889.
[Bug target/65035] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65035 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Another dup of PR65003 ?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Terry Guo terry.guo at arm dot com changed: What|Removed |Added CC||terry.guo at arm dot com --- Comment #35 from Terry Guo terry.guo at arm dot com --- I am building trunk for mingw and still having issue: /home/build/work/GCC-5-0-build/src/gcc/gcc/../libgcc/libgcov-util.c:55:17: fatal error: ftw.h: No such file or directory compilation terminated. make[1]: *** [libgcov-util.o] Error 1 Is this something we just missed?
[Bug ipa/65034] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65034 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-12 CC||jakub at gcc dot gnu.org Component|target |ipa Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug tree-optimization/65014] [5 Regression] ice with error: type mismatch in shift expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65014
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Thu Feb 12 09:45:27 2015
New Revision: 220640
URL: https://gcc.gnu.org/viewcvs?rev=220640root=gccview=rev
Log:
PR tree-optimization/65014
* fold-const.c (fold_binary_loc): When creating {L,R}ROTATE_EXPR,
use original second operand of arg0 or arg1 instead of
that adjusted by STRIP_NOPS.
* gcc.c-torture/compile/pr65014.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr65014.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
[Bug ipa/65039] [5 Regression] g++ 5 segmentation fault when compiling with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65039 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-12 Component|c++ |ipa Known to work||4.8.3, 4.9.2 Summary|g++ 5 segmentation fault|[5 Regression] g++ 5 |when compiling with -O2 |segmentation fault when |optimization|compiling with -O2 ||optimization Ever confirmed|0 |1 Known to fail||5.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 0xc9602f crash_signal /home/jwakely/src/gcc/gcc/gcc/toplev.c:381 0x12c322a tree_check /home/jwakely/src/gcc/gcc/gcc/tree.h:2845 0x12c322a ipa_icf::sem_function::init() /home/jwakely/src/gcc/gcc/gcc/ipa-icf.c:786 0x12c6a19 ipa_icf::sem_item_optimizer::parse_nonsingleton_classes() /home/jwakely/src/gcc/gcc/gcc/ipa-icf.c:1873 0x12cb9b2 ipa_icf::sem_item_optimizer::execute() /home/jwakely/src/gcc/gcc/gcc/ipa-icf.c:1729 0x12cc5e1 ipa_icf_driver /home/jwakely/src/gcc/gcc/gcc/ipa-icf.c:2459 0x12cc5e1 ipa_icf::pass_ipa_icf::execute(function*) /home/jwakely/src/gcc/gcc/gcc/ipa-icf.c:2507
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #37 from Kai Tietz ktietz at gcc dot gnu.org --- I confirm that in libgcc we still have an issue ... Could you please make a new report for libgcc's libgcov-util.c for it. Thanks in advance
[Bug c++/65039] New: g++ 5 segmentation fault when compiling with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65039 Bug ID: 65039 Summary: g++ 5 segmentation fault when compiling with -O2 optimization Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: truckman at FreeBSD dot org Created attachment 34739 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34739action=edit preprocessed c++ source that triggers g++ segmentation fault when compiling with -O2 # g++5 -v Using built-in specs. COLLECT_GCC=g++5 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc5/gcc/x86_64-portbld-freebsd10.1/5.0.0/lto-wrapper Target: x86_64-portbld-freebsd10.1 Configured with: ./../gcc-5-20150208/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc5 --libexecdir=/usr/local/libexec/gcc5 --program-suffix=5 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc5/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc5 --build=x86_64-portbld-freebsd10.1 Thread model: posix gcc version 5.0.0 20150208 (experimental) (FreeBSD Ports Collection) g++ is getting a segmentation fault when compiling a particular c++ file with -O2 optimization. Compiling with -O0 or -O1 is successful. Fails: # g++5 -std=c++11 -fmessage-length=0 -c -O2 -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-unused-local-typedefs -fpic -fexceptions -fno-enforce-eh-specs -o _serviceregistration_controller.o _serviceregistration_controller.ii /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.1/main/chart2/source/controller/main/_serviceregistration_controller.cxx:113:1: internal compiler error: Segmentation fault } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. Succeeds: # g++5 -std=c++11 -fmessage-length=0 -c -O1 -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-unused-local-typedefs -fpic -fexceptions -fno-enforce-eh-specs -o _serviceregistration_controller.o _serviceregistration_controller.ii #
[Bug target/65031] [5 Regression] ICE (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65031 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Another dup of PR65003 ?
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- See PR54005 for some of the history.
[Bug sanitizer/65019] [5 Regression] Compare debug failure with -fsanitize=alignment,object-size,vptr -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65019 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 12 09:48:44 2015 New Revision: 220641 URL: https://gcc.gnu.org/viewcvs?rev=220641root=gccview=rev Log: PR sanitizer/65019 * ubsan.c (ubsan_expand_objsize_ifn): Always return true. * g++.dg/ubsan/pr65019.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr65019.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug c/57653] [4.8/4.9 Regression] filename information discarded when using -imacros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Feb 12 09:48:56 2015 New Revision: 220642 URL: https://gcc.gnu.org/viewcvs?rev=220642root=gccview=rev Log: 2015-02-11 Richard Biener rguent...@suse.de Backport from mainline 2014-07-24 Marek Polacek pola...@redhat.com PR c/57653 * c-opts.c (c_finish_options): If -imacros is in effect, return. Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog
[Bug tree-optimization/64823] [5 Regression] false may be used uninitialized, missed jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Actually not a duplicate now that I've been able to look deeper.
[Bug tree-optimization/64705] Bad code generation of sieve on x86-64 because of too aggressive IV optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705 --- Comment #5 from amker at gcc dot gnu.org --- Author: amker Date: Fri Feb 13 05:44:46 2015 New Revision: 220676 URL: https://gcc.gnu.org/viewcvs?rev=220676root=gccview=rev Log: PR tree-optimization/64705 * tree-ssa-loop-niter.h (expand_simple_operations): New parameter. * tree-ssa-loop-niter.c (expand_simple_operations): New parameter. * tree-ssa-loop-ivopts.c (extract_single_var_from_expr): New. (find_bivs, find_givs_in_stmt_scev): Pass new argument to expand_simple_operations. testsuite PR tree-optimization/64705 * gcc.dg/tree-ssa/pr64705.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr64705.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-loop-niter.h
[Bug tree-optimization/64823] [5 Regression] false may be used uninitialized, missed jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law law at redhat dot com --- *Very* likely a duplicate of 61409 based on some initial investigations. Obviously I'll verify that as I pull together a fix for this issue. *** This bug has been marked as a duplicate of bug 61409 ***
[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||alserkli at inbox dot ru --- Comment #12 from Jeffrey A. Law law at redhat dot com --- *** Bug 64823 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #9 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #7) Vlad, What's the rationale behind the 50% probability cutoff for forming an EBB? For the purposes of inheritance, ISTM you want the biggest EBBs possible to give you a maximal window in which to find an insn to inherit from? Or is it the case that EBB formation impacts both spilling and inheritance in IRA/LRA? I remember I tried different cut-off probabilities. But LRA is changing quickly, may be it is time to check this again. I'd agree with you that for inheritance the bigger EBB, the better. But there are also optional reloads. So if we had EBB consisting of BB1 and very low probability BB2 BB1 op with pseudo spilled BB2 the spilled pseudo use optional reload and inheritance would transform it into BB1 load hr, pseudo spilled op with hr BB2 hr use With 50% cut-off we would have BB1 op with pseudo spilled BB2 the spilled pseudo use which is better code if probability BB1 BB2.
[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 --- Comment #13 from Jeffrey A. Law law at redhat dot com --- So we don't thread this case because of the limits we place on the number of statements in the duplicated block. If --param max-jump-thread-duplication-stmts=16 is added to the command line, jump threading will kick in creating the pseudo-code I posted in c#11. For reference, the default value of that param is 15. What I don't understand from c#4 is uninit can't simplify this condition: if (_35 == 4611686018595160064 (.AND.) (.NOT.) _31 != 5) is false While we may not know the full condition, does realizing that the (*.NOT.) _31 != 5 is totally pointless help?
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Feb 13 05:26:37 2015 New Revision: 220675 URL: https://gcc.gnu.org/viewcvs?rev=220675root=gccview=rev Log: PR c++/64956 * c-opts.c (c_common_post_options): Change flag_abi_version from 0 to the current highest version. * c-cppbuiltin.c (c_cpp_builtins): Assert that it isn't 0. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-cppbuiltin.c trunk/gcc/c-family/c-opts.c trunk/gcc/common.opt trunk/gcc/testsuite/g++.dg/abi/macro0.C
[Bug tree-optimization/64705] Bad code generation of sieve on x86-64 because of too aggressive IV optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705 --- Comment #6 from amker at gcc dot gnu.org --- Since it works on gcc 3.4, so I consider this as a regression and applied the patch. Should be fixed now. Hi Vlad, could you please help me verify that the original benchmark is fixed too? Thanks very much!
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822 --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Fri Feb 13 02:57:03 2015 New Revision: 220673 URL: https://gcc.gnu.org/viewcvs?rev=220673root=gccview=rev Log: 2015-02-12 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/57822 * gfortran/fmt_g0_7.f08: Adjust for archtectures with less than four different KINDs. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_g0_7.f08
[Bug rtl-optimization/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||rth at gcc dot gnu.org Resolution|--- |FIXED --- Comment #17 from Richard Henderson rth at gcc dot gnu.org --- Fixed. Thanks for the work on this one, HJ.
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #10 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #8) And for GCC 5, ISTM the question that hasn't been answered, particularly with regard to the second reproducer is whether or this is a regression for the overall performance of that code. It's certainly possible that IRA determined that %ebx was better used to hold a different value and that the PIC register might end up in a call-clobbered register. If the object in %ebx is heavily used, the benefits of keeping that value in %ebx may outweigh the cost of having the PIC value in a different register (say perhaps one that is call-clobbered). I guess it is easy to check by preventing pic pseudo generation.
[Bug rtl-optimization/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219 --- Comment #16 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Fri Feb 13 04:52:45 2015 New Revision: 220674 URL: https://gcc.gnu.org/viewcvs?rev=220674root=gccview=rev Log: PR rtl/32219 gcc/ * cgraphunit.c (cgraph_node::finalize_function): Set definition before notice_global_symbol. (varpool_node::finalize_decl): Likewise. * varasm.c (default_binds_local_p_2): Rename from default_binds_local_p_1, add weak_dominate argument. Use direct returns instead of assigning to local variable. Unify varpool and cgraph paths via symtab_node. Reject undef weak variables before testing visibility. Reorder tests for simplicity. (default_binds_local_p): Use default_binds_local_p_2. (default_binds_local_p_1): Likewise. (decl_binds_to_current_def_p): Unify varpool and cgraph paths via symtab_node. (default_elf_asm_output_external): Emit visibility when specified. gcc/testsuite/ * gcc.dg/visibility-22.c: New test. * gcc.dg/visibility-23.c: New test. * gcc.target/i386/pr32219-1.c: New test. * gcc.target/i386/pr32219-2.c: New test. * gcc.target/i386/pr32219-3.c: New test. * gcc.target/i386/pr32219-4.c: New test. * gcc.target/i386/pr32219-5.c: New test. * gcc.target/i386/pr32219-6.c: New test. * gcc.target/i386/pr32219-7.c: New test. * gcc.target/i386/pr32219-8.c: New test. * gcc.target/i386/pr64317.c: Expect GOTOFF, not GOT. Added: trunk/gcc/testsuite/gcc.dg/visibility-22.c trunk/gcc/testsuite/gcc.dg/visibility-23.c trunk/gcc/testsuite/gcc.target/i386/pr32219-1.c trunk/gcc/testsuite/gcc.target/i386/pr32219-2.c trunk/gcc/testsuite/gcc.target/i386/pr32219-3.c trunk/gcc/testsuite/gcc.target/i386/pr32219-4.c trunk/gcc/testsuite/gcc.target/i386/pr32219-5.c trunk/gcc/testsuite/gcc.target/i386/pr32219-6.c trunk/gcc/testsuite/gcc.target/i386/pr32219-7.c trunk/gcc/testsuite/gcc.target/i386/pr32219-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr64317.c trunk/gcc/varasm.c
[Bug fortran/64932] [4.9/5 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932 --- Comment #8 from Daniel Shapero shapero at uw dot edu --- Everything works now, thanks Paul!
[Bug c++/65046] New: -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046
Bug ID: 65046
Summary: -Wabi-tag doesn't warn about variables or function
return types
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ABI
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Compiling this testcase with -Wabi-tag doesn't warn about 'a' or change its
mangled name. This needs to be fixed for GCC 5.
inline namespace foo __attribute ((abi_tag)) {
struct A { };
};
A a;
