[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 --- Comment #4 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 32068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32068action=edit testcase.i produced by c-reduce
[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 --- Comment #5 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 32069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32069action=edit Original ii file gzipped
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Jouko Orava jouko.orava at iki dot fi changed: What|Removed |Added CC||jouko.orava at iki dot fi --- Comment #6 from Jouko Orava jouko.orava at iki dot fi --- Confirmed. The second test case still segfaults when run if compiled with -static in Linux 3.8.0 x86_64 kernel on Ubuntu 12.04.4 LTS, using gfortran 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5). When gdb is run on the static binary, it warns that no loadable sections found in added symbol-file system-supplied DSO at 0x77ffd000. gdb backtrace: (gdb) run Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0040bb83 in write_float () #2 0x00404d27 in formatted_transfer () #3 0x0040318a in _gfortran_transfer_array () #4 0x004013a5 in MAIN__ () at fdp1.f90:4 (gdb) info registers rax0x11 rbx0x6fb6e87321320 rcx0x2739 rdx0x4be7124974354 rsi0x3149 rdi0x7fffdb80140737488345984 rbp0x280x28 rsp0x7fffdab80x7fffdab8 r8 0x00 r9 0x00 r100x00 r110xb333197032483697459 r120x7fffddc0140737488346560 r130x7fffdb80140737488345984 r140x00 r150x00 rip0x00 eflags 0x10202[ IF RF ] cs 0x3351 ss 0x2b43 ds 0x00 es 0x00 fs 0x6399 gs 0x00 The disassembly of the write_float () up to the segmentation fault: 0040ba60 write_float: 40ba60: 41 57 push %r15 40ba62: 41 56 push %r14 40ba64: 41 55 push %r13 40ba66: 41 54 push %r12 40ba68: 49 89 fcmov%rdi,%r12 40ba6b: 55 push %rbp 40ba6c: bd 28 00 00 00 mov$0x28,%ebp 40ba71: 53 push %rbx 40ba72: 48 89 f3mov%rsi,%rbx 40ba75: 48 81 ec 08 01 00 00sub$0x108,%rsp 40ba7c: 44 8b 2emov(%rsi),%r13d 40ba7f: 64 48 8b 04 25 28 00mov%fs:0x28,%rax 40ba86: 00 00 40ba88: 48 89 84 24 f8 00 00mov%rax,0xf8(%rsp) 40ba8f: 00 40ba90: 31 c0 xor%eax,%eax 40ba92: 41 83 fd 1e cmp$0x1e,%r13d 40ba96: 74 0a je 40baa2 write_float+0x42 40ba98: 41 83 fd 1c cmp$0x1c,%r13d 40ba9c: 0f 85 06 05 00 00 jne40bfa8 write_float+0x548 40baa2: 83 f9 08cmp$0x8,%ecx 40baa5: 0f 84 4a 05 00 00 je 40bff5 write_float+0x595 40baab: 0f 8e 6f 08 00 00 jle40c320 write_float+0x8c0 40bab1: 83 f9 0acmp$0xa,%ecx 40bab4: 0f 84 7e 08 00 00 je 40c338 write_float+0x8d8 40baba: 83 f9 10cmp$0x10,%ecx 40babd: 0f 1f 00nopl (%rax) 40bac0: 0f 85 63 08 00 00 jne40c329 write_float+0x8c9 40bac6: 66 0f 6f 02 movdqa (%rdx),%xmm0 40baca: 66 0f 7f 44 24 40 movdqa %xmm0,0x40(%rsp) 40bad0: e8 9b 27 01 00 callq 41e270 __trunctfdf2 40bad5: 66 44 0f 50 f0 movmskpd %xmm0,%r14d 40bada: 66 0f 6f 54 24 40 movdqa 0x40(%rsp),%xmm2 40bae0: 41 83 e6 01 and$0x1,%r14d 40bae4: 66 0f db 15 44 30 0bpand 0xb3044(%rip),%xmm2# 4beb30 CSWTCH.109+0xb0 40baeb: 00 40baec: 66 0f 6f 0d 4c 30 0bmovdqa 0xb304c(%rip),%xmm1# 4beb40 CSWTCH.109+0xc0 40baf3: 00 40baf4: 66 0f 6f c2 movdqa %xmm2,%xmm0 40baf8: 66 0f 7f 54 24 10 movdqa %xmm2,0x10(%rsp) 40bafe: e8 ed 25 01 00 callq 41e0f0 __unordtf2 40bb03: 48 85 c0test %rax,%rax 40bb06: 66 0f 6f 54 24 10 movdqa 0x10(%rsp),%xmm2 40bb0c: 0f 85 8e 0c 00 00 jne40c7a0 write_float+0xd40 40bb12: 66 0f 6f 0d 26 30 0bmovdqa 0xb3026(%rip),%xmm1# 4beb40 CSWTCH.109+0xc0 40bb19: 00 40bb1a: 66 0f 6f c2 movdqa %xmm2,%xmm0 40bb1e: e8 8d 2c 01 00 callq 41e7b0 __getf2 40bb23: 48 85 c0test %rax,%rax 40bb26: 0f 8f 74 0c 00 00 jg 40c7a0 write_float+0xd40 40bb2c: 45 85 f6test %r14d,%r14d 40bb2f: 74 14 je 40bb45
[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Yes, I fixed it at r205581 but the PR reference in the ChangeLog disappeared between the submission and the commit :( Yvan
[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 --- Comment #6 from David Kredba nheghathivhistha at gmail dot com --- Revision 207565 is fine with it.
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. The second test case still segfaults when run if compiled with -static in Linux 3.8.0 x86_64 kernel on Ubuntu 12.04.4 LTS, using gfortran 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5). The 4.6 versions are no longer supported. Could you test with the current releases 4.7.3 and/or 4.8.2?
[Bug c/60100] New: warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
Bug ID: 60100
Summary: warning disappears when preprocessed source is
compiled
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Created attachment 32070
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32070action=edit
GCC specs are attached
Hello,
When compiling the attached C code with GCC 4.8.1, I see a warning (which is
correct) that the callback signature mismatches what's expected in the argument
of BUF_PeekAtCB() call. If however, the source is first preprocessed then
compiled, there is no warning! Since distcc uses precompiled source, the
disappearing warning is a bad thing because it hides potential (and real, such
as this case) bugs.
$ cat qq.h
#include stddef.h
typedef struct SBUF* BUF;
extern size_t BUF_PeekAtCB
(BUF buf,
size_t pos,
size_t(*callback)(void* cbdata, const void* buf, size_t size),
void* cbdata,
size_t size
);
$ cat qq.c
#include stdio.h
#include qq.h
size_t cb(void* a, void* b, size_t c, int d)
{
return c;
}
int main()
{
BUF b = 0;
size_t n = BUF_PeekAtCB(b, 0, cb, 0, 512);
printf(%u\n, (unsigned int) n);
return 0;
}
$ gcc -Wall -c qq.c -o qq.o
qq.c: In function 'main':
qq.c:14:5: warning: passing argument 3 of 'BUF_PeekAtCB' from incompatible
pointer type [enabled by default]
size_t n = BUF_PeekAtCB(b, 0, cb, 0, 512);
^
In file included from qq.c:2:0:
qq.h:7:15: note: expected 'size_t (*)(void *, const void *, size_t)' but
argument is of type 'size_t (*)(void *, void *, size_t, int)'
extern size_t BUF_PeekAtCB
^
$ gcc -Wall -E qq.c -o qq.e
$ gcc -Wall -c qq.e -o qq.o
gcc: warning: qq.e: linker input file unused because linking not done
Also, I'm not sure why there is a bogus warning about linking here (and not
when
compiling right from the source file, above).
Any insight that you may have provide will be highly appreciated.
Thanks,
Anton Lavrentiev
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Also, I'm not sure why there is a bogus warning about linking here (and not when compiling right from the source file, above). Because your command line did not actual compile anything. Use the .i suffix instead of the .e suffix for preprocessed source and try your commands again.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- This could be a duplicate of pr50201.
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Because your command line did not actual compile anything. Indeed. with .i I see the warning again. But I can't see any warning if the precompiled file is processed through distcc...
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #3 from lavr at ncbi dot nlm.nih.gov --- Ok, sorry and let me start again. My original mockup case wasn't good enough. So attached is the real (preprocessed) code that fails to produce a warning (yet when compiled from the .c form, the warning is there). This completes w/o warnings: gcc -E -std=gnu11 -fgnu89-inline -c -Wall -Wno-format-y2k -fPIC -gdwarf-3 -D_DEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNCBI_WITHOUT_MT -I/home/lavr/cxx/GCC-Debug64/inc -I/home/lavr/cxx/include /home/lavr/cxx/src/connect/ncbi_socket.c -o ncbi_socket.i gcc -std=gnu11 -fgnu89-inline -c -Wall -Wno-format-y2k -fPIC -gdwarf-3 -D_DEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 ncbi_socket.i -o ncbi_socket.o This produces a warning (as it should): gcc -c -std=gnu11 -fgnu89-inline -c -Wall -Wno-format-y2k -fPIC -gdwarf-3 -D_DEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNCBI_WITHOUT_MT -I/home/lavr/cxx/GCC-Debug64/inc -I/home/lavr/cxx/include /home/lavr/cxx/src/connect/ncbi_socket.c -o ncbi_socket.o /home/lavr/cxx/src/connect/ncbi_socket.c: In function 's_WritePending': /home/lavr/cxx/src/connect/ncbi_socket.c:3447:33: warning: passing argument 3 of 'BUF_PeekAtCB' from incompatible pointer type [enabled by default] x_WriteBuf, ctx, sock-w_len); ^ In file included from /home/lavr/cxx/src/connect/ncbi_socketp.h:44:0, from /home/lavr/cxx/src/connect/ncbi_connssl.h:37, from /home/lavr/cxx/src/connect/ncbi_socket.c:76: /home/lavr/cxx/include/connect/ncbi_buffer.h:180:36: note: expected 'size_t (*)(void *, const void *, size_t)' but argument is of type 'size_t (*)(void *, const void *, size_t, int)' extern NCBI_XCONNECT_EXPORT size_t BUF_PeekAtCB
[Bug c/60101] New: Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 Bug ID: 60101 Summary: Long compile times when mixed complex floating point datatypes are used in lengthy expressions Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thorstenkurth at me dot com Created attachment 32071 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32071action=edit Archive which includes test case. In the example I copied below, the double.c file compiles instantly whereas the float.c file takes very long. This is a truncated version of an even longer file (more lines of code in the loop) and the compile time for the float.c file grows like N^3, where N is the number of lines. Here is the output of the long version for 4.8.2: 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 0x40c875 handle_braces ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5786 0x40c875 handle_braces ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5786 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 and more messages like that The attached files both compile, but they the float.c takes significantly longer. The only difference between those files is that the temporary variable sum is double complex in the working version and float complex in the non-working version. So I guess, the compiler tries to reorganize the complex multiplications and additions so that intermediate floating point results can be used (this is what I guess). Both files compile using the icc (=11.0) and clang/LLVM almost instantly. It also works for gcc=4.4.
[Bug c/60100] warning disappears when preprocessed source is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100 --- Comment #4 from lavr at ncbi dot nlm.nih.gov --- Created attachment 32072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32072action=edit Preprocessed C source that fails to produce a warning when compiled
[Bug target/46481] long double should default to 64bit even for aix6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46481 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- fixed
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #8 from Jouko Orava jouko.orava at iki dot fi --- I confirm, still occurs with 4.7.3 and 4.8.1. For simplicity, I obtained the 4.7 and 4.8 versions from Ubuntu toolchain test builds' PPA, https://launchpad.net/~ubuntu-toolchain-r/. GNU Fortran 4.7.3 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04): gdb backtrace: #0 0x in ?? () #1 0x0040c868 in write_float () #2 0x00405db6 in formatted_transfer () #3 0x00404004 in _gfortran_transfer_array () #4 0x00401396 in MAIN__ () Code near the segfault: 40c85b: 0f 94 84 24 80 00 00sete 0x80(%rsp) 40c862: 00 40c863: e8 98 37 bf ff callq 0 __libc_tsd_LOCALE 40c868: 41 83 3c 24 20 cmpl $0x20,(%r12) 40c86d: 0f 84 bd 08 00 00 je 40d130 write_float+0x9e0 40c873: 44 0f b6 84 24 80 00movzbl 0x80(%rsp),%r8d Assigning a breakpoint at 40c863 and jumping to 40d130 avoids the segfault. The printed output contains 'V' instead of \xb6. GNU Fortran 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04): gdb backtrace: #0 0x in ?? () #1 0x0040c3e9 in write_float () #2 0x00406671 in formatted_transfer () #3 0x0040402f in _gfortran_transfer_array () #4 0x00401396 in MAIN__ () Code near the segfault: 40c3dc: 4c 89 e6mov%r12,%rsi 40c3df: b8 01 00 00 00 mov$0x1,%eax 40c3e4: e8 17 3c bf ff callq 0 __libc_tsd_LOCALE 40c3e9: 41 89 c0mov%eax,%r8d 40c3ec: 0f b6 85 f0 fe ff ffmovzbl -0x110(%rbp),%eax 40c3f3: 89 44 24 08 mov%eax,0x8(%rsp) 40c3f7: e9 c7 00 00 00 jmpq 40c4c3 write_float+0x273 Assigning a breakpoint at 40c3e4 and jumping to 40c3e9 or 40c4c3 avoids the first segfault (again a call to __libc_tsd_LOCALE). Another segfault will occur at 4531fb in memcpy(), in a 'rep movsq %ds:(%rsi),%es:(%rdi)' instruction, with source (%rsi register) referring to just past/above stack (0x7000). (The process map indicates stack is at 7ffde000-7000). To me, this looks like trying to copy a string, but with the source string missing completely. In fact, this enforces my belief that the call to __libc_tsd_LOCALE really should be some kind of setup for the locale-specific numeric formatting string, and that finding out how a reference to the thread-specific locale structure can be changed to a function call to that address. That said, in all cases there are other calls to __libc_tsd_LOCALE (which all would cause a segmentation fault, if executed) in the disassembly. If compiled with 4.7.3, in _IO_flush_all_linebuffered: 438d04: 438d3a: _IO_flush_all_lockp: 438860: 4388da: _IO_link_in: 43787d: 4378ba: _IO_un_link: 43766f: 4376a2: _IO_vfprintf: 47a94e: 47aa5f: _IO_vfscanf: 4a448a: 4a55c0: _IO_vfwprintf: 4851ab: 4851f7: _Unwind_Find_FDE: 422a45: 422a95: __assert_fail_base: 4235dc: __dcigettext: 424609: 424613: 42469d: 4246cb: 4249db: 4249e5: 424a2f: 424a39: 424bc2: 424bcc: 424d78: 424db6: __deregister_frame_info_bases: 4228ed: 422975: __dl_iterate_phdr: 46b611: 46b6cf: __dlerror: 4ad826: 4ad83f: __dlsym: 4b3912: 4b393d: __dlvsym: 4b39c4: 4b39f1: __gconv_compare_alias: 46d621: __gconv_find_transform: 46d729: __libc_enable_asynccancel: 46a740: __libc_fork: 4664d6: __libc_start_main: 422e4e: __register_frame_info_bases: 42278b: __register_frame_info_table_bases: 42284a: __wcsmbs_load_conv: 465f3f: 466071: _dl_add_to_namespace_list: 49f7cb: _dl_addr: 46b7ad: 46b9c2: _dl_close: 4b3566: _dl_close_worker: 4b2ed9: 4b3078: _dl_fini: 4b5b3f: 4b5c06: _dl_lookup_symbol_x: 49f325: 49f3f5: 49f481: _dl_open: 4b1a4d: 4b1b12: 4b1b97: 4b1c6d: _dl_tlsdesc_resolve_hold_fixup: 4b3787: _dl_tlsdesc_resolve_rela_fixup: 4b361c: 4b363f: _dlerror_run: 4adad1: 4adb60: 4adb9f: _gfortran_arandom_r10: 41011b: _gfortran_arandom_r16: 41030b: _gfortran_arandom_r4: 40fd7b: _gfortran_arandom_r8: 40ff2a: _gfortran_random_r10: 40fb18: _gfortran_random_r16: 40fbef: _gfortran_random_r4: 40f9d3: _gfortran_random_r8: 40fa48: _gfortran_random_seed_i4: 4104c2: 410648: _gfortran_random_seed_i8: 4106e3: _gfortrani_close_units: 408c90: _gfortrani_convert_infnan: 41898b: _gfortrani_convert_real: 41888e: _gfortrani_find_file: 40a24e: 40a268: 40a282: 40a29b: 40a2af: 40a2b7: 40a335: _gfortrani_flush_all_units: 40a36a: 40a3a1: 40a3c2: 40a3e9: 40a3f1: 40a40d: 40a415: _gfortrani_get_internal_unit: 4083c8: _gfortrani_init_units: 408777: 40884b: 408922: _nl_find_domain: 424efb: 424f5b: 425064: 4250c1: _nl_find_msg: 423ca8: 423d11: 423ef2: 423f79: 424418: 42454b: _nl_get_alt_digit: 49942a: 49945e: _nl_get_walt_digit: 4994d9: 49956a:
[Bug c++/59632] ICE with erroneous loop condition after #pragma GCC ivdep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59632 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Volker Reichelt reichelt at gcc dot gnu.org --- Apparently this has been fixed between 2014-01-17 and 2014-01-18.
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #12 from Jeffrey A. Law law at redhat dot com --- So the problem here is try_combine is playing things a bit fast and loose when it rips apart the PARALLEL into two independent sets (one of which is a nop). In particular it assumes that I3 is an INSN as opposed to a JUMP_INSN or CALL_INSN. As a result combine is happy to create the bogus RTL as seen in Andreas's last comment. It's easily fixed and a patch for that is in testing.
[Bug middle-end/60102] New: powerpc fp-bit ices at dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Bug ID: 60102 Summary: powerpc fp-bit ices at dwf_regno Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pa...@matos-sorge.com Created attachment 32073 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32073action=edit Testcase This might be a dup of PR52372 or PR57933 but since I am not sure I am opening a new bug. When trying to compile powerpc libgcc fp-bit I get an ICE using trunk: $ /home/pmatos/projects/EXTERNAL/GCC/builds/gcc-trunk_powerpc/./gcc/cc1 -fpreprocessed fp-bit.i -quiet -dumpbase fp-bit.c -msoft-float -mcpu=8540 -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fvisibility=hidden -o fp-bit.s GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20140205 (experimental) (powerpc-eabispe) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 52229a64c376a95d997a16c551e2c79f fp-bit.i: In function ‘fn3’: fp-bit.i:27:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909 } ^ 0x786749 dwf_regno ../../../gcc-trunk/gcc/dwarf2cfi.c:909 0x78696b dwarf2out_flush_queued_reg_saves ../../../gcc-trunk/gcc/dwarf2cfi.c:988 0x789981 scan_trace ../../../gcc-trunk/gcc/dwarf2cfi.c:2522 0x789ab2 create_cfi_notes ../../../gcc-trunk/gcc/dwarf2cfi.c:2565 0x78a553 execute_dwarf2_frame ../../../gcc-trunk/gcc/dwarf2cfi.c:2925 0x78b402 execute ../../../gcc-trunk/gcc/dwarf2cfi.c:3421 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. I will attach the fp-bit.i reduced version.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #11 from Jacob Abel thatcadguy at gmail dot com --- The culprit that -march=native activates on my Core i7 laptop is -mavx. Compiling with -mavx causes the segfault, without is fine. Unfortunately, that flag was not set on my other laptop, so might be multiple issues here.
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #13 from Jeffrey A. Law law at redhat dot com --- BTW, compiling with -O2 rather than -O1 makes this problem go away. The problematical sequence (testing that the result of an alloca call is nonzero) is eliminated by the VRP optimizers which only run at -O2 and above.
[Bug rtl-optimization/60030] [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60030 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 21:54:21 2014 New Revision: 207582 URL: http://gcc.gnu.org/viewcvs?rev=207582root=gccview=rev Log: PR rtl-optimization/60030 * internal-fn.c (ubsan_expand_si_overflow_mul_check): Surround lopart with paradoxical subreg before shifting it up by hprec. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #12 from Jacob Abel thatcadguy at gmail dot com --- Created attachment 32074 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32074action=edit NEW smaller simpler file to create the segfault
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #13 from Jacob Abel thatcadguy at gmail dot com --- The following file: SUBROUTINE test(N) IMPLICIT NONE INTEGER, INTENT(IN) :: N REAL(KIND=16) :: array(N) array = 0 END SUBROUTINE test PROGRAM main IMPLICIT NONE CALL test(10) END PROGRAM main Creates the same problem. Segfault occurs on 'array = 0'. Will provide more info when I get home.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Jacob Abel from comment #8) Seriously? Look, you falsely assumed it was mingw only. Yes, with the information I had at the time, I thought the problem was mingw specific. No wonder clang is going to win in the long run. Fucking twat. If neither gfortran nor the free support offered by the volunteer gfortran developers/maintainers do not meet your expectation, you can remove gfortran from your system and use the llvm-based Fortran compiler.
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #9 from Jouko Orava jouko.orava at iki dot fi --- It turns out that while fdp2.f90, PROGRAM fdp2 IMPLICIT none INTEGER, PARAMETER :: b128 = SELECTED_REAL_KIND(33, 1000) REAL(KIND=b128) :: x(4) x = 3.4_b128 PRINT *, KIND(x) WRITE (*, (4F10.3)) x(1:4) END PROGRAM crashes when compiled static, PROGRAM fdp2 IMPLICIT none INTEGER, PARAMETER :: b128 = SELECTED_REAL_KIND(33, 1000) REAL(KIND=b128) :: x(4) x = 3.4_b128 PRINT *, KIND(x) WRITE (*, (4F10.3)) x(1), x(3:4) END PROGRAM does not. The only thing that changes in the second-to-last line: with x(1:4) it segfaults, with x(1),x(3:4) it works fine. Compiled on 4.7.3 using gfortran-4.7 -static -ggdb -W -Wall -O3 fdp2.f90 -o fdp2 and on 4.8.1 using gfortran-4.8 -static -ggdb -W -Wall -O3 fdp2.f90 -o fdp2 Comparing the disassembly of the two, both do have a large number of callq 0 __libc_tsd_LOCALE calls. However, where the first one segfaults, the second one has callq 423320 quadmath_snprintf Furthermore, compiling using -Wl,-uquadmath_snprintf fixes the issue, i.e. gfortran-4.7 -static -ggdb -W -Wall -O3 fdp2.f90 -Wl,-uquadmath_snprintf fdp2 causes the shown example program to work correctly. Finally, compiling Bill Long's example fdp2.f90 using gfortran-4.7 -fdefault-real-8 -static fdp2.f90 -Wl,-uquadmath_snprintf -o a.out or gfortran-4.8 -fdefault-real-8 -static fdp2.f90 -Wl,-uquadmath_snprintf -o a.out fixes the segfault for me. It seems like some kind of linking issue. How the issue is masked by printing a scalar before an array is a mystery to me, however.
[Bug driver/57951] -MG doesn't work with -MD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57951 Douglas Bagnall douglas at halo dot gen.nz changed: What|Removed |Added CC||douglas at halo dot gen.nz --- Comment #1 from Douglas Bagnall douglas at halo dot gen.nz --- Also present in 4.8.1, and it also affects -MMD as you might expect.
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alan Modra amodra at gmail dot com --- Yes, and the offending patch didn't make its way into 4.8.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Jouko Orava jouko.orava at iki dot fi changed: What|Removed |Added CC||jouko.orava at iki dot fi --- Comment #15 from Jouko Orava jouko.orava at iki dot fi --- Bug #50201 is fixed by adding -Wl,-uquadmath_snprintf option to gfortran (to cause the linker to consider the quadmath_snprintf to be undefined, and pulls it in). I do not have an AVX-capable CPU at hand, so I don't know if this bug is related or not; perhaps it is worth a test?
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #16 from Jacob Abel thatcadguy at gmail dot com --- Still segfaults, at least on MinGW: C:\Users\Jake\Downloadsgfortran -march=native -Wl,-uquadmath_snprintf newtest.f 90 C:\Users\Jake\Downloadsa Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 6f610f4e #1 6f6913eb #2 004010f8 C:\Users\Jake\Downloads
[Bug c/60103] New: Spurious -Wsequence-point warning with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103
Bug ID: 60103
Summary: Spurious -Wsequence-point warning with -O1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Gcc -O1 emits an undefined behavior warning, whereas gcc -O0 not.
Based on my understanding of the standard, I cannot see why it is an undefined
behavior.
$: cat s.c
extern unsigned short fn2(unsigned short, unsigned short);
void fn1(int l) {
l = fn2(l = 0, 0) || 0;
}
$: gcc-trunk -c -Wsequence-point -O1 s.c
s.c: In function ‘fn1’:
s.c:3:5: warning: operation on ‘l’ may be undefined [-Wsequence-point]
l = fn2(l = 0, 0) || 0;
^
$: gcc-trunk -c -Wsequence-point -O0 s.c
[Bug c/60103] Spurious -Wsequence-point warning with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think C11 and C90/C99 have a different idea here. There is a relative sequence point between the function call fn2 and the 0 but there is no sequence point between the two assignments I think. Sequence points are not my area of expertise so I could be wrong but I do know that C11/C++11 does get rid of the idea of sequence points and change the name of it to something else.
[Bug target/60104] New: load not folded into indirect branch on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60104 Bug ID: 60104 Summary: load not folded into indirect branch on x86-64 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dan433584 at gmail dot com Created attachment 32075 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32075action=edit a C testcase The attached testcase is a greatly reduced interpreter loop, containing a simple load and indirect branch: goto *addresses[*pc++] gcc 4.8.2 (as well as older versions) with -O2 produces the following x86-64 output: movqaddresses.1721(,%rax,8), %rax jmp*%rax Since the loaded value is not used after the branch, there's no need to hold it in a register, so the load could be folded into the branch. This would improve code size and instruction count.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #18 from Jouko Orava jouko.orava at iki dot fi --- Addendum: the unaligned access causing the segfault seems to occur because __libc_malloc returns an address aligned to 8 bytes, but it is used as if it was aligned to 16 bytes. The disassembly is 80493a0: e8 bb 64 04 00call 808f860 __libc_malloc 80493a5: 89 45 f0 mov%eax,-0x10(%ebp) 80493a8: 8b 5d f4 mov-0xc(%ebp),%ebx 80493ab: b8 01 00 00 00mov$0x1,%eax 80493b0: 39 d8 cmp%ebx,%eax 80493b2: 7f 18 jg 80493cc test_+0x58 80493b4: 8d 48 ff lea-0x1(%eax),%ecx 80493b7: 8b 55 f0 mov-0x10(%ebp),%edx 80493ba: c1 e1 04 shl$0x4,%ecx 80493bd: 01 ca add%ecx,%edx 80493bf: 66 0f ef c0 pxor %xmm0,%xmm0 80493c3: 66 0f 7f 02 movdqa %xmm0,(%edx) 80493c7: 83 c0 01 add$0x1,%eax 80493ca: eb e4 jmp80493b0 test_+0x3c 80493cc: 8b 45 f0 mov-0x10(%ebp),%eax but note that this exact binary was compiled statically, and therefore the addresses differ from the original bug report. Assuming I read the above disassembly correctly, the pointer returned to by __libc_malloc is stored in the stack (at %ebp-16), and retrieved before the access back to %edx. An offset is calculated based on some values into %ecx, multiplied by 16, and added to %edx. %xmm0 is cleared, then copied to address pointed to by %edx. In other words, this is just clearing the array received from malloc() to zeros. Jacob Abel, if you could run the binary you provided me in gdb using (gdb) break *0x80493a5 (gdb) run (gdb) info registers and verify that the %eax register contains an unaligned value (not aligned to 16, last nibble nonzero), then we can confirm that this is the issue -- that GNU Fortran or quadmath library expects malloc() to return 16-byte aligned pointers, whereas it only provides 8-byte aligned pointers. For reference, the malloc man page at the Linux man-pages project, at http://man7.org/linux/man-pages/man3/malloc.3.html explicitly states malloc() returns only 8-byte aligned pointers. (Other references seem to erroneously state that it returns 16-byte aligned pointers on 64-bit architectures.)
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||hubicka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #19 from Jacob Abel thatcadguy at gmail dot com --- jake@Jake-E1505:~/Desktop$ gfortran -static -march=native -Wl,-uquadmath_snprintf newtest.f90 -o newtest jake@Jake-E1505:~/Desktop$ gdb newtest GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jake/Desktop/newtest...(no debugging symbols found)...done. (gdb) break *0x80493a5 Breakpoint 1 at 0x80493a5 (gdb) run Starting program: /home/jake/Desktop/newtest Breakpoint 1, 0x080493a5 in test_ () (gdb) info registers eax0x81325c8135472584 ecx0x812c780135448448 edx0x81325c8135472584 ebx0x80481d8134513112 esp0xb2e00xb2e0 ebp0xb3080xb308 esi0x00 edi0x812c00c135446540 eip0x80493a50x80493a5 test_+49 eflags 0x286[ PF SF IF ] cs 0x73115 ss 0x7b123 ds 0x7b123 es 0x7b123 fs 0x00 gs 0x3351 (gdb)
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Confirmed. Never ending virtual inheritance fun!
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #47 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 7 02:27:05 2014 New Revision: 207589 URL: http://gcc.gnu.org/viewcvs?rev=207589root=gccview=rev Log: PR ipa/59469 * lto-cgraph.c (lto_output_node): Use symtab_get_symbol_partitioning_class. (lto_output_varpool_node): likewise. (symtab_get_symbol_partitioning_class): Move here from lto/lto-partition.c * cgraph.h (symbol_partitioning_class): Likewise. (symtab_get_symbol_partitioning_class): Declare. * lto-partition.c (symbol_class): Move to cgraph.h (get_symbol_class): Move to symtab.c (add_references_to_partition, add_symbol_to_partition_1, lto_max_map, lto_1_to_1_map, lto_balanced_map, lto_promote_cross_file_statics): Update. Modified: trunk/gcc/cgraph.h trunk/gcc/lto-cgraph.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-partition.c
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #17 from Jouko Orava jouko.orava at iki dot fi --- I asked and received the details from Jacob Abel off-list, to find out if this bug #60088 is related to bug #50201. They do not seem to be. The instruction causing the segfault in this bug #60088 is 66 0f 7f 02movdqa %xmm0,(%edx) which requires %edx to be aligned to a 16 byte boundary, but %edx is 0x81325c8, unaligned. Thus, segfault. Why this occurs with -mavx but not without, I do not know. In short, the segfault is due to 8-byte aligned access, where 16-byte alignment is required. Perhaps this bug is related to bug #56564 ?
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #50 from Jan Hubicka hubicka at gcc dot gnu.org --- Hope so, this PR was quite persistent ;)
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 7 02:11:27 2014 New Revision: 207587 URL: http://gcc.gnu.org/viewcvs?rev=207587root=gccview=rev Log: PR target/60077 * expr.c (emit_move_resolve_push): Export; be bit more selective on when to clear alias set. * expr.h (emit_move_resolve_push): Declare. * function.h (struct function): Add tail_call_marked. * tree-tailcall.c (optimize_tail_call): Set tail_call_marked. * config/i386/i386-protos.h (ix86_expand_push): Remove. * config/i386/i386.md (TImode move expander): De not call ix86_expand_push. (FP push expanders): Preserve memory attributes. * config/i386/sse.md (pushmode1): Remove. * config/i386/i386.c (ix86_expand_vector_move): Handle push operation. (ix86_expand_push): Remove. * config/i386/mmx.md (pushmode1): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/mmx.md trunk/gcc/config/i386/sse.md trunk/gcc/expr.c trunk/gcc/expr.h trunk/gcc/function.h trunk/gcc/tree-tailcall.c
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #49 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 7 02:28:33 2014 New Revision: 207591 URL: http://gcc.gnu.org/viewcvs?rev=207591root=gccview=rev Log: PR ipa/59469 * lto-cgraph.c (lto_output_node): Use symtab_get_symbol_partitioning_class. (lto_output_varpool_node): likewise. (symtab_get_symbol_partitioning_class): Move here from lto/lto-partition.c * cgraph.h (symbol_partitioning_class): Likewise. (symtab_get_symbol_partitioning_class): Declare. Modified: trunk/gcc/symtab.c
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #48 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 7 02:27:37 2014 New Revision: 207590 URL: http://gcc.gnu.org/viewcvs?rev=207590root=gccview=rev Log: PR ipa/59469 * lto-cgraph.c (lto_output_node): Use symtab_get_symbol_partitioning_class. (lto_output_varpool_node): likewise. (symtab_get_symbol_partitioning_class): Move here from lto/lto-partition.c * cgraph.h (symbol_partitioning_class): Likewise. (symtab_get_symbol_partitioning_class): Declare. Modified: trunk/gcc/ChangeLog
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #20 from Jouko Orava jouko.orava at iki dot fi --- Apologies, Jacob; my advice was faulty. Could you please retest using the following? Compile the binary using gfortran -march=native -ggdb newtest.f90 -o newtest then start gdb, gdb newtest and run until the segfault: (gdb) run At the segfault, list the registers, (gdb) info registers to verify that %edi is still not 16-byte aligned (last hex digit is nonzero). Check the backtrace, (gdb) bt noting the #0 address. Let's say it is 0x6f610f4e. Substract about 0x40 or so from that address, and show the disassembly from that point forwards, using (gdb) disassemble 0x6f610f1e,+100 That should include the segfault address. (In some cases you may need to move the start address by one to five bytes, so that it starts at the correct instruction boundary.) Then, if you could restart the gdb session, and set a breakpoint at the address after the 'call' instruction before the segfault point. Say the line after the 'call' instruction is 0x6f619f2c, then you'd use (gdb) break *0x6f610f2c (gdb) run (gdb) info registers The interesting thing here is the %eax value. If it does end with 8, it means the __libc_malloc call returned a non-aligned memory chunk, and that the generated code did not expect that at all. If not, my theory is incorrect. However, if the above checks out, it means this really is a memory alignment issue, where __libc_malloc() returns a 8-byte-aligned chunk whereas a 16-byte-aligned chunk was expected.
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Conrad conradsand.arma at gmail dot com changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #1 from Conrad conradsand.arma at gmail dot com --- It would be a good idea to post this to the gcc-patches mailing list. See http://gcc.gnu.org/lists.html
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377 --- Comment #11 from Andrey Belevantsev abel at gcc dot gnu.org --- (In reply to fabien from comment #10) The testcase is not valid, as a using declaration shall refer to a direct base class, which is not the case in 'using ns::Base::i' (the namespace ns does not seem to be relevant here). It is invalid for a second reason, 'using Base::i' is declared (implicitly) in a private section, so inaccessible in DerivedDerived. Thank you for clarification, we weren't 100% sure whether this is a bug but decided in favor of it because of icc/clang results... It's 9 years of the original bugreport, maybe rise a priority?.. Raising the priority would not make me fix this bug more quickly. This bug is not a regression, and not a high priority in my opinion. Thought, it is in my TODO list. I gave it a try two years ago, and it was not obvious to fix. Feel free to take over if you have more free time than I have. And sorry for the noise here, I just thought that having another test would help with fixing the issue but of course the invalid test does not help.
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918
--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org ---
This is just over-active sanity check
Index: ipa-devirt.c
===
--- ipa-devirt.c (revision 207588)
+++ ipa-devirt.c (working copy)
@@ -689,10 +689,7 @@ record_target_from_binfo (vec cgraph_no
we may not have its associated vtable. This is not a problem, since
we will walk it on the other path. */
if (!type_binfo)
- {
- gcc_assert (BINFO_VIRTUAL_P (binfo));
- return;
- }
+ return;
tree inner_binfo = get_binfo_at_offset (type_binfo,
offset, otr_type);
/* For types in anonymous namespace first check if the respective vtable
Are we getting to end of the non-invalid code ipa-devirt ICEs? :)
[Bug c/60103] Spurious -Wsequence-point warning with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103 --- Comment #2 from Chengnian Sun chengniansun at gmail dot com --- (In reply to Andrew Pinski from comment #1) I think C11 and C90/C99 have a different idea here. There is a relative sequence point between the function call fn2 and the 0 but there is no sequence point between the two assignments I think. Sequence points are not my area of expertise so I could be wrong but I do know that C11/C++11 does get rid of the idea of sequence points and change the name of it to something else. Thanks Andrew. After checking the standard, I see your point here. If the warning is not spurious, then IMHO gcc should also warn this with -O0.
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Feb 7 06:01:36 2014 New Revision: 207592 URL: http://gcc.gnu.org/viewcvs?rev=207592root=gccview=rev Log: PR ipa/59918 * ipa-devirt.c (record_target_from_binfo): Remove overactive sanity check. * g++.dg/torture/pr59918.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr59918.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 --- Comment #21 from Jouko Orava jouko.orava at iki dot fi --- This bug is a duplicate of #55916.
[Bug preprocessor/56824] [4.8/4.9 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored -Waggregate-return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824 --- Comment #9 from Magnus Reftel magnus.reftel at gmail dot com --- Thanks for the patch! I applied it on top of 53c3c39b96df9c6a6368bf0d6acfd28a7af3cb63 and tested. Without the patch, the error was still printed when compiling the testcase. With the patch, the error was not printed. Removing the #pragma GCC diagnostic ignored made the error print again, as expected. The fix is thus working as it should on the testcase. I no longer have access to the code base where the problem was discovered, so I guess this verification will have to do. I'm not sure what the criteria for updating the status field are, though, so I leave it at ASSIGNED.
[Bug target/40977] [4.7/4.8/4.9 regression] problem with code like this: res = ((uint64_t)resh 32) | resl;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-07
CC||law at redhat dot com
Known to work||
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
Known to fail||
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
The current trunk looks better than gcc-4.4, but it's still not as good as
gcc-3.4
After reload the key insns like this:
(insn 25 24 28 6 (set (reg:DI 0 %d0 [orig:47 D.1386 ] [47])
(ashift:DI (zero_extend:DI (reg/v:SI 8 %a0 [orig:31 resh ] [31]))
(const_int 32 [0x20]))) l.c:54 302 {ashldi_extsi}
(nil))
(note 28 25 43 6 NOTE_INSN_DELETED)
(insn 43 28 44 6 (set (reg:SI 0 %d0)
(reg:SI 0 %d0 [ D.1386 ])) l.c:57 39 {*movsi_m68k2}
(nil))
(insn 44 43 36 6 (set (reg:SI 1 %d1 [orig:0+4 ] [0])
(reg:SI 6 %d6 [orig:44 resl ] [44])) l.c:57 39 {*movsi_m68k2}
(nil))
You can safely ignore insn 43, it'll get zapped because it's a NOP.
The key here is to realize that insn 25 generates two instructions, one which
sets d0, the other sets d1. The instruction setting d1 is dead as that value
will be overwritten by the instruction generated for insn 44. But GCC is
particularly bad at discovering and exploiting these kind of situations.
This can be fixed by changing ashldi_extsi from a define_insn into a suitable
define_insn_and_split which will decompose the insn into its component parts.
That gets us something like this:
(insn 49 24 50 6 (set (reg:SI 0 %d0 [ D.1386 ])
(reg/v:SI 8 %a0 [orig:31 resh ] [31])) l.c:54 38 {*movsi_m68k}
(nil))
(insn 50 49 28 6 (set (reg:SI 1 %d1 [orig:47 D.1386+4 ] [47])
(const_int 0 [0])) l.c:54 36 {*movsi_const0_68040_60}
(nil))
(note 28 50 44 6 NOTE_INSN_DELETED)
(insn 44 28 36 6 (set (reg:SI 1 %d1 [orig:0+4 ] [0])
(reg:SI 6 %d6 [orig:44 resl ] [44])) l.c:57 39 {*movsi_m68k2}
(nil))
Now the double-word set originally associated with insn 25 is represented by
insns 49 and 50. And we're in a form that the DCE code can easily digest and
determine that insn 50 is dead. This results in:
(insn 49 24 28 6 (set (reg:SI 0 %d0 [ D.1386 ])
(reg/v:SI 8 %a0 [orig:31 resh ] [31])) l.c:54 38 {*movsi_m68k}
(expr_list:REG_DEAD (reg/v:SI 8 %a0 [orig:31 resh ] [31])
(nil)))
(note 28 49 44 6 NOTE_INSN_DELETED)
(insn 44 28 36 6 (set (reg:SI 1 %d1 [orig:0+4 ] [0])
(reg:SI 6 %d6 [orig:44 resl ] [44])) l.c:57 39 {*movsi_m68k2}
(expr_list:REG_DEAD (reg:SI 6 %d6 [orig:44 resl ] [44])
Which is, much better.
The final assembly code looks like:
MUL64:
movem.l #15872,-(%sp)
move.l 24(%sp),%a1
move.l 28(%sp),%d5
#APP
| 47 l.c 1
| Inlined umul_ppmm
move.l %a1,%d0
move.l %d5,%d1
move.l %d0,%d2
swap%d0
move.l %d1,%d3
swap%d1
move.w %d2,%d4
mulu%d3,%d4
mulu%d1,%d2
mulu%d0,%d3
mulu%d0,%d1
move.l %d4,%d0
eor.w %d0,%d0
swap%d0
add.l %d0,%d2
add.l %d3,%d2
jcc 1f
add.l #65536,%d1
1: swap%d2
moveq #0,%d0
move.w %d2,%d0
move.w %d4,%d2
move.l %d2,%d6
add.l %d1,%d0
move.l %d0,%a0
#NO_APP
tst.l %a1
jlt .L6
tst.l %d5
jlt .L7
.L3:
move.l %a0,%d0
move.l %d6,%d1
movem.l (%sp)+,#124
rts
.L7:
sub.l %a1,%a0
move.l %a0,%d0
move.l %d6,%d1
movem.l (%sp)+,#124
rts
.L6:
sub.l %d5,%a0
tst.l %d5
jge .L3
jra .L7
Which should be as good as or better than the gcc-3.4 code, with the possible
exception of codesize. But the compiler has tried to optimize the most likely
path through the function (neither argument is negative). As a result we have
a bit of tail duplication.
[Bug c++/60105] New: [C++11] g++ segfault on enable_if explicit cast operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60105
Bug ID: 60105
Summary: [C++11] g++ segfault on enable_if explicit cast
operator
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Andrey.E.Antipov at gmail dot com
g++ segfaults on enable_if explicit cast operator.
The code below crashes on gcc-4.8.2 on a mac with
$ g++-4.8 a.cpp -std=c++11 -o ./a
a.cpp: In function 'int main()':
a.cpp:16:18: internal compiler error: Segmentation fault: 11
std::cout std::endl; // This causes a crash
^
a.cpp:16:18: internal compiler error: Abort trap: 6
g++-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
---
#include iostream
#include type_traits
template typename V
struct subclass {
template typename V2 = V,
typename = typename
std::enable_if!std::is_sameV2,int::value::type
explicit operator int(){return 1;};
operator V(){return 2.;}
friend std::ostream operator(std::ostreamout, const subclass p){out
3; return out;}
};
int main()
{
subclassint ;
subclassdouble ;
std::cout std::endl; // This causes a crash
std::cout std::endl;
std::cout int() std::endl;
std::cout int() std::endl;
}
-
Commenting out the std::cout std::endl or removing explicit
keyword results in successful compilation and 3
3
2
1
output as expected.
g++-4.8 is
$ g++-4.8 -v
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc48/4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/lto-wrapper
Target: x86_64-apple-darwin13.0.0
Configured with: ../configure --build=x86_64-apple-darwin13.0.0
--prefix=/usr/local/Cellar/gcc48/4.8.2 --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp4
--with-mpfr=/usr/local/opt/mpfr2 --with-mpc=/usr/local/opt/libmpc08
--with-cloog=/usr/local/opt/cloog018 --with-isl=/usr/local/opt/isl011
--with-system-zlib --enable-version-specific-runtime-libs
--enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release
--enable-lto --disable-werror --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug c++/60106] New: ICE in g++.dg/gomp/pr59150.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106 Bug ID: 60106 Summary: ICE in g++.dg/gomp/pr59150.C Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/g++/../../xg++ -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/g++/../../ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/g++.dg/gomp/pr59150.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include -I/home/ed/gnu/gcc-4.9-20140202/libstdc++-v3/libsupc++ -I/home/ed/gnu/gcc-4.9-20140202/libstdc++-v3/include/backward -I/home/ed/gnu/gcc-4.9-20140202/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -O -fopenmp-simd -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce -S -o pr59150.s^M *** glibc detected *** /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/g++/../../cc1plus: double free or corruption (fasttop): 0x0117e7a0 ***^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/g++.dg/gomp/pr59150.C: In function 'int foo()':^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/g++.dg/gomp/pr59150.C:8:1: internal compiler error: Aborted^M 0x76722f crash_signal^M ../../gcc-4.9-20140202/gcc/toplev.c:337^M
