[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #15 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Apr 20 21:46:59 2015 New Revision: 49 URL: https://gcc.gnu.org/viewcvs?rev=49root=gccview=rev Log: /cp 2015-04-20 Paolo Carlini paolo.carl...@oracle.com PR c++/65801 * typeck2.c (check_narrowing): In C++11 mode too, -Wno-narrowing suppresses the diagnostic. 2015-04-20 Paolo Carlini paolo.carl...@oracle.com PR c++/65801 * doc/invoke.texi ([-Wnarrowing]): Update. /testsuite 2015-04-20 Paolo Carlini paolo.carl...@oracle.com PR c++/65801 * g++.dg/cpp0x/Wnarrowing2.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180 --- Comment #6 from boger at us dot ibm.com --- I have verified this testcase now passes on ppc64le with today's gcc-5-branch and with gcc trunk.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #13) Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1? It is IMHO too late for that, but not too late for 5.2.
[Bug other/65820] New: escape backslashes in .d file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65820 Bug ID: 65820 Summary: escape backslashes in .d file Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: paul_robinson at playstation dot sony.com gcc should escape backslashes when writing a .d file, because that's what GNU make expects. (Yes, I know special characters in filenames are a bad idea...) There are various scenarios, this one seems to be the easiest to demonstrate. $ gcc --version gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 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. $ make --version GNU Make 3.81 Copyright (C) 2006 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. This program built for x86_64-pc-linux-gnu $ cat quote.c #include a\\b.h $ # BTW that's two backslashes, not one escaped backslash; C11 6.4.7. $ touch ab.h $ gcc -c -MMD quote.c $ # But the .d file just copies the string literally. $ cat quote.d quote.o: quote.c a\\b.h $ rm ab.h $ # Make properly doesn't find the nonexistent file $ make -f quote.d quote.o make: *** No rule to make target `a\\b.h', needed by `quote.o'. Stop. $ # Accidentally create the wrong number of backslashes... $ touch a\\b.h $ # ...make will interpret a\\b.h as a\b.h, even though gcc doesn't. $ make -f quote.d quote.o cc-c -o quote.o quote.c quote.c:1:18: fatal error: a\\b.h: No such file or directory #include a\\b.h ^ compilation terminated. make: *** [quote.o] Error 1 $ If I modify the .d file to escape backslashes, it works properly. $ cat quote.d quote.o: quote.c ab.h $ touch ab.h $ ls a\\b.h quote.c quote.d $ make -f quote.d quote.o cc-c -o quote.o quote.c $
[Bug debug/65821] New: [4.8.2 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
Bug ID: 65821
Summary: [4.8.2 regression] incorrect debug line # info for
main
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: chihin.ko at oracle dot com
this happen since 4.8.2, 4.9.0 also have same problem.
cat t.cc
==
1 #include stdio.h
2
3 int b = 12;
4
5 inline void foo(const int x = (b+3))
6 {
7 printf(%d\n, x);
8 } 9
10 inline void baz(const int x = 200)
11 {
12 printf(%d\n, x);
13 }
14
15 inline void bar(int x = b)
16 { 17 printf(%d\n, x);
18 x = 100;
19 printf(%d\n, x);
20 }
21
22
23 void
24 bob(char *s = hello) 25 {
26 printf(%s\n, s);
27 } 28
29 int main()
30 {
31 foo(); 32 baz();
33 bar();
34 bob();
35 return 0;
36 }
The line table for main is incorrect:
10x067eDW_TAG_subprogram
DW_AT_external yes(1)
DW_AT_name main
DW_AT_decl_file 0x0001 t.cc
DW_AT_decl_line 0x001d
DW_AT_type 0x0491
DW_AT_low_pc0x0040129f
DW_AT_high_pc 0x004012ff
.debug_line
---
0x0040129f [ 30, 0] NS
0x004012a7 [ 5, 0] NS extra line info
0x004012b0 [ 31, 0] NS
0x004012bf [ 32, 0] NS DI=0x1
0x004012d2 [ 33, 0] NS
0x004012dc [ 34, 0] NS
This cause follwing problem:
(gdb) b main
Breakpoint 1 at 0x4006ea: file c++defargs3.cc, line 5. == should be line 31
(gdb) run
Starting program:
/workspace/chko/ws/dinstall/dbx_test/intel_S11_gcc482/c++defargs3.dbx,gcc/g47/a.out
Breakpoint 1, main () at c++defargs3.cc:5
5 inline void foo(const int x = (b+3))
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?
[Bug tree-optimization/65818] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 35371 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35371action=edit Preprocessed source
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #11) Draft patch 2 I think let's go with this. It's odd, but not complex and does what we want.
[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Blocks||37131 Severity|normal |enhancement
[Bug tree-optimization/65818] New: libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 Bug ID: 65818 Summary: libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 if [ x-fPIC != x ]; then \ /test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc / -B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-6.0/hppa2 .0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-6. 0/hppa2.0w-hp-hpux11.11/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../gc c/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototype s -pedantic -fPIC ../../gcc/libiberty/vprintf-support.c -o pic/vprintf-support. o; \ else true; fi ../../gcc/libiberty/vprintf-support.c: In function 'libiberty_vprintf_buffer_siz e': ../../gcc/libiberty/vprintf-support.c:41:1: internal compiler error: in expand_i fn_va_arg_1, at tree-stdarg.c:1095 libiberty_vprintf_buffer_size (const char *format, va_list args) ^
[Bug fortran/65819] New: overzealous checking in gfc_check_dependency for identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 Bug ID: 65819 Summary: overzealous checking in gfc_check_dependency for identical=true Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Just ran across this while trying to cook up a test case for matrix inlining. In the patch proposed for PR 37131, I have if (gfc_check_dependency (expr1, matrix_a, true) || gfc_check_dependency (expr1, matrix_b, true)) return 0; In the test case, I want to do f(3,1:eight:2,:) = matmul(f(1,1:3,2:3), f(2,2:3,:)) where clearly the lhs does not depend on the rhs. However, specifying true to gfc_dep_dependency leads to if (identical) return 1; before any checking is done. I'm not sure if there is a real-world test case yet, but there will be one soon, so I'll keep this PR as a reminder.
[Bug debug/65821] [4.8.2 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 --- Comment #2 from chihin ko chihin.ko at oracle dot com --- (In reply to Andrew Pinski from comment #1) It is doing (b+3) first which is from :5 which seems correct to me. Default arguments should have a line information right? Then gdb should stop at line 30 first and when I step into foo(), it stop at line 5. line 5 should belongs to foo(). Current behavior is confusing to user.
[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 --- Comment #5 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Tue Apr 21 05:23:08 2015 New Revision: 56 URL: https://gcc.gnu.org/viewcvs?rev=56root=gccview=rev Log: PR rtl-optimization/64916 * cfgcleanup.c (values_equal_p): New function. (can_replace_by): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c
[Bug debug/65822] New: [4.8.2 regression] Used variant fun names in dwarf info for CTORs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65822 Bug ID: 65822 Summary: [4.8.2 regression] Used variant fun names in dwarf info for CTORs Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: chihin.ko at oracle dot com Created attachment 35372 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35372action=edit test case 1/1 for attached *.cc, there are 3 A CTORS and 3 variant A CTORS: nm a.out | grep _ZN1AC 00400a8c W _ZN1AC1Ei 00400ab2 W _ZN1AC1Eifci 00400a5a W _ZN1AC1Ev 00400a8c W _ZN1AC2Ei 00400ab2 W _ZN1AC2Eifci 00400a5a W _ZN1AC2Ev In dwarf dump, _ZN1AC2... was used : grep _ZN1AC a.out.dw DW_AT_MIPS_linkage_name _ZN1AC2Ev DW_AT_MIPS_linkage_name _ZN1AC2Ei DW_AT_MIPS_linkage_name _ZN1AC2Eifci name at offset 0x011a, length9 is '_ZN1AC2Ei' name at offset 0x0143, length 12 is '_ZN1AC2Eifci' name at offset 0x015a, length9 is '_ZN1AC2Ev' I don't see _ZN1AC1... were used in a.out.dw
[Bug debug/65822] [4.8/4.9/5/6 Regression] Used variant fun names in dwarf info for CTORs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65822 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|[4.8.2 regression] Used |[4.8/4.9/5/6 Regression] |variant fun names in dwarf |Used variant fun names in |info for CTORs |dwarf info for CTORs --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- The C1 and C2 don't stand for CTORs and variant CTORs, but for complete object constructor and base object constructor. If the compiler chooses them to emit them as aliases (because they are the same), you only get one of them in the debug info, emitting both the same way would just severely bloat the debug info, unless there is a way to represent the aliases without duplication. Dunno if e.g. a DW_TAG_subprogram with DW_AT_name/DW_AT_linkage_name and just DW_AT_abstract_origin on the alias and nothing else would do the job.
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 --- Comment #3 from amker at gcc dot gnu.org --- Author: amker Date: Tue Apr 21 02:23:18 2015 New Revision: 55 URL: https://gcc.gnu.org/viewcvs?rev=55root=gccview=rev Log: PR testsuite/65767 * g++.dg/lto/pr65276_0.C: Change namespace std to std2. * g++.dg/lto/pr65276_1.C: Change namespace std to std2. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/pr65276_0.C trunk/gcc/testsuite/g++.dg/lto/pr65276_1.C
[Bug debug/65821] [4.8.2 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- It is doing (b+3) first which is from :5 which seems correct to me. Default arguments should have a line information right?
[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Fixed by Shiva's patch on the trunk.
[Bug libgomp/65814] [5/6 Regression] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65814 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 65742 ***
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- So shouldn't this be INVALID rather than NEW?
[Bug c++/65811] [6 Regression] ice in vague_linkage_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r222134.
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Can you please try to reduce it to a testcase?
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- I am using ld.bfd from binutils master branch.
[Bug testsuite/60806] libstdc++ abi check should ignore missing TLS symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60806 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #1 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Subscribing. Just spent half-a-day figuring out why I get more TLS symbols on aarch64-linux-gnu, than baseline show.
[Bug debug/65807] [5/6 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[5 Regression] ICE () on|[5/6 Regression] ICE () on |powerpc64le-linux-gnu |powerpc64le-linux-gnu --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 5.1+.
[Bug c++/65811] [6 Regression] ice in vague_linkage_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
struct foo { int i; };
static void fn1 ();
inline void
fn1 ()
{
static struct foo a[1];
}
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 20 Apr 2015, hjl.tools at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- r18 failed for me: https://gcc.gnu.org/ml/gcc-regression/2015-04/msg00231.html My GCC was configured with --prefix=/export/gnu/import/git/gcc-test-spec-lto/usr --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-multilib-list=m32,m64,mx32 --with-fpmath=sse --enable-languages=c,c++,fortran,lto Do you use gold or GNU ld (and which version)? I don't use any extra configure args for GCC and I'm using GNU ld 2.25.0 (that is, sth from the 2.25 branch)
[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 20 13:30:01 2015 New Revision: 32 URL: https://gcc.gnu.org/viewcvs?rev=32root=gccview=rev Log: PR debug/65807 * dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val.val_entry. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug libgomp/65814] New: [5/6 Regression] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65814 Bug ID: 65814 Summary: [5/6 Regression] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_dev ice-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11
[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 20 13:31:02 2015 New Revision: 33 URL: https://gcc.gnu.org/viewcvs?rev=33root=gccview=rev Log: PR debug/65807 * dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val.val_entry. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/dwarf2out.c
[Bug go/65813] New: GO: bug347.go segment violation on S390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
Bug ID: 65813
Summary: GO: bug347.go segment violation on S390x
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
With current code from gcc_5_branch, the Go test bug347.go crashes by
dereferencing a null pointer:
-- snip --
$ gdb ./bug347.x
(gdb) run
Starting program: /home/vogt/src/git/gcc/build-go/gcc/testsuite/go/bug347.x
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New Thread 0x3fffaaa5910 (LWP 47868)]
[New Thread 0x3fffbba5910 (LWP 47867)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffaaa5910 (LWP 47868)]
0x800019b8 in main.f ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
22case -t.c: // THIS IS LINE 22
(gdb) bt
#0 0x800019b8 in main.f ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
#1 0x80001a8c in main.main ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:48
(gdb) p main.t
$1 = (struct {...} *) 0x0
-- snip --
It just dumps a core file and never calls the defered function (GOTRACEBACK is
not set).
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #20 from Thomas Koenig tkoenig at gcc dot gnu.org --- First submitted patch: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00969.html
[Bug libgomp/65742] [5/6 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 65814 has been marked as a duplicate of this bug. ***
[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I don't think it is a bug. If you use -pedantic, it doesn't matter whether -std=c11 or -std=gnu11 (the default) is in effect. If you want to suppress the warning, use __extension__ as you did in the test().
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c |tree-optimization --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Looks more like a tree-optimization problem rather than C FE one.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) Created attachment 35362 [details] assembly created by r211698 The difference between the assembly created by r211652 and r211698 is the single line .stabs a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16),32,0,6,0 maybe that should have been transformed to : .stabs __emutls_v.a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16),32,0,6,0 .. or sth similar, Im a bit rusty on STABs format.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Couldn't you simply turn the error_at into pedwarn?
[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 --- Comment #59 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to vries from comment #58) Given the fix of PR64950, we should be able to remove the workaround committed for this PR. I have started bootstrap/regtest with the following revert: --cut here-- Index: config/alpha/alpha.c === --- config/alpha/alpha.c (revision 28) +++ config/alpha/alpha.c (working copy) @@ -5957,10 +5957,6 @@ alpha_build_builtin_va_list (void) integer_type_node); DECL_FIELD_CONTEXT (ofs) = record; DECL_CHAIN (ofs) = space; - /* ??? This is a hack, __offset is marked volatile to prevent - DCE that confuses stdarg optimization and results in - gcc.c-torture/execute/stdarg-1.c failure. See PR 41089. */ - TREE_THIS_VOLATILE (ofs) = 1; base = build_decl (BUILTINS_LOCATION, FIELD_DECL, get_identifier (__base), --cut here--
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- r18 failed for me: https://gcc.gnu.org/ml/gcc-regression/2015-04/msg00231.html My GCC was configured with --prefix=/export/gnu/import/git/gcc-test-spec-lto/usr --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-multilib-list=m32,m64,mx32 --with-fpmath=sse --enable-languages=c,c++,fortran,lto
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #6 from Alan Modra amodra at gmail dot com --- It isn't seen most of the time because the failure happens only when r2 isn't 16-byte aligned (50% chance) and the r2 offset to a long double constant is n*64k+32k-8 (0.012% chance per long double). libgfortran stores paths for error messages in .rodata, so source path can affect placement of those long double constants. I'm just lucky.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #40 from mwahab at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #25) Documentation needs updating for sure... The rules have changed under us since originally SEQ_CST and sync were intended to be the same thing... Guess I shouldn't have tied our horse to the C++11 cart :-) I've submitted a patch to try to update the __atomics documentation: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01025.html.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to vries from comment #6) (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: Is that always the case (try -fnon-call-exceptions)? Then doing that looks obvious. Richard. (gdb) call debug_generic_expr (*expr_p ) VA_ARG_EXPR c (gdb) call debug_tree (*expr_p ) va_arg_expr 0x7661e9a0 type pointer_type 0x764c97e0 type integer_type 0x764a7690 int public SI size integer_cst 0x764c50a8 constant 32 unit size integer_cst 0x764c50c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x764a7690 precision 32 min integer_cst 0x764c5060 -2147483648 max integer_cst 0x764c5078 2147483647 pointer_to_this pointer_type 0x764c97e0 sizes-gimplified unsigned DI size integer_cst 0x764a3e58 constant 64 unit size integer_cst 0x764a3e70 constant 8 align 64 symtab 0 alias set -1 canonical type 0x764c97e0 pointer_to_this pointer_type 0x76622540 side-effects arg 0 var_decl 0x764b0c60 c type array_type 0x764ccbd0 __builtin_va_list type record_type 0x764cc738 __va_list_tag sizes-gimplified BLK size integer_cst 0x764c5318 constant 192 unit size integer_cst 0x764c52e8 constant 24 align 64 symtab 0 alias set -1 canonical type 0x764cc888 domain integer_type 0x764cc7e0 used tree_1 decl_5 BLK file test.cc line 13 col 25 size integer_cst 0x764c5318 192 unit size integer_cst 0x764c52e8 24 align 64 context function_decl 0x766240d8 fn1 test.cc:15:32 (gdb) call tree_could_throw_p (*expr_p ) $1 = false ... I'll bootstrap and reg-test this fix.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #8 from vries at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) (In reply to vries from comment #6) (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: Is that always the case (try -fnon-call-exceptions)? Then doing that looks obvious. Richard. Yep, that's also the case with -fnon-call-exceptions: ... (gdb) call debug_generic_expr (*expr_p) VA_ARG_EXPR c (gdb) call tree_could_throw_p (*expr_p ) $1 = false (gdb) p flag_non_call_exceptions $2 = 1 ...
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- So most likely r211689 ? Can you attach assembly created by r211688 and r211689 ? Isn't this just a darwin linker bug?
[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 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 #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35363 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35363action=edit gcc5-pr65807.patch Untested obvious fix. I'd say this is safe even for 5.1 at this point. Keeping uninitialized garbage in val_entry pointer is undesirable for GC.
[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 vries at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org, ||vries at gcc dot gnu.org --- Comment #58 from vries at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #57) See also PR64950 [ Adding alpha maintainer to cc. ] Given the fix of PR64950, we should be able to remove the workaround committed for this PR.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really doesn't
have extensions to describe the TLS vars. Like:
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
if (MEM_P (home) GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
{
+ if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+return 0;
if (TREE_PUBLIC (decl))
{
int offs;
The disadvantage of doing that is that (at least on x86_64-linux with
-gstabs+), ptype a etc. will stop working, but one couldn't inspect the
variables there either, you really need DWARF for that.
p a
$3 = (struct S (*)[10]) 0x0
is of course wrong. So, I'd classify this as a buggy Apple toolchain, but the
above patch might be just ok and not really break anything anyone cares about.
[Bug middle-end/65796] unnecessary stack spills during complex numbers function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- There is some older bug where I noticed the same issue. It's basically an artifact of the x86 calling conventions and GCC going through generic argument setup code (and RTL optimizers not being able to optimize spill + load into unpcklps). That said, somebody needs to find the duplicate bugreport. PR48607 is also related.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thus what shall we do? Shall we go back to my minimal patch which only touched enums? https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00880.html
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 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 --- This changed supposedly with r138933 and from that PR20644 I think it is quite clear this is intentional. The code in foo_2 is conditional (on a condition later proved to be always true, though), so we really don't want to warn on it early, because it might be in dead code, and we don't warn for it late because it really is dead code, optimized away as nothing uses it. If you add say a global void *b; variable and change the a = a; statements to b = a;, then it will warn even when optimizing, as the code won't be dead.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 35361 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35361action=edit assembly created by r211652
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Why is this not seen on powerpc64-unknown-linux-gnu at https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02317.html?
[Bug c++/65811] [6 Regression] ice in vague_linkage_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ice in vague_linkage_p |[6 Regression] ice in ||vague_linkage_p Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 --- Comment #3 from Joe Perches joe at perches dot com --- Thank you both for your very prompt replies. It might be useful to have a -Wunused-eliminated type extra warning though that might be very noisy.
[Bug tree-optimization/65797] [5 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 35362 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35362action=edit assembly created by r211698 The difference between the assembly created by r211652 and r211698 is the single line .stabsa:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16),32,0,6,0
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #30 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 17 Apr 2015, jason at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #29 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #17) Lambda functions aren't really nested functions in the tree-nested.c sense, but still are so closely related to the functions they are nested in that IMHO it would be desirable not to split them off into separate partitions, not just temporarily for GCC 5 for debug info reasons. Agreed. decl_function_context of the lambda function should give you the containing function. As far as I understood imposing constraints like this to the partitioner is hard because either you implement the same constraints into the inliner as well or you eventually blow up partition sizes. I'm also not 100% sure the issue we hit in dwarf2out is specific to lambdas or nested functions - it might very well trigger with regular C++ classes as well, just harder to reproduce. So at least for branches I think my patch is the way to go - eventually guarded with in_lto_p (if you really insist on that...)
[Bug target/64134] (vector float){0, 0, b, a} Uses stores when it does not need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134 --- Comment #3 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Apr 20 10:29:26 2015 New Revision: 29 URL: https://gcc.gnu.org/viewcvs?rev=29root=gccview=rev Log: [AArch64] PR/64134: Make aarch64_expand_vector_init use 'ins' more often gcc/: PR target/64134 * config/aarch64/aarch64.c (aarch64_expand_vector_init): Load constant and overwrite variable parts if = 1/2 the elements are variable. gcc/testsuite/: PR target/64134 * gcc.target/aarch64/vec_init_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/vec_init_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug c/65812] New: gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Bug ID: 65812
Summary: gcc 4.9.1 doesn't warn about uninitialized variable
use declared in a switch/case statement when compiled
with -O
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe at perches dot com
Created attachment 35365
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35365action=edit
sample code
Here is a small example:
$ cat t.c
struct foo {
int bar[100];
};
void foo_1(void)
{
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];
a = a;
}
void foo_2(void)
{
int i = 1;
switch (i) {
case 1: {
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];
a = a;
break;
}
}
}
$
gcc warns properly about both foo_1 and foo_2 without -O
$ gcc -c -Wall t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
struct foo *a = array[m];
^
t.c: In function ‘foo_2’:
t.c:21:15: warning: ‘m’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
struct foo *a = array[m];
^
$
but gcc warns about foo_1 but not foo_2 with -O
$ gcc -c -Wall -O t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
struct foo *a = array[m];
^
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
The following seems to work and regtests cleanly. But I have to say I'm
somewhat dubious now about changing this at all. I suppose I should try to
compile e.g. the Linux kernel with this patch and see if anything breaks.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index ebe4c73..590e235 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7565,7 +7565,7 @@ pop_init_level (location_t loc, int implicit,
/* Silently discard empty initializations. The parser will
already have pedwarned for empty brackets. */
if (integer_zerop (constructor_unfilled_index))
-constructor_type = NULL_TREE;
+/* Do nothing. */;
else
{
gcc_assert (!TYPE_SIZE (constructor_type));
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to vries from comment #5) So the question is: should ifn_va_arg have ECF_NOTHROW? Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE. And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing: ... (gdb) call debug_generic_expr (*expr_p ) VA_ARG_EXPR c (gdb) call debug_tree (*expr_p ) va_arg_expr 0x7661e9a0 type pointer_type 0x764c97e0 type integer_type 0x764a7690 int public SI size integer_cst 0x764c50a8 constant 32 unit size integer_cst 0x764c50c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x764a7690 precision 32 min integer_cst 0x764c5060 -2147483648 max integer_cst 0x764c5078 2147483647 pointer_to_this pointer_type 0x764c97e0 sizes-gimplified unsigned DI size integer_cst 0x764a3e58 constant 64 unit size integer_cst 0x764a3e70 constant 8 align 64 symtab 0 alias set -1 canonical type 0x764c97e0 pointer_to_this pointer_type 0x76622540 side-effects arg 0 var_decl 0x764b0c60 c type array_type 0x764ccbd0 __builtin_va_list type record_type 0x764cc738 __va_list_tag sizes-gimplified BLK size integer_cst 0x764c5318 constant 192 unit size integer_cst 0x764c52e8 constant 24 align 64 symtab 0 alias set -1 canonical type 0x764cc888 domain integer_type 0x764cc7e0 used tree_1 decl_5 BLK file test.cc line 13 col 25 size integer_cst 0x764c5318 192 unit size integer_cst 0x764c52e8 24 align 64 context function_decl 0x766240d8 fn1 test.cc:15:32 (gdb) call tree_could_throw_p (*expr_p ) $1 = false ... I'll bootstrap and reg-test this fix.
[Bug rtl-optimization/65805] [5 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Target Milestone|--- |5.2 Summary|[5/6 Regression] Chromium |[5 Regression] Chromium |gets miscompiled|gets miscompiled Known to fail||5.1.0
[Bug target/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Looks like debug related (we GC walk DIEs).
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #4) On Fri, 17 Apr 2015, hjl.tools at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #2) Can't reproduce with r222165 and -O3 -funroll-loops -ffast-math. But my bug report is against -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin not -O3 -funroll-loops -ffast-math. r222168 still has the same bug. My bad - I uses -O3 -funroll-loops -ffast-math -flto=jobserver linker-plugin gets used automatically for me and -fwhole-program should be a no-op with linker-plugin. I can re-double-check that on Monday though. Works for me again.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin14.3 |*-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 Host|x86_64-apple-darwin14.3 |*-apple-darwin* Summary|FAIL: |[5/6 Regression] FAIL: |gcc.dg/debug/pr65771.c |gcc.dg/debug/pr65771.c |-gstabs+* -O* (test for |-gstabs+* -O* (test for |excess errors) |excess errors) Ever confirmed|0 |1 Build|x86_64-apple-darwin14.3 |*-apple-darwin* --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced range: no warning for r211652. Confirmed by Iain Sandoe on other darwin targets (including powerpc-apple-darwin9).
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Well, at the time I think we agreed that we wanted to be strict at least about enums... Otherwise, yes, we can do that plus setting ok = true in that case too, thus collapsing the last two ifs (+ reverting the docs change and adjusting the testsuite).
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #7 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really
doesn't have extensions to describe the TLS vars. Like:
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
if (MEM_P (home) GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
{
+ if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+return 0;
if (TREE_PUBLIC (decl))
{
int offs;
The disadvantage of doing that is that (at least on x86_64-linux with
-gstabs+), ptype a etc. will stop working, but one couldn't inspect the
variables there either, you really need DWARF for that.
p a
$3 = (struct S (*)[10]) 0x0
is of course wrong. So, I'd classify this as a buggy Apple toolchain,
there's nothing apple-specific about this - or even Darwin-specific.
The problem will exist for all the toolchains that use emutls (*iff* they are
interested in STABs debug).
AFAICT ld64 just detected an inconsistency that has gone un-noticed elsewhere,
if that's really a ld64 bug we should file it…
OTOH, I agree that there's probably little interest in STABs - even on Darwin
it's only relevant for the most ancient system on the horizon.
the above patch might be just ok and not really break anything anyone cares
about.
let's test that out.
[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|target |debug Target Milestone|5.2 |5.0
[Bug c++/65811] New: ice in vague_linkage_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811 Bug ID: 65811 Summary: ice in vague_linkage_p Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 35364 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35364action=edit gzipped C++ source code The attached code, when compiled by gcc trunk dated 20150418, does this xcsv_tokens.in: In function ‘xt_mapping* in_word_set(const char*, unsigned int)’ : xcsv_tokens.in:28:5: internal compiler error: in vague_linkage_p, at cp/decl2.c: 1866 0x703cde vague_linkage_p(tree_node*) ../../src/trunk/gcc/cp/decl2.c:1866 0x63230c maybe_commonize_var(tree_node*) ../../src/trunk/gcc/cp/decl.c:5200 0x65fff5 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../src/trunk/gcc/cp/decl.c:6692 0x750d6e cp_parser_init_declarator ../../src/trunk/gcc/cp/parser.c:17280
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This is because at the point where we warn we don't know that the code is executed unconditionally and with optimization we don't warn about maybe-uninitialized uses early. Late we have removed all code as dead and thus do not warn either. I'd say it works as intended (even though surprising).
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #8 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #7)
(In reply to Jakub Jelinek from comment #6)
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
if (MEM_P (home) GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
{
+ if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+return 0;
if (TREE_PUBLIC (decl))
{
int offs;
hmm .. not as things stand ..
(gdb) p debug_rtx(home)
(mem/c:BLK (symbol_ref:SI (__emutls_v.a) [flags 0x1402] var_decl 0x14260ed80
__emutls_v.a) [0 __emutls_v.a+0 S16 A32])
(flags [5:3] contain the tls model which is 0 == TLS_MODEL_NONE in the case
above).
Current language: auto; currently c++
(gdb) p debug_tree(decl)
var_decl 0x14260e990 a
type array_type 0x14271d888
type record_type 0x14271d738 S type_0 DI
size integer_cst 0x142601d20 constant 64
unit size integer_cst 0x142601d38 constant 8
align 32 symtab 18 alias set -1 canonical type 0x14271d738 fields
field_decl 0x142626980 s context translation_unit_decl 0x1424cf258 D.1823
pointer_to_this pointer_type 0x14271d930 chain type_decl
0x1426268e8 D.1815
BLK
size integer_cst 0x14261d300 constant 640
unit size integer_cst 0x142712870 constant 80
align 32 symtab 0 alias set -1 canonical type 0x14271d888
domain integer_type 0x14271d7e0 type integer_type 0x1426050a8
sizetype
SI
size integer_cst 0x142601cc0 constant 32
unit size integer_cst 0x142601cd8 constant 4
align 32 symtab 0 alias set -1 canonical type 0x14271d7e0 precision
32 min integer_cst 0x142601cf0 0 max integer_cst 0x142712810 9
addressable used public static BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
integer_cst 0x14261d300 640 unit size integer_cst 0x142712870 80
align 32 context translation_unit_decl 0x1424cf258 D.1823
value-expr var_decl 0x14260ed80 __emutls_v.a
type record_type 0x14271dd20 __emutls_object BLK
size integer_cst 0x14261d030 constant 128
unit size integer_cst 0x14261d048 constant 16
align 32 symtab 0 alias set -1 canonical type 0x14271dd20 fields
field_decl 0x142626c78 __size
asm_written used public static ignored BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
integer_cst 0x14261d030 128 unit size integer_cst 0x14261d048 16
align 32 context translation_unit_decl 0x1424cf258 D.1823 initial
constructor 0x1427129a8
(mem/c:BLK (symbol_ref:SI (__emutls_v.a) [flags 0x1402] var_decl
0x14260ed80 __emutls_v.a) [0 __emutls_v.a+0 S16 A32]) chain var_decl
0x14260ea20 b
(gdb) p decl-decl_common.ignored_flag
$3 = 0
(gdb) p decl_tls_model(decl)
$4 = TLS_MODEL_NONE
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Yes, I was thinking that in such cases clang does something we don't normally do (ie, an hard error by default suppressible with a -Wno-*). Let me see if we can achieve that as you suggested.
[Bug tree-optimization/65752] Too strong optimizations int - pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #12 from Robbert gcc at robbertkrebbers dot nl --- (In reply to Richard Biener from comment #10) and see how this will make PTA useless (all pointers passed to a function whose result might be used in a way to take advantage of an equality relation need to be considered pointing to anything). [and then thorougly specify take advantage of an equality relation] That is undesired indeed. Only in case a pointer has been obtained via a construction that breaks abstraction (for example, if it has been obtained via an int - pointer casts, or by poking bytes somewhere and then reinterpreting these as a pointer) convervative PTA assumptions should be made.
[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808 --- Comment #2 from David L. equinox-gccbugs at diac24 dot net --- (In reply to Marek Polacek from comment #1) I don't think it is a bug. If you use -pedantic, it doesn't matter whether -std=c11 or -std=gnu11 (the default) is in effect. If you want to suppress the warning, use __extension__ as you did in the test(). Hm. It doesn't seem to produce a warning for the system's/glibc's wait() definition, even though there is no __extension__ on that. I guess that's special-handling for system headers(?) (Either way our target language is C with gcc/clang/icc common extensions, so I guess -pedantic is not appropriate...)
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) Then perhaps one needs to check TREE_CODE (decl) == VAR_DECL (TREE_STATIC (decl) || DECL_EXTERNAL (decl)) decl_tls_model (decl) != TLS_MODEL_NONE instead. except for: (gdb) p decl_tls_model(decl) $4 = TLS_MODEL_NONE which doesn't seem right .. but haven't got a chance to debug further right now.
[Bug c++/65815] New: std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Bug ID: 65815
Summary: std::array initialization with initializer list: a =
{x,y,z} incorrectly flagged as syntax error
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andras.aszodi at csf dot ac.at
On Page 975 of The C++ Programming Language, 4th edition, Bjarne Stroustrup
says:
An array can be initialized by an initializer list:
arrayint,3 a1 = { 1, 2, 3 };
and Clang (V 3.5) accepts it. However, G++ 4.9.2 thinks this is an error:
error: array must be initialized with a brace-enclosed initializer
const std::arraydouble, 3 _ar0val = {1.0, -1.0, 1.0};
The ugly fix is:
#ifdef __GNUC__
const std::arraydouble, 3 _ar0val{{1.0, -1.0, 1.0}};
#else
const std::arraydouble, 3 _ar0val = {1.0, -1.0, 1.0};
#endif
but of course it is still a bug.
[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to David L. from comment #2) Hm. It doesn't seem to produce a warning for the system's/glibc's wait() definition, even though there is no __extension__ on that. I guess that's special-handling for system headers(?) Yes, likely: if you put the declarations in your test case into a header file along with #pragma GCC system_header, you won't see any warnings. I'm marking this as resolved. If anyone thinks I'm wrong, please reopen.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #5) Well, at the time I think we agreed that we wanted to be strict at least about enums... Otherwise, yes, we can do that plus setting ok = true in that case too, thus collapsing the last two ifs (+ reverting the docs change and adjusting the testsuite). I think that for constants, we want it to be an error without -Wno-narrowing. I wonder if the best way to get that is to set pedantic_errors around the pedwarn call?
[Bug c/64918] invalid (?) warning when initializing structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64918 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Could be fixed with adding -Woverride-init-side-effects, but not sure if it's worth it.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Then perhaps one needs to check TREE_CODE (decl) == VAR_DECL (TREE_STATIC (decl) || DECL_EXTERNAL (decl)) decl_tls_model (decl) != TLS_MODEL_NONE instead.
[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Sure.
[Bug c++/65681] [c++-concepts] spurious ambiguous template instantiation error; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681 --- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com --- This is a good one. It is a regression, but it didn't have to do with the resolution of partial specializations. The substitution into requires-expressions was too eagerly doing full semantic on analysis on simple and compound requirements, and that was causing a later constraint check for a member function to fail unexpectedly. Substituting a concrete type (say, MA2) into the constraint !CA2MA2 is generating a requirement for the expression t.MA2::mf(). When we go to check that letter, we perform another substitution with the expectation that, in this case, the result would be identical to the original since it's already been resolved. However, the substitution actually rebuilds the call expression and tries to resolve it as MA2::mf(t), which fails. Anyways, this is resolved by deferring all semantic analysis to constraint checking, and not allowing it to happen when we substitute into requirements. Fixed in r36.
[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65732 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- _ZN23Parma_Polyhedra_Library9OR_MatrixINS_14Checked_NumberI10__gmp_exprIA1_12__mpz_structS4_ENS_26WRD_Extended_Number_Policy16any_row_iteratorIKS7_EpLImEENS_9Enable_IfIXgtcvT_ngLi1ELi0EERSB_E4typeESE_ _ZN2kjmlIllNS_1_15NanosecondLabelEEENS_8QuantityIDTmlcvT_Li1EcvT0_Li1EET1_EES4_NS3_IS5_S7_EE
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-20 Ever confirmed|0 |1
[Bug tree-optimization/65658] Jump threading too pessimistic when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65658 --- Comment #2 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Mon Apr 20 17:13:52 2015 New Revision: 42 URL: https://gcc.gnu.org/viewcvs?rev=42root=gccview=rev Log: PR tree-optimization/65658 * tree-ssa-threadupdate.c (redirection_block_p): Ignore clobber statements too. PR tree-optimization/65658 * gcc.dg/pr65658.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65658.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 35366 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35366action=edit A testcase [hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase gamess.ltrans29 -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip gamess.ltrans29.ltrans.o -O3 -O3 -version -fno-math-errno -fno-signed-zeros -fno-trapping-math -fno-trapv -fno-openmp -fno-openacc -funroll-loops -ffast-math -fwhole-program -fuse-linker-plugin -fltrans gamess.ltrans29.o -o gamess.ltrans29.s GNU GIMPLE (GCC) version 6.0.0 20150420 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 6.0.0 20150420 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 cisgrd.fppized.f: In function ‘cisao’: cisgrd.fppized.f:319:0: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:524 0xd98eff set_lattice_value /export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:524 0xd9fd16 visit_assignment /export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2272 0xd9ff1d ccp_visit_stmt /export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2341 0xe43186 simulate_stmt /export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:348 0xe435c6 process_ssa_edge_worklist /export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:462 0xe449dd ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**, tree_node**), ssa_prop_result (*)(gphi*)) /export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:936 0xda00b5 do_ssa_ccp /export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2387 0xda016e execute /export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2420 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.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #41 from mwahab at gcc dot gnu.org --- (In reply to torvald from comment #38) (In reply to Andrew Macleod from comment #34) Also, if you look at the IA-64 __sync_lock_release vs. GCC docs' __sync_lock_release, the latter is like x86/TSO. Do you have any info on which other semantics __sync was supposed to adhere to? One potential way to solve it would be to just require code that uses __sync to more or less implement an IA-64 or x86 memory model, modulo allowing compiler-reordering and optimization between adjacent non-__sync memory accesses. This could be inefficient on ARM (see James' examples) and perhaps Power too (or not -- see Jakub's comments). If the __sync barriers are as described in the GCC manual, that a barrier is atomic and its restrictions apply to all data references, then the Aarch64 backend doesn't currently emit strong enough barriers. For MEMMODEL_SEQ_CST, the problem was visible enough and the solution I suggested (extending the set of available memmodel types) was simple enough that the changes it would need could be justified. I don't think that's true for the MEMMODEL_ACQUIRE case which seems to be much less likely to be seen and would be rather more disruptive. I believe that Aarch64 is the only current target where the code needs to be strengthened. Since extending the set of memmodels is difficult to justify and (IMO) so is resurrecting the __sync patterns, I suggest just adding a target hook to allow the expansion of __sync calls to be overridden. That will allow Aarch64 to set a target-specific memmodel value, as is currently allowed, which can then be passed through the existing __atomics mechanisms in the middle through to the Aarch64 backend. No other backend will need to be touched. If it happens that future architectures have a similar problem then we can reconsider whether any changes need to be made in the target-independent expansions. Does that sounds like a reasonable approach?
[Bug go/65813] GO: bug347.go segment violation on S390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- I think you know this, but to be clear, the test is supposed to dereference a null pointer, and then it's supposed to recover from the run time panic. The program should unwind the stack for the signal and call __go_check_defer which should invoke the deferred function. Can you find out where that process is going awry? If the recover* tests pass, then this test ought to pass, or at least it ought not to fail in this way.
[Bug go/65813] GO: bug347.go segment violation on S390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813 Dominik Vogt vogt at linux dot vnet.ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Sorry, this turned out to be the same problem we had with Glibc a while ago. Somehow the broken Glibc had been reactivated. Not a Go or Gcc problem.
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-04-20 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Works for me, please provide a complete testcase and your exact g++ command. https://gcc.gnu.org/bugs/
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Created attachment 35367 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35367action=edit Draft patch
[Bug c/65606] Internal compiler error in linux-next 2015-03-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65606 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming.
[Bug c++/65816] New: Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
Bug ID: 65816
Summary: Constructor delegation does not perform
zero-initialization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dyp-cpp at gmx dot net
In the following program, I expect the object `t` to be zero-initialized via
constructor delegation. Clang++ does this, but g++ 6.0 2015-04-20 does not.
-
struct test
{
int m;
test() = default;
test(int) : test() {}
};
#include iostream
int main()
{
test t(0);
std::cout t.m;
}
-
While C++14 IS [class.base.init]p6 is unclear about this, as far as I can tell,
paragraph 7 implies (in the parenthesized clause) that the constructor
`test(int)` is required to value-initialize the object:
The expression-list or braced-init-list in a mem-initializer is used to
initialize the designated subobject (or, in the case of a delegating
constructor, the complete class object) according to the initialization rules
of 8.5 for direct-initialization.
The class `test` does not have a user-provided default constructor, hence
zero-initialization should be performed as per [dcl.init]p8.2
[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
Hm? This compiles just fine for me:
#include array
const std::arraydouble, 3 q1 = {1.0, -1.0, 1.0};
const std::arraydouble, 3 q2{{1.0, -1.0, 1.0}};
So can you provide a complete test case?
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, as far as I can see *nowhere* else in the compiler we fiddle with flag_pedantic_errors, all the tweaks I tried look super hackish to me :( If we are Ok with just going back to pedwarns the attached passes testing...
[Bug plugins/65817] New: libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Bug ID: 65817
Summary: libcc1: ICE: SEGV: c_incomplete_type_error()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
r30
Current libcc1 uses just: make_node (RECORD_TYPE)
which crashes on:
if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
as TYPE_NAME (type) == NULL .
Actual:
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_PRE_GENERICIZE| libcc1plugin
PLUGIN_GGC_MARKING | libcc1plugin
PLUGIN_PRAGMAS | libcc1plugin
gdb command line:1:1: internal compiler error: Segmentation fault
0xb1c4af crash_signal
../../gccgitatsign/gcc/toplev.c:383
0x618794 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:282
0x623750 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:235
0x623750 build_component_ref(unsigned int, tree_node*, tree_node*)
../../gccgitatsign/gcc/c/c-typeck.c:2304
0x654fb3 c_parser_postfix_expression_after_primary
../../gccgitatsign/gcc/c/c-parser.c:7925
0x6478f6 c_parser_postfix_expression
../../gccgitatsign/gcc/c/c-parser.c:7715
0x649f5a c_parser_unary_expression
../../gccgitatsign/gcc/c/c-parser.c:6602
0x65122f c_parser_cast_expression
../../gccgitatsign/gcc/c/c-parser.c:6440
0x651412 c_parser_binary_expression
../../gccgitatsign/gcc/c/c-parser.c:6255
0x651f75 c_parser_conditional_expression
../../gccgitatsign/gcc/c/c-parser.c:6031
0x652560 c_parser_expr_no_commas
../../gccgitatsign/gcc/c/c-parser.c:5949
0x652c52 c_parser_expression
../../gccgitatsign/gcc/c/c-parser.c:8022
0x653689 c_parser_expression_conv
../../gccgitatsign/gcc/c/c-parser.c:8055
0x661978 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:5115
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x661a67 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:4964
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x65fc80 c_parser_declaration_or_fndef
../../gccgitatsign/gcc/c/c-parser.c:1982
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.
Compilation failed.
Expected:
gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’
1586c8fbaf0116931ffacd1746a6540c81c2d438 GDB commit
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35368
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35368action=edit
GDB patch
GDB patch to crash GCC.
together with:
cat 1.c EOH
// b tree.c:build_qualified_type
// p TYPE_SIZE (type)
volatile struct sv { volatile struct sv *p; } sv; // CRASH: compile code sv.p =
sv;
volatile struct s { int i; } s, *sp; // OK: compile code sp = s;
int main(void) { return 0; }
EOH
gcc -o 1 1.c -Wall -g;noGDBHOOK=1
PATH=/home/jkratoch/redhat/gccgitatsign-root/bin:$PATH
LD_LIBRARY_PATH=/home/jkratoch/redhat/gccgitatsign-root/lib64 ../gdb ./1 -ex
start -ex 'set debug compile 0' -ex 'compile code sv.p = sv;printf(%p
%p\n,sv,sv.p);'
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35369
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35369action=edit
Attempted GCC fix.
With this GCC fix and the GDB reproducer it looks as fixed:
gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’
But after running gdb.compile/compile.exp one gets another crash so this GCC
fix is probably not right.
compile code struct_object.selffield = struct_object^M
gdb command line:1:1: error: cannot convert gdb type to gcc type^M
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.^M
Event| Plugins^M
PLUGIN_PRE_GENERICIZE| libcc1plugin^M
PLUGIN_GGC_MARKING | libcc1plugin^M
PLUGIN_PRAGMAS | libcc1plugin^M
gdb command line:1:1: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in plugin_build_add_field, at
libcc1/plugin.cc:533^M
0xd7d007 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)^M
../../gccgitatsign/gcc/tree.c:9350^M
0x7f61d20f1084 tree_class_check(tree_node*, tree_code_class, char const*, int,
char const*)^M
../../gccgitatsign/libcc1/../gcc/tree.h:2969^M
0x7f61d20ef461 plugin_build_add_field(cc1_plugin::connection*, unsigned long
long, char const*, unsigned long long, unsigned long, unsigned long)^M
../../gccgitatsign/libcc1/plugin.cc:533^M
0x7f61d20f6407 cc1_plugin::connection::do_wait(bool)^M
../../gccgitatsign/libcc1/connection.cc:144^M
0x7f61d20f12be cc1_plugin::connection::wait_for_result()^M
../../gccgitatsign/libcc1/connection.hh:72^M
0x7f61d20f1edd cc1_plugin::status cc1_plugin::callint, gcc_c_oracle_request,
char const*(cc1_plugin::connection*, char const*, int*, gcc_c_oracle_request,
char const*)^M
../../gccgitatsign/libcc1/rpc.hh:227^M
0x7f61d20ee778 plugin_binding_oracle^M
../../gccgitatsign/libcc1/plugin.cc:278^M
0x5fe398 i_symbol_binding^M
../../gccgitatsign/gcc/c/c-decl.c:268^M
0x5fe398 lookup_name(tree_node*)^M
../../gccgitatsign/gcc/c/c-decl.c:3896^M
0x645e44 c_lex_one_token^M
../../gccgitatsign/gcc/c/c-parser.c:363^M
0x663633 c_parser_peek_token^M
../../gccgitatsign/gcc/c/c-parser.c:440^M
0x663633 c_parser_next_token_is^M
../../gccgitatsign/gcc/c/c-parser.c:452^M
0x663633 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4557^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x661a67 c_parser_statement_after_labels^M
../../gccgitatsign/gcc/c/c-parser.c:4964^M
0x663173 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4701^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x65fc80 c_parser_declaration_or_fndef^M
../../gccgitatsign/gcc/c/c-parser.c:1982^M
0x669a97 c_parser_external_declaration^M
../../gccgitatsign/gcc/c/c-parser.c:1452^M
0x66a359 c_parser_translation_unit^M
../../gccgitatsign/gcc/c/c-parser.c:1339^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
Compilation failed.^M
(gdb) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield =
struct_object
BTW the GDB patch is wrong, it is used only as a reproducer of the GCC crash.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com --- Created attachment 35370 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35370action=edit Draft patch 2
