[Bug gcov-profile/71672] New: inlining indirect calls does not work with autofdo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672 Bug ID: 71672 Summary: inlining indirect calls does not work with autofdo Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Target Milestone: --- The current mainline version of autofdo doesn't inline indirect calls based on profiling data. I instrumented a bootstrap and it never triggers. gcc.dg/tree-prof/indir-call-prof.c also fails (needs the patch kit in https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01786.html applied first). I did some debugging and it seems to give up in update_inlined_ind_target() here 772 /* Program behavior changed, original promoted (and inlined) target is not 773 hot any more. Will avoid promote the original target. 774 775 To check if original promoted target is still hot, we check the total 776 count of the unpromoted targets (stored in old_info). If it is no less 777 than half of the callsite count (stored in INFO), the original promoted 778 target is considered not hot any more. */ 779 if (total >= info->count / 2) but even with the test commented out it doesn't work.
[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 --- Comment #3 from vineeshvs --- (In reply to vineeshvs from comment #2) > (In reply to Andrew Pinski from comment #1) > > >g++: internal compiler error: Killed (program cc1plus) > > > > How much RAM do you have? What target is this on? > > RAM: 3.7 GiB > > - > -- > > Processor: Intel® Core™ i5-3550 CPU @ 3.30GHz × 4 > Graphics: Intel® Ivybridge Desktop > OS Type: 64-bit > Disk: 272 GB > > - > -- > > $ uname -a > > Linux tinyCodes 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > > - > -- Below are my GCC and G++ versions gcc (Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413 g++ (Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413
[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 --- Comment #2 from vineeshvs --- (In reply to Andrew Pinski from comment #1) > >g++: internal compiler error: Killed (program cc1plus) > > How much RAM do you have? What target is this on? RAM: 3.7 GiB --- Processor: Intel® Core™ i5-3550 CPU @ 3.30GHz × 4 Graphics: Intel® Ivybridge Desktop OS Type: 64-bit Disk: 272 GB --- $ uname -a Linux tinyCodes 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ---
[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 Andrew Pinski changed: What|Removed |Added Keywords||memory-hog Severity|major |normal --- Comment #1 from Andrew Pinski --- >g++: internal compiler error: Killed (program cc1plus) How much RAM do you have? What target is this on?
[Bug c++/71671] New: g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 Bug ID: 71671 Summary: g++: internal compiler error: Killed (program cc1plus) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shopping_vineeshvs at outlook dot com Target Milestone: --- Created attachment 38771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38771&action=edit The error log from terminal Gets the following error on installing Pythong Graph tool - make[4]: Entering directory '/home/vineeshvs/software/graph-tool-2.16/src/graph/inference' CXX cache.lo CXX graph_blockmodel.lo g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Makefile:604: recipe for target 'graph_blockmodel.lo' failed make[4]: *** [graph_blockmodel.lo] Error 1 make[4]: Leaving directory '/home/vineeshvs/software/graph-tool-2.16/src/graph/inference' Makefile:738: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/vineeshvs/software/graph-tool-2.16/src/graph' Makefile:412: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/vineeshvs/software/graph-tool-2.16/src' Makefile:584: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/vineeshvs/software/graph-tool-2.16' Makefile:471: recipe for target 'all' failed make: *** [all] Error 2
[Bug target/71670] powerpc64le ICE in extract_constrain_insn with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71670 --- Comment #1 from Segher Boessenkool --- I have a fix.
[Bug c/70924] Wrong position for "warning: missing braces around initializer [-Wmissing-braces]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70924
Zhendong Su changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #1 from Zhendong Su ---
Here is another test pinpointing the same issue:
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160626 (experimental) [trunk revision 237789] (GCC)
$
$ gcc-trunk -c -Wmissing-braces check.c
check.c:1:15: warning: missing braces around initializer [-Wmissing-braces]
int a[3][1] = { { 0 }, { 1 }, 2 };
^
check.c:1:15: note: (near initialization for ‘a’)
$
$ clang -c -Wmissing-braces check.c
check.c:1:31: warning: suggest braces around initialization of subobject
[-Wmissing-braces]
int a[3][1] = { { 0 }, { 1 }, 2 };
^
{}
1 warning generated.
$
$ cat check.c
int a[3][1] = { { 0 }, { 1 }, 2 };
[Bug target/71670] New: powerpc64le ICE in extract_constrain_insn with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71670
Bug ID: 71670
Summary: powerpc64le ICE in extract_constrain_insn with
-mcpu=power9
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
The following testcase:
volatile int a;
int b;
void fn1(void) { b + (long)b || a; }
hits an ICE when built with:
# gcc -O1 -mcpu=power9 testcase.c
testcase.c: In function ‘fn1’:
testcase.c:3:1: error: insn does not satisfy its constraints:
void fn1(void) { b + (long)b || a; }
^~~~
(insn 24 23 9 2 (parallel [
(set (reg:CC 68 0 [162])
(compare:CC (ashift:DI (sign_extend:DI (reg:SI 10 10))
(const_int 1 [0x1]))
(const_int 0 [0])))
(clobber (scratch:DI))
]) testcase.c:3 260 {ashdi3_extswsli_dot}
(expr_list:REG_DEAD (reg:SI 10 10)
(nil)))
testcase.c:3:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211
0x108329d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x10832a2b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:119
0x107f8797 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2211
0x107fd89f copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.c:774
0x107fe8b7 execute
../../gcc/gcc/regcprop.c:1280
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 --- Comment #9 from BillyBarty --- (In reply to Benda Xu from comment #8) > (In reply to BillyBarty from comment #7) > > I was having this same issue building gcc 5.2.0 on my Raspberry Pi 3. > > Thank you for your report. Is your Raspberry Pi 3 running aarch64 (arm64) > or arm (32 bit)? Well, since I haven't done anything special with the OS installation (I just followed the "Getting Started" instructions that came in the box to load Raspbian), I believe that I am running arm (32 bit).
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 --- Comment #8 from Benda Xu --- (In reply to BillyBarty from comment #7) > I was having this same issue building gcc 5.2.0 on my Raspberry Pi 3. Thank you for your report. Is your Raspberry Pi 3 running aarch64 (arm64) or arm (32 bit)?
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 Uroš Bizjak changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #9 from Uroš Bizjak --- Suspended until the infrastructure is ready.
[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 Uroš Bizjak changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from Uroš Bizjak --- Suspended until the infrastructure is ready.
[Bug target/71453] Spills to vector registers are sub-optimal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71453 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #4 from Uroš Bizjak --- Suspended until the infrastructure is ready.
[Bug target/71555] [7 Regression] ICE: compilation "never" finishes with -O -mtune=sandybridge -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71555 Uroš Bizjak changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from Uroš Bizjak --- Suspended until the infrastructure is ready.
[Bug rtl-optimization/70902] [7 Regression] GCC freezes while compiling for 'skylake-avx512' target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 Uroš Bizjak changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #5 from Uroš Bizjak --- Suspended until the infrastructure is ready.
[Bug target/71555] [7 Regression] ICE: compilation "never" finishes with -O -mtune=sandybridge -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71555 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jun 26 20:56:34 2016 New Revision: 237792 URL: https://gcc.gnu.org/viewcvs?rev=237792&root=gcc&view=rev Log: PR target/70902 PR target/71453 PR target/71555 PR target/71596 PR target/71657 * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition. (ix86_spill_class): Disable to always return NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jun 26 20:56:34 2016 New Revision: 237792 URL: https://gcc.gnu.org/viewcvs?rev=237792&root=gcc&view=rev Log: PR target/70902 PR target/71453 PR target/71555 PR target/71596 PR target/71657 * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition. (ix86_spill_class): Disable to always return NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/71453] Spills to vector registers are sub-optimal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71453 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jun 26 20:56:34 2016 New Revision: 237792 URL: https://gcc.gnu.org/viewcvs?rev=237792&root=gcc&view=rev Log: PR target/70902 PR target/71453 PR target/71555 PR target/71596 PR target/71657 * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition. (ix86_spill_class): Disable to always return NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jun 26 20:56:34 2016 New Revision: 237792 URL: https://gcc.gnu.org/viewcvs?rev=237792&root=gcc&view=rev Log: PR target/70902 PR target/71453 PR target/71555 PR target/71596 PR target/71657 * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition. (ix86_spill_class): Disable to always return NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug rtl-optimization/70902] [7 Regression] GCC freezes while compiling for 'skylake-avx512' target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jun 26 20:56:34 2016 New Revision: 237792 URL: https://gcc.gnu.org/viewcvs?rev=237792&root=gcc&view=rev Log: PR target/70902 PR target/71453 PR target/71555 PR target/71596 PR target/71657 * config/i386/i386.c (TARGET_SPILL_CLASS): #if 0 out the definition. (ix86_spill_class): Disable to always return NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak --- This is another manifestation of spills to vec register problems. [uros@localhost test]/ssd/uros/gcc-build-fast/gcc/cc1plus -O3 -quiet -mtune=core2 crash_main.ii [uros@localhost test]$ g++ crash_init.s crash_main.s [uros@localhost test]$ ./a.out terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 13673958) >= this->size() (which is 38) Aborted (core dumped) [uros@localhost test]$ /ssd/uros/gcc-build-fast/gcc/cc1plus -O3 -quiet -mtune=core2 -mtune-ctrl=^general_regs_sse_spill crash_main.ii [uros@localhost test]$ g++ crash_init.s crash_main.s [uros@localhost test]$ ./a.out The asm code in question is: ... movl32(%rsp), %eax subl$38, %eax movd%eax, %xmm0<- spill to vec .L29: cmpl8(%rsp), %r10d jge .L19 movl%r10d, %ebp subl28(%rsp), %ebp movd%xmm0, %eax<- fill from vec xorl%r8d, %r8d movl8(%rsp), %r14d leal(%rax,%r10), %r15d leal-6(%r10), %r12d movslq %r15d, %r15 leaq(%r15,%r15,2), %r11 movslq %ebp, %rbp leaq0(%rbp,%rbp,2), %rbx salq$3, %r11 subl%r10d, %r14d salq$3, %rbx .p2align 4,,10 .p2align 3 .L24: testl %esi, %esi jle .L27 movqv0(%rip), %rdx movqv0+8(%rip), %rax subq%rdx, %rax sarq$3, %rax imulq %r9, %rax cmpq%rbp, %rax jbe .L25 leal(%r12,%r8), %ecx addq%rbx, %rdx movq(%rdx), %rax movslq %ecx, %rcx movq8(%rdx), %rdi leaq(%rcx,%rcx,2), %rcx movslq %r8d, %rdx subq%rax, %rdi addq%r11, %rax sarq$3, %rdi movq%rax, %xmm0 <- *clobbering* spill to vec! imulq %r9, %rdi leaq64(%rsp), %rax addq%rax, %rcx cmpq%rdi, %r15 jnb .L26 movq%xmm0, %rax <- fill from the above spill movq(%rax), %rax movzbl (%rax,%rdx,8), %edi xorl%eax, %eax .p2align 4,,10 .p2align 3 .L28: movl%edi, %edx subb(%rcx,%rax), %dl movb%dl, 0(%r13,%rax) addq$1, %rax cmpl%eax, %esi jg .L28 .L27: addl$1, %r8d cmpl%r14d, %r8d jne .L24 .L19: addl$2, 8(%rsp) addl$2, %r10d cmpl16(%rsp), %r10d jle .L29 ...
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #6 from Jonathan Wakely --- The code is not readable. Where do you initialise v13? This is not reasonable code.
[Bug debug/71668] certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- See https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00074.html .
[Bug debug/71669] DW_AT_data_bit_offset is not emitted for dwarf4 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71669 --- Comment #1 from Andrew Pinski --- Note GDB does not support it yet: https://sourceware.org/bugzilla/show_bug.cgi?id=12616
[Bug debug/71669] New: DW_AT_data_bit_offset is not emitted for dwarf4 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71669 Bug ID: 71669 Summary: DW_AT_data_bit_offset is not emitted for dwarf4 and above Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- http://www.dwarfstd.org/ShowIssue.php?issue=081130.1 Due to the no so nice parts of DW_AT_bit_offset for little-endian, the dwarf standard come up with DW_AT_data_bit_offset to fix that. DW_AT_bit_offset has been deprecated for dwarf4.
[Bug debug/71668] certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 --- Comment #3 from Andrew Pinski --- bug 71669 for using DW_AT_data_bit_offset .
[Bug debug/71668] certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Is this on a little-endian or big-endian target? It is little-endian. Note that dwarf issues explains this fully. Basically DW_AT_bit_offset is defined nicely for big-endian but not nice for little-endian. GCC does not emit DW_AT_data_bit_offset yet; I will file a bug report about that in a second.
[Bug debug/71668] certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 --- Comment #1 from Andrew Pinski --- Is this on a little-endian or big-endian target? Read http://www.dwarfstd.org/ShowIssue.php?issue=081130.1 on why DW_AT_bit_offset is deprecated in DWARF Version 4.
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 Aliaksei Kandratsenka changed: What|Removed |Added CC||alkondratenko at gmail dot com --- Comment #10 from Aliaksei Kandratsenka --- There is similar issue with bsr and __builtin_clz. Looks like for __builtin_clz gcc does 31 - . And 31 - __builtin_clz does gets compiled optimized to plain bsr, but only under --march=haswell or later amd cpus. Under earlier cpus it generates 2 redundant 31 - arg computations. This is easy to play with at: https://godbolt.org/g/o7gNSS Clang-en doesn't have that same problem (but they have another. Under -march=haswell they sometimes too strongly prefer lzcnt which returns different result and thus requires extra computation).
[Bug debug/71668] New: certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 Bug ID: 71668 Summary: certain bitfields get negative DW_AT_bit_offset Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: richlowe at richlowe dot net Target Milestone: --- Created attachment 38770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38770&action=edit test case source The DWARF for certain structures, at least when using -gdwarf-2, seems to emit with a signed, negative, bitoffset. I'm not sure whether that's valid, but it's causing some of our tools to choke and since it seems to happen in such a narrow range of circumstances it seems to be, at the least, suspicious. The DWARF standards seem to have little to say on the matter. It appears to happen when a bitfield structure is between 33 and 39 bits in size, and at no other time I've been able to determine (a large source tree contains only a single instance of the problem, from which this test case was reduced). Perhaps something is off-by-one on the number of bytes somewhere? My apologies if this behaviour is correct. I'm attaching a test file, the following diff shows the dwarfdump between a good and bad sized version of the bitfield: --- good.dwarf 2016-06-26 18:40:52.582216186 +0100 +++ bad.dwarf 2016-06-26 18:41:09.862679856 +0100 @@ -23,8 +23,8 @@ DW_AT_decl_line 0x0004 DW_AT_type <0x0050> DW_AT_byte_size 0x0004 -DW_AT_bit_size 0x0008 -DW_AT_bit_offset0x0018 +DW_AT_bit_size 0x0007 +DW_AT_bit_offset0x0019 DW_AT_data_member_location DW_OP_plus_uconst 0 < 2><0x003e> DW_TAG_member DW_AT_name "csts_cfs" @@ -33,8 +33,8 @@ DW_AT_type <0x0050> DW_AT_byte_size 0x0004 DW_AT_bit_size 0x0020 -DW_AT_bit_offset0x -DW_AT_data_member_location DW_OP_plus_uconst 1 +DW_AT_bit_offset0xfff9 +DW_AT_data_member_location DW_OP_plus_uconst 0 < 1><0x0050>DW_TAG_base_type DW_AT_byte_size 0x0004 DW_AT_encoding DW_ATE_unsigned
[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug bootstrap/43714] missing check for zlib.h, fails to build lto-compress.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714 Peter VARGA changed: What|Removed |Added CC||developm...@faf-ltd.com --- Comment #3 from Peter VARGA --- But is this really that big deal to check it in configure? There are checked so many conditions and a missing zlib.h causes the compilation to fail.
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-pc-linux-gnu, ||aarch64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, happens on aarch64-linux-gnu also.
[Bug ipa/71624] [6/7 regression][CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71624 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |6.2
[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |6.2
[Bug libstdc++/71660] [5/6/7 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660 Andrew Pinski changed: What|Removed |Added Keywords||ABI Target Milestone|--- |5.5 Summary|[5 regression] alignment of |[5/6/7 regression] |std::atomic<8 byte |alignment of std::atomic<8 |primitive type> (long long, |byte primitive type> (long |double) is wrong on x86 |long, double) is wrong on ||x86 Severity|major |normal
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #5 from Anton Mitrokhin --- I have compiled this test case in several ways The first two emit no warnings and fail as described: > g++ -Wall -Wextra -std=c++11 -static-libgcc -static-libstdc++ -Ofast > -march=westmere -o out crash_init.cpp crash_main.cpp > g++ -Wall -Wextra -fno-strict-aliasing -fwrapv > -fno-aggressive-loop-optimizations -std=c++11 -static-libgcc > -static-libstdc++ -Ofast -march=westmere -o out crash_init.cpp crash_main.cpp The clang sanitizers are also silent on runtime: > clang++ -Wall -Wextra -fsanitize=undefined -std=c++11 -O2 -o out > crash_init.cpp crash_main.cpp > clang++ -Wall -Wextra -fsanitize=memory -std=c++11 -O2 -o out crash_init.cpp > crash_main.cpp > clang++ -Wall -Wextra -fsanitize=address -std=c++11 -O2 -o out crash_init.cpp > crash_main.cpp The versions with GLIBCXX_DEBUG do not fail: > g++ -Wall -Wextra -D_GLIBCXX_DEBUG -std=c++11 -static-libgcc > -static-libstdc++ -Ofast -march=westmere -o out crash_init.cpp crash_main.cpp > g++ -Wall -Wextra -D_GLIBCXX_DEBUG -fno-strict-aliasing -fwrapv > -fno-aggressive-loop-optimizations -std=c++11 -static-libgcc > -static-libstdc++ -Ofast -march=westmere -o out crash_init.cpp crash_main.cpp The test case is not that big, and it contains only 3 arrays, only one of which can emit that kind of an error. This code is easy-checkable by hand and it looks like it *should* work.
[Bug middle-end/71654] [6/7 Regression] missing VRP optimization on c++ unsigned char and short expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71654 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |6.2
[Bug target/71652] [7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Target Milestone|--- |7.0
[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71630 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug libstdc++/71640] [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71640 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug ipa/71633] [7 regression][CHKP] internal compiler error: in inline_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71633 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |7.0
[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71602 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.2
[Bug target/71629] [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71626 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |4.9.4
[Bug tree-optimization/71575] [6/7 Regression] [graphite] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71575 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.2
[Bug c++/71570] [6/7 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71570 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.2
[Bug c++/71577] [6/7 regression] ICE on invalid C++11 code (with extra struct initializer) on x86_64-linux-gnu: in digest_init_r, at cp/typeck2.c:1117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71577 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.2
[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |6.2
[Bug c++/71569] [5/6/7 regression] Crash: External definition of template member from template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71569 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.5
[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.2
[Bug tree-optimization/71503] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "gen_phi_arg_condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71503 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c/71345] Warn about redundant conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71345 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug driver/69849] Some spec functions are undocumented in doc/invoke.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69849 Andrew Pinski changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Really the specs documentation should be removed from invoke.texi and moved to the internals manual instead. Confirmed.
[Bug c++/69775] thread_local extern variable causes linkage error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #2 from Andrew Pinski --- Confirmed, Though I can't figure out how to reduce it further. Right now we still have std::list. I tried using a simple class which has a constructor/detor but no go.
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #4 from Jonathan Wakely --- Also compile with -D_GLIBCXX_DEBUG
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 --- Comment #3 from Jonathan Wakely --- I'm not very motivated to debug this "code", please make sure you try the options suggested at https://gcc.gnu.org/bugs/ to be sure the sanitizers don't find a problem.
[Bug middle-end/71524] [7 Regression] internal compiler error: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71524 --- Comment #3 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > It is caused by r70018. Oops. It was caused by r235065.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386
--- Comment #6 from Marc Glisse ---
Slightly simpler
template
auto List(XS...xs)
{
return [=](auto processList){return processList(xs...);};
};
auto l1 = List(42);
auto foo = [](auto... xs1)
{
return [=]()
{
return l1([=](auto)
{
return __builtin_printf("%d",xs1...);
});
};
};
int main()
{
auto concat = l1(foo);
concat();
__builtin_printf("\n");
}
If I make xs1 non-variadic (just erase '...' in 2 places), things work. The
main difference seems to be in [with auto:2 = {int}] (we
write to some place in the stack then re-read the value from another place) but
it isn't clear what is going wrong there.
[Bug debug/71667] New: [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667
Bug ID: 71667
Summary: [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2
-ftree-vectorize
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-7.0.0-alpha20160619 ICEs on the following reduced testcase w/ -O2 (-O3,
-Ofast) -g -ftree-vectorize:
unsigned int mu;
int pt;
void
qf (void)
{
int gy;
long int vz;
for (;;)
{
for (gy = 0; gy < 80; ++gy)
{
vz = mu;
++mu;
pt = (vz != 0) && (pt != 0);
}
while (gy < 81)
while (gy < 83)
{
vz = (vz != 0) ? 0 : mu;
++gy;
}
pt = vz;
++mu;
}
}
% gcc-7.0.0-alpha20160619 -c -O2 -g -ftree-vectorize jjgn2cjj.c
jjgn2cjj.c: In function 'qf':
jjgn2cjj.c:5:1: internal compiler error: in as_a, at is-a.h:192
qf (void)
^~
[Bug middle-end/71666] profile-generate not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71666 --- Comment #2 from vincenzo Innocente --- ok so is just the sentence "" See Optimize Options" which needs to be changed...
[Bug web/71666] profile-generate not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71666 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fprofile-generate-957
[Bug web/71666] New: profile-generate not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71666 Bug ID: 71666 Summary: profile-generate not documented Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch Target Milestone: --- as of today -fprofile-generate does not seem to be documented in https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html it is quoted 4 times including a self-referencing " See Optimize Options, for information about the -fprofile-generate option" (btw -fprofile-dir is quoted and not documented as well)
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #5 from Marc Glisse --- (In reply to Anton Mitrokhin from comment #3) > I see those warnings with -O3, but not with -O0. Why is that? As the documentation says, this warning depends on optimizations. A bogus optimization that breaks the code may thus also cause this warning. > I also do not see what is wrong with the code. If you manage to reduce the example a little more, with fewer lambdas, that might help with the debugging.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed, looks like GCC is getting confused somewhere but I can't figure it out easily.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #3 from Anton Mitrokhin --- I see those warnings with -O3, but not with -O0. Why is that? I also do not see what is wrong with the code. Note, that clang with all warnings enabled (and ub sanitizer!) will also not produce any warnings and will generate correct code.
[Bug middle-end/71650] unnecessary call to __memcpy_chk emitted on a bounded copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71650 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/71478] [7 Regression] ICE in tree-ssa-reassoc.c after r236564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71478 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug middle-end/71524] [7 Regression] internal compiler error: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71524 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- (In reply to H.J. Lu from comment #1) > It is caused by r70018. Did you mean (one of the) fixes for PR70018? Do you have the commit id?
