[Bug sanitizer/65749] New: sanitizer stack trace pc off by 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
Bug ID: 65749
Summary: sanitizer stack trace pc off by 1
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
The PC printed in sanitizer stack traces is consistently off by 1. Either off
by 1 byte, or by 1 instruction, depending on the target. The problem can be
seen in any stack trace, including the one below.
The StackTrace::Print() function in
libsanitizer/sanitizer_common/sanitizer_stacktrace_libcdep.cc computes the PC
to include in the backtrace like so:
// PCs in stack traces are actually the return addresses, that is,
// addresses of the next instructions after the call.
uptr pc = GetPreviousInstructionPc(trace[i]);
GetPreviousInstructionPc() simply returns its argument decremented by the width
of the smallest instruction on a target, or 4 on powerpc and 1 on x86_64.
This computation is incorrect because it results in PC values that don't match
up with either the faulting address in the case of the active frame, or with
the address of either the subsequent instruction that would have been executed
had the faulting function returned to the caller or with the call instruction
(on x86_64).
As a side effect of this defect the sanitizer stack trace also sometimes lists
different line numbers (for programs compiled with -g) than GDB (and than is
recorded in the DWARF line program).
$ cat -n t.c ./gcc/xgcc -Bgcc
-L$PWD/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -O2 -fno-builtin-memset
-fsanitize=address -g t.c
LD_LIBRARY_PATH=$PWD/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs ./a.out;
LD_LIBRARY_PATH=$PWD/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs gdb
-batch -ex r -ex 'x/1i $pc' -ex bt -quiet a.out
1void __attribute__ ((weak)) foo (int *p)
2{
3*p = 0xdeadbeef;
4}
5
6void __attribute__ ((weak)) bar (int *p)
7{
8int a;
9foo (a);
10
11foo (p);
12}
13
14int main (void)
15{
16bar (0);
17
18return 0;
19}
20
ASAN:SIGSEGV
=
==7883==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x004007ef bp 0x0bc4 sp 0x7fffde18 T0)
#0 0x4007ee in foo /build/gcc-65479/t.c:2
#1 0x400869 in bar /build/gcc-65479/t.c:11
#2 0x4006ba in main /build/gcc-65479/t.c:16
#3 0x76ad3fdf in __libc_start_main (/lib64/libc.so.6+0x1ffdf)
#4 0x4006fd (/home/msebor/build/gcc-65479/a.out+0x4006fd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/gcc-65479/t.c:2 foo
==7883==ABORTING
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Program received signal SIGSEGV, Segmentation fault.
0x004007ef in foo (p=p@entry=0x0) at t.c:3
3*p = 0xdeadbeef;
= 0x4007ef foo+31:movl $0xdeadbeef,(%rdi)
#0 0x004007ef in foo (p=p@entry=0x0) at t.c:3
#1 0x0040086a in bar (p=p@entry=0x0) at t.c:11
#2 0x004006bb in main () at t.c:16
[Bug c++/65750] New: miss interpret in a virtual member function with a C++11 style function signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65750
Bug ID: 65750
Summary: miss interpret in a virtual member function with a
C++11 style function signature
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: usagi at WonderRabbitProject dot net
Repro:
#include functional
class a
{
virtual auto f( std::function void () ) - void;
virtual auto g( std::function auto () - void ) - void;
};
auto main() - int { }
Result 1 ( g++-5.0.0, 4.9.2 and = 4.9.0 ):
prog.cc:6:16: error: implicit templates may not be 'virtual'
virtual auto g( std::function auto () - void ) - void;
Result 2 ( g++-4.8.2, g++4.7.3 ):
(no errors, compile is succeed.)
Result 3 ( clang++-3.7.0, 3.6.0, 3.5.0 and 3.4 )
(no errors, compile is succeed.)
[Bug target/65710] [4.9/5 Regression] Thumb1 ICE caused by no register to spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710 --- Comment #31 from xuepeng guo xguo at gcc dot gnu.org --- Author: xguo Date: Mon Apr 13 05:22:09 2015 New Revision: 222037 URL: https://gcc.gnu.org/viewcvs?rev=222037root=gccview=rev Log: Add missing test case 2015-04-13 Terry Guo terry@arm.com PR target/65710 * gcc.target/arm/pr65710.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr65710.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/57533] When throwing local variable, it's being move-constructed even if not going out of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 65748 has been marked as a duplicate of this bug. ***
[Bug c++/65748] [C++11][C++14]Invalid copy elision on operand of throw-exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65748 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Already reported (three times). *** This bug has been marked as a duplicate of bug 57533 ***
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Depends on||65749 --- Comment #7 from Martin Sebor msebor at gcc dot gnu.org --- I forgot to mention that there is yet another bug here that's complicating things. I was initially going to describe it here but since it's independent of this problem I decided to open a separate bug: pr65749. The complication is that a patch for this bug that produces the expected results on POWER (i.e., passes all sanitizer tests) breaks at least one test on x86_64 because of the incorrect computation of the PC value in libsanitizer/sanitizer_common/sanitizer_stacktrace_libcdep.cc.
[Bug sanitizer/64078] FAIL: c-c++-common/ubsan/object-size-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078 --- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de --- The same could happen also with object-size-10.c: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01293.html FAIL: c-c++-common/ubsan/object-size-10.c -O2 execution test FAIL: c-c++-common/ubsan/object-size-10.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test I can't reproduce that one, but it may possibly also be a pointer value too close to a page boundary?
[Bug fortran/58754] [4.8/4.9/5 Regression] ICE on allocating character array with source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- This fixes the problem. Confirmed. However, it will produce multiple evaluations of function results and expressions. I will introduce a temporary to cover those cases. Is it obvious? PS It's a pity I did not clock this before the RC! No RC yet!
[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089
--- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This patch resolves the -fsanitize=address issue and also does some memory
cleanup on formatted I/O errors. I have regression tested and all is OK, but
have not tried all the variations with -m32 or -fsanitize=address on the
testsuite.
The patch looks good (even for my limited understanding of the code). I have
run the fortran test suite with
check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32,-m64,-m32/-fsanitize=address,-m64/-fsanitize=address}'
The io_real_boz* problem is fixed without new regression. I have also
sanitized the NIST test suite which runs without error for both -m32 and
-m64.
Thanks for working on this issue.
[Bug fortran/59997] c_pointer = c_loc(...) internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59997
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I am confused by the comments 5 to 7, probably because my comment 4 was
confusing.
What I have tested is 4.8.5 with the patch for fortran/trans-expr.c plus the
additional tests
diff -upN ../4.8_clean/gcc/testsuite/gfortran.dg/c_loc_test_20.f90
gcc/testsuite/gfortran.dg/c_loc_test_20.f90
--- ../4.8_clean/gcc/testsuite/gfortran.dg/c_loc_test_20.f901970-01-01
01:00:00.0 +0100
+++ gcc/testsuite/gfortran.dg/c_loc_test_20.f902013-03-25
18:07:07.0 +0100
@@ -0,0 +1,34 @@
+! { dg-do run }
+!
+! PR fortran/38829
+! PR fortran/40963
+! PR fortran/38813
+!
+!
+program testcloc
+use, intrinsic :: iso_c_binding
+implicit none
+
+type obj
+real :: array(10,10)
+real, allocatable :: array2(:,:)
+end type
+
+type(obj), target :: obj1
+type(c_ptr) :: cptr
+integer :: i
+real, pointer :: array(:)
+
+allocate (obj1%array2(10,10))
+obj1%array = reshape ([(i, i=1,100)], shape (obj1%array))
+obj1%array2 = reshape ([(i, i=1,100)], shape (obj1%array))
+
+cptr = c_loc (obj1%array)
+call c_f_pointer (cptr, array, shape=[100])
+if (any (array /= [(i, i=1,100)])) call abort ()
+
+cptr = c_loc (obj1%array2)
+call c_f_pointer (cptr, array, shape=[100])
+if (any (array /= [(i, i=1,100)])) call abort ()
+end program testcloc
+
diff -upN ../4.8_clean/gcc/testsuite/gfortran.dg/pr59997.f90
gcc/testsuite/gfortran.dg/pr59997.f90
--- ../4.8_clean/gcc/testsuite/gfortran.dg/pr59997.f901970-01-01
01:00:00.0 +0100
+++ gcc/testsuite/gfortran.dg/pr59997.f902015-04-11 11:00:43.0
+0200
@@ -0,0 +1,29 @@
+! { dg-do compile }
+
+program test
+use iso_c_binding
+implicit none
+
+interface
+function cfun(a) ! should be subroutine if saythis returns void
+import :: c_ptr
+type(c_ptr), value :: a
+end function cfun
+end interface
+
+
+type scratch
+character(c_char) :: c_line(11)
+end type
+type(scratch), target :: X
+type(c_ptr) :: c_string_ptr
+character(10) :: line
+integer cerr ;
+
+line = 'my text'
+X%c_line = line
+X%c_line(11) = c_null_char
+c_string_ptr = c_loc(X%c_line)
+cerr = cfun(c_string_ptr);
+write (*,*) cerr= , cerr ;
+end program
gfortran.dg/pr59997.f90 is a small modified version of the test proposed in
comment 3. This test can only be compiled because cfun is not present. If you
want to extend the test to run it, you should have a look at the several tests
checking the C/Fortran interoperability, e.g., gfortran.dg/c_ptr_tests*.
gfortran.dg/c_loc_test_20.f90 is a copy of the test found in the 4.9 branch or
in trunk. I have checked that compiling this test with a clean 4.8.5 gives an
ICE while the test compiles and runs with the patch.
[Bug libfortran/65234] Output descriptor (*(1E15.7)) not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65234 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This patch passes regression testing and NIST testing. Fairly simple. Works as advertised! Thanks.
[Bug c++/65748] [C++11][C++14]Invalid copy elision on operand of throw-exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65748 --- Comment #1 from frankhb1989 at gmail dot com --- G++ 5 also seems to fail. Recent Clang++ is OK.
[Bug lto/65746] New: [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65746 Bug ID: 65746 Summary: [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux/x86-64, r222001 miscompiled 450.soplex in SPEC CPU 2006: Running 450.soplex ref base lto default 450.soplex: copy 0 non-zero return code (exit code=11, signal=0) r221961 is OK.
[Bug c++/65748] New: [C++11][C++14]Invalid copy elision on operand of throw-exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65748
Bug ID: 65748
Summary: [C++11][C++14]Invalid copy elision on operand of
throw-exception
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
struct E
{
E() = default;
E(const E) = delete;
E(E) = default;
};
int main()
{
E e;
try
{
// E e; // Not here.
throw e;
}
catch(...)
{}
}
No diagnostics with g++ -std=c++14 -pedantic -Wall -Wextra. Same to -std=c++11.
It seems the move constructor is selected according to 12.8/32, which depends
on copy elision.
However, both ISO C++11 and C++14 forbid copy elision in this case, i.e. for
operand of throw-expression, it may be elided only when:
whose scope does not extend beyond the end of the innermost enclosing try-block
(if there is one)
as per 12.8/31.2.
[Bug target/65744] New: Some AVX512 instrinsics take __mmask16 instead of __mmask8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65744
Bug ID: 65744
Summary: Some AVX512 instrinsics take __mmask16 instead of
__mmask8
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
Compiling with -Wsystem-headers, I got the following warnings, which seem to
point at a few mistakes (the intrinsic prototypes don't quite match Intel's
documentation). I don't believe it can cause any problem, but we should still
fix it.
usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlintrin.h:
In function '__m128i _mm_mask_mullo_epi32(__m128i, __mmask16, __m128i,
__m128i)':
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlintrin.h:9050:26:
warning: conversion to 'char' from '__mmask16 {aka short unsigned int}' may
alter its value [-Wconversion]
(__v4si) __W, __M);
^
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlbwintrin.h:
In function '__m128i _mm_mask_packus_epi32(__m128i, __mmask16, __m128i,
__m128i)':
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlbwintrin.h:4314:28:
warning: conversion to 'char' from '__mmask16 {aka short unsigned int}' may
alter its value [-Wconversion]
(__v8hi) __W, __M);
^
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlbwintrin.h:
In function '__m128i _mm_mask_packs_epi32(__m128i, __mmask16, __m128i,
__m128i)':
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/5.0.0/include/avx512vlbwintrin.h:4357:28:
warning: conversion to 'char' from '__mmask16 {aka short unsigned int}' may
alter its value [-Wconversion]
(__v8hi) __W, __M);
^
[Bug lto/65745] New: [5 Regression] lto ICE (Segmentation fault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65745 Bug ID: 65745 Summary: [5 Regression] lto ICE (Segmentation fault) on powerpc64le-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with the same package as in PR58528 (apt-cacher-ng), the work around using -g0 still applies. for now powerpc64le-linux-gnu only. works with 4.9 branch. object files at http://people.canonical.com/~doko/tmp/obj.tar.gz g++ -g -O3 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -flto -Wl,--as-needed CMakeFiles/apt-cacher-ng.dir/source/filelocks.cc.o CMakeFiles/apt-cacher-ng.dir/source/mirror.cc.o CMakeFiles/apt-cacher-ng.dir/source/dirwalk.cc.o CMakeFiles/apt-cacher-ng.dir/source/bgtask.cc.o CMakeFiles/apt-cacher-ng.dir/source/acfg.cc.o CMakeFiles/apt-cacher-ng.dir/source/cacheman.cc.o CMakeFiles/apt-cacher-ng.dir/source/expiration.cc.o CMakeFiles/apt-cacher-ng.dir/source/acfg_defaults.cc.o CMakeFiles/apt-cacher-ng.dir/source/meta.cc.o CMakeFiles/apt-cacher-ng.dir/source/pkgimport.cc.o CMakeFiles/apt-cacher-ng.dir/source/caddrinfo.cc.o CMakeFiles/apt-cacher-ng.dir/source/conn.cc.o CMakeFiles/apt-cacher-ng.dir/source/rfc2553emu.cc.o CMakeFiles/apt-cacher-ng.dir/source/acbuf.cc.o CMakeFiles/apt-cacher-ng.dir/source/cleaner.cc.o CMakeFiles/apt-cacher-ng.dir/source/dlcon.cc.o CMakeFiles/apt-cacher-ng.dir/source/filereader.cc.o CMakeFiles/apt-cacher-ng.dir/source/apt-cacher.cc.o CMakeFiles/apt-cacher-ng.dir/source/aclogger.cc.o CMakeFiles/apt-cacher-ng.dir/source/job.cc.o CMakeFiles/apt-cacher-ng.dir/source/fileio.cc.o CMakeFiles/apt-cacher-ng.dir/source/tcpconnect.cc.o CMakeFiles/apt-cacher-ng.dir/source/showinfo.cc.o CMakeFiles/apt-cacher-ng.dir/source/conserver.cc.o CMakeFiles/apt-cacher-ng.dir/source/header.cc.o CMakeFiles/apt-cacher-ng.dir/source/maintenance.cc.o CMakeFiles/apt-cacher-ng.dir/source/fileitem.cc.o CMakeFiles/apt-cacher-ng.dir/source/lockable.cc.o lto1: internal compiler error: Segmentation fault 0x1070b9d3 crash_signal ../../src/gcc/toplev.c:383 0x10e97df0 htab_hash_string ../../src/libiberty/hashtab.c:834 Please submit a full bug report, with preprocessed source if appropriate. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapper Target: powerpc64le-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5-20150410-0ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-ppc64el --with-arch-directory=ppc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8 --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=yes --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu Thread model: posix gcc version 5.0.0 20150410 (experimental) [trunk revision 221996] (Ubuntu 5-20150410-0ubuntu11)
[Bug middle-end/65747] New: [5 Regression] ICE (in compare_ssa_name, at ipa-icf-gimple.c:134) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65747
Bug ID: 65747
Summary: [5 Regression] ICE (in compare_ssa_name, at
ipa-icf-gimple.c:134) on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Created attachment 35303
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35303action=edit
preprocessed source
seen building the DCE VM for OpenJDK 7 (openjdk-7-dcevm package)
$ g++ -c -g -O2 assembler_x86.ii
assembler_x86.ii:53:1: internal compiler error: in compare_ssa_name, at
ipa-icf-gimple.c:134
}
^
0x12fc510 ipa_icf_gimple::func_checker::compare_ssa_name(tree_node*,
tree_node*)
../../src/gcc/ipa-icf-gimple.c:134
0x12fd53c ipa_icf_gimple::func_checker::compare_operand(tree_node*, tree_node*)
../../src/gcc/ipa-icf-gimple.c:524
0x12fe6fb ipa_icf_gimple::func_checker::compare_gimple_call(gcall*, gcall*)
../../src/gcc/ipa-icf-gimple.c:766
0x12ff6ee ipa_icf_gimple::func_checker::compare_bb(ipa_icf_gimple::sem_bb*,
ipa_icf_gimple::sem_bb*)
../../src/gcc/ipa-icf-gimple.c:691
0x12ecd62 ipa_icf::sem_function::equals_private(ipa_icf::sem_item*,
hash_mapsymtab_node*, ipa_icf::sem_item*, default_hashmap_traits)
../../src/gcc/ipa-icf.c:757
0x12ed1f3 ipa_icf::sem_function::equals_private(ipa_icf::sem_item*,
hash_mapsymtab_node*, ipa_icf::sem_item*, default_hashmap_traits)
../../src/gcc/ipa-icf.c:653
0x12ed1f3 ipa_icf::sem_function::equals(ipa_icf::sem_item*,
hash_mapsymtab_node*, ipa_icf::sem_item*, default_hashmap_traits)
../../src/gcc/ipa-icf.c:654
0x12eddf2 ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
../../src/gcc/ipa-icf.c:2657
0x12f8eec ipa_icf::sem_item_optimizer::execute()
../../src/gcc/ipa-icf.c:2421
0x12fa8e6 ipa_icf_driver
../../src/gcc/ipa-icf.c:3306
0x12fa8e6 ipa_icf::pass_ipa_icf::execute(function*)
../../src/gcc/ipa-icf.c:3353
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat assembler_x86.ii
class A {
public:
enum relocType {};
};
class B {
enum {} _relocbuf[];
public:
A::relocType m_fn1() const;
};
class Relocation {
public:
virtual A m_fn2();
} *a;
class C {
B _rspec;
void m_fn3() { _rspec.m_fn1(); }
friend class D;
};
class D {
int m_fn4(C);
void m_fn5();
void m_fn6(int, C);
void m_fn7(int, C);
void m_fn8();
bool m_fn9();
void m_fn10(int);
void m_fn11(int);
};
A::relocType B::m_fn1() const {
a = (Relocation *)_relocbuf;
a-m_fn2();
}
void D::m_fn10(int) { m_fn8(); }
void D::m_fn11(int) { m_fn8(); }
int D::m_fn4(C p1) { p1.m_fn3(); }
void D::m_fn6(int, C p2) {
int b;
if (m_fn9()) {
m_fn4(p2);
m_fn10(b);
} else
m_fn5();
m_fn10(int());
}
void D::m_fn7(int, C p2) {
int c;
if (m_fn9()) {
m_fn4(p2);
m_fn11(c);
} else
m_fn5();
m_fn11(int());
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5-20150410-0ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-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=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.0.0 20150410 (experimental) [trunk revision 221996] (Ubuntu
5-20150410-0ubuntu11)
[Bug middle-end/65747] [5 Regression] ICE (in compare_ssa_name, at ipa-icf-gimple.c:134) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65747 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35304 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35304action=edit gcc5-pr65747.patch Untested fix. Honza, does this make sense?
[Bug middle-end/65747] [5 Regression] ICE (in compare_ssa_name, at ipa-icf-gimple.c:134) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65747 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-12 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r221086.
[Bug lto/65745] [5 Regression] lto ICE (Segmentation fault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65745 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup of PR65549 ?
[Bug lto/65746] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65746 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is a hardware issue.
[Bug inline-asm/65741] Missed loop optimization with asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65741 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-12 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- Confirmed. If not using an asm but, say, a simple assignment, cddce1 gets rid of the loop. Moving the asm outside of the loop isn't done at tree level, but only by the RTL opts. Most RTL opts can only deal with single sets, which explains why your multiple-output asm isn't optimised as well as you'd like.
[Bug c++/65736] [5 Regression] ICE (in process_init_constructor_array, at cp/typeck2.c:1263)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65736 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sun Apr 12 19:10:58 2015 New Revision: 222022 URL: https://gcc.gnu.org/viewcvs?rev=222022root=gccview=rev Log: PR c++/65736 * constexpr.c (cxx_eval_pointer_plus_expression): Don't fold for VLAs, don't fold if op01 isn't divisible by TYPE_SIZE_UNIT. Convert the expression to the original type at the end. * g++.dg/cpp0x/pr65736.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr65736.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/65735] [5 Regression] ICE (in duplicate_thread_path, at tree-ssa-threadupdate.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65735 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/65736] [5 Regression] ICE (in process_init_constructor_array, at cp/typeck2.c:1263)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65736 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug middle-end/65747] [5 Regression] ICE (in compare_ssa_name, at ipa-icf-gimple.c:134) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65747 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sun Apr 12 19:30:51 2015 New Revision: 222024 URL: https://gcc.gnu.org/viewcvs?rev=222024root=gccview=rev Log: PR tree-optimization/65747 * ipa-icf-gimple.c (func_checker::compare_operand): Use compare_operand rather than compare_ssa_name for OBJ_TYPE_REF_OBJECT. * g++.dg/torture/pr65747.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr65747.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/65747] [5 Regression] ICE (in compare_ssa_name, at ipa-icf-gimple.c:134) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65747 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug middle-end/65686] [4.9 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added Summary|incorrect warning |[4.9 regression] |maybe-uninitialized |inconsistent warning ||maybe-uninitialized: warn ||about 'unsigned', not warn ||about 'int' --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com --- gcc version 4.9.3 20150412 (prerelease) [gcc-4_9-branch revision 222021] (GCC) PASS
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to François Dumont from comment #2)
So yes it doubles the number of comparisons which is definitely a
Well actually your patch doesn't double the number, because you only do the
reverse check when the first check returns true.
performance hint but your patch on the other hand expect to detect an
implementation issue on only 1 use case so it can miss many kind of wrong
implementation on special instances.
The most common mistake I want this to detect is simply trying to define
something equivalent to operator= instead of operator (see PR 59391 that I
linked to) and that will be detected for every value, so you only need to check
the first one. i.e. I want to check for irreflexivity.
Your patch checks for antisymmetry instead, which is also required for a strict
weak order, but is a different property.
Checking for antisymmetry is necessary to check broken orders like this:
bool cmp(const pairint,int l, const pairint,int r)
{ return l.first r.first || l.second r.second; }
Your patch also only works for C++11, but there's no reason this shouldn't work
for C++03 too. Which algorithms benefit from handling heterogeneous types in
these checks?
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 --- Comment #2 from François Dumont fdumont at gcc dot gnu.org --- Created attachment 35305 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35305action=edit Strict weak ordering debug check patch On my side here what I had plan to do. This patch rely on additional feature in the _Formatter type to pass a type or iterator value_type to point the user to the invalid operator or functor. It also do not perform the check if the comparator is not able to handle it. So yes it doubles the number of comparisons which is definitely a performance hint but your patch on the other hand expect to detect an implementation issue on only 1 use case so it can miss many kind of wrong implementation on special instances.
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #3) Your patch checks for antisymmetry instead, which is also required for a strict weak order, but is a different property. Maybe we want both, because the irreflexivity check can be done very cheaply, so is suitable for the Debug Mode Lite I've talked about, but the antisymmetry check is more expensive.
[Bug ipa/65701] [5/6 Regression] r221530 makes 187.facerec drop with -Ofast -flto on bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65701 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org --- However the spec score seems to indicate that well over half of the performance gap is gone by the vectorizer change. Good ;)
