[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev ---
This optimization is still missing in current trunk:
$ cat ./test.cc
struct A
{
int j;
};
struct B : public virtual A
{
};
struct C final : public B
{
int get();
};
int C::get()
{
return A::j;
}
$ /opt/gcc-5.0.0/bin/g++ -O -std=c++11 -c -S ./test.cc -o test_gcc.s && cat
./test_gcc.s
.file "test.cc"
.text
.align 2
.globl _ZN1C3getEv
.type _ZN1C3getEv, @function
_ZN1C3getEv:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
movq-24(%rax), %rax
movl(%rdi,%rax), %eax
ret
.cfi_endproc
.LFE0:
.size _ZN1C3getEv, .-_ZN1C3getEv
.ident "GCC: (GNU) 5.0.0 20150315 (experimental)"
.section.note.GNU-stack,"",@progbits
(Note: optimization flags like -O3 and -fdevirtualize-speculatively don't
affect this behavior; neither method calls nor data member accesses get
devirtualized)
$ clang++ -O -std=c++11 -c -S ./test.cc -o test_clang.s && cat ./test_clang.s
.text
.file "./test.cc"
.globl _ZN1C3getEv
.align 16, 0x90
.type _ZN1C3getEv,@function
_ZN1C3getEv:# @_ZN1C3getEv
.cfi_startproc
# BB#0: # %entry
movl8(%rdi), %eax
retq
.Ltmp0:
.size _ZN1C3getEv, .Ltmp0-_ZN1C3getEv
.cfi_endproc
.ident "clang version 3.7.0 (trunk 228487)"
.section".note.GNU-stack","",@progbits
So, I can confirm it in sense "reproduce" (I don't have a right to change the
status of PR)
[Bug ipa/65432] New: [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 Bug ID: 65432 Summary: [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Running the testsuite on ppc64le with an --enable-checking=valgrind compiler shows many instances of: ==94166== Invalid read of size 1 ==94166==at 0x40980F8: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==94166==by 0x4626503: vfprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so) ==94166==by 0x4631003: fprintf@@GLIBC_2.17 (in /usr/lib64/libc-2.20.so) ==94166==by 0x10CF34B3: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) ==94166==by 0x10CF962B: ipa_icf::sem_item_optimizer::execute() (ipa-icf.c:2236) ==94166==by 0x10CFC8DF: ipa_icf_driver (ipa-icf.c:3060) ==94166==by 0x10CFC8DF: ipa_icf::pass_ipa_icf::execute(function*) (ipa-icf.c:3107) ==94166==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==94166==by 0x10690B53: execute_ipa_pass_list(opt_pass*) (passes.c:2727) ==94166==by 0x1038D2DF: ipa_passes (cgraphunit.c:2207) ==94166==by 0x1038D2DF: symbol_table::compile() (cgraphunit.c:2295) ==94166==by 0x1038ED47: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) ==94166==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==94166==by 0x1076894F: compile_file() (toplev.c:608) ==94166== Address 0x701ee20 is 0 bytes inside a block of size 38 free'd ==94166==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==94166==by 0x10243CAF: cxx_printable_name_internal(tree_node*, int, bool) (tree.c:2026) ==94166==by 0x10374D23: symtab_node::name() const (symtab.c:479) ==94166==by 0x10CF3497: name (ipa-icf.h:177) ==94166==by 0x10CF3497: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958) ==94166==by 0x10CF962B: ipa_icf::sem_item_optimizer::execute() (ipa-icf.c:2236) ==94166==by 0x10CFC8DF: ipa_icf_driver (ipa-icf.c:3060) ==94166==by 0x10CFC8DF: ipa_icf::pass_ipa_icf::execute(function*) (ipa-icf.c:3107) ==94166==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==94166==by 0x10690B53: execute_ipa_pass_list(opt_pass*) (passes.c:2727) ==94166==by 0x1038D2DF: ipa_passes (cgraphunit.c:2207) ==94166==by 0x1038D2DF: symbol_table::compile() (cgraphunit.c:2295) ==94166==by 0x1038ED47: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) ==94166==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==94166==by 0x1076894F: compile_file() (toplev.c:608)
[Bug middle-end/65431] New: [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65431 Bug ID: 65431 Summary: [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Running the testsuite on ppc64le with an --enable-checking=valgrind compiler shows many instances of: ==32629== Invalid read of size 8 ==32629==at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586) ==32629==by 0x10D6D50F: splay_tree_delete_helper (splay-tree.c:96) ==32629==by 0x10D6D50F: splay_tree_delete (splay-tree.c:353) ==32629==by 0x105E265B: execute_lower_omp (omp-low.c:11906) ==32629==by 0x105E265B: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==32629==by 0x10619A07: execute_one_pass(opt_pass*) (passes.c:2328) ==32629==by 0x10619F03: execute_pass_list_1(opt_pass*) (passes.c:2380) ==32629==by 0x10619FA3: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==32629==by 0x10317FFB: cgraph_node::analyze() (cgraphunit.c:645) ==32629==by 0x1031B207: analyze_functions() (cgraphunit.c:1023) ==32629==by 0x1031B6B7: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==32629==by 0x105657C7: write_global_declarations() (langhooks.c:344) ==32629==by 0x10206083: gfc_write_global_declarations() (f95-lang.c:309) ==32629==by 0x106F278F: compile_file() (toplev.c:608) ==32629== Address 0x4951198 is 264 bytes inside a block of size 304 free'd ==32629==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==32629==by 0x105DBC87: delete_omp_context(unsigned long) (omp-low.c:1607) ==32629==by 0x10D6D4AB: splay_tree_delete_helper (splay-tree.c:89) ==32629==by 0x10D6D4AB: splay_tree_delete (splay-tree.c:353) ==32629==by 0x105E265B: execute_lower_omp (omp-low.c:11906) ==32629==by 0x105E265B: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==32629==by 0x10619A07: execute_one_pass(opt_pass*) (passes.c:2328) ==32629==by 0x10619F03: execute_pass_list_1(opt_pass*) (passes.c:2380) ==32629==by 0x10619FA3: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==32629==by 0x10317FFB: cgraph_node::analyze() (cgraphunit.c:645) ==32629==by 0x1031B207: analyze_functions() (cgraphunit.c:1023) ==32629==by 0x1031B6B7: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==32629==by 0x105657C7: write_global_declarations() (langhooks.c:344) ==32629==by 0x10206083: gfc_write_global_declarations() (f95-lang.c:309) or: ==66627== Invalid read of size 8 ==66627==at 0x10650F58: delete_omp_context(unsigned long) (omp-low.c:1586) ==66627==by 0x10DD258B: splay_tree_delete_helper (splay-tree.c:89) ==66627==by 0x10DD258B: splay_tree_delete (splay-tree.c:353) ==66627==by 0x106579BB: execute_lower_omp (omp-low.c:11906) ==66627==by 0x106579BB: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==66627==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==66627==by 0x106900C3: execute_pass_list_1(opt_pass*) (passes.c:2380) ==66627==by 0x10690163: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==66627==by 0x1038B67B: cgraph_node::analyze() (cgraphunit.c:645) ==66627==by 0x1038E887: analyze_functions() (cgraphunit.c:1023) ==66627==by 0x1038ED37: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==66627==by 0x101A31CB: cp_write_global_declarations() (decl2.c:4754) ==66627==by 0x1076894F: compile_file() (toplev.c:608) ==66627==by 0x10111D33: do_compile (toplev.c:2076) ==66627==by 0x10111D33: toplev::main(int, char**) (toplev.c:2174) ==66627== Address 0x4a0b928 is 264 bytes inside a block of size 304 free'd ==66627==at 0x4095394: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==66627==by 0x10650FE7: delete_omp_context(unsigned long) (omp-low.c:1607) ==66627==by 0x10DD25EF: splay_tree_delete_helper (splay-tree.c:96) ==66627==by 0x10DD25EF: splay_tree_delete (splay-tree.c:353) ==66627==by 0x106579BB: execute_lower_omp (omp-low.c:11906) ==66627==by 0x106579BB: (anonymous namespace)::pass_lower_omp::execute(function*) (omp-low.c:11936) ==66627==by 0x1068FBC7: execute_one_pass(opt_pass*) (passes.c:2328) ==66627==by 0x106900C3: execute_pass_list_1(opt_pass*) (passes.c:2380) ==66627==by 0x10690163: execute_pass_list(function*, opt_pass*) (passes.c:2391) ==66627==by 0x1038B67B: cgraph_node::analyze() (cgraphunit.c:645) ==66627==by 0x1038E887: analyze_functions() (cgraphunit.c:1023) ==66627==by 0x1038ED37: symbol_table::finalize_compilation_unit() (cgraphunit.c:2435) ==66627==by 0x1
[Bug c/65430] New: false negative of -Wsequence-point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65430
Bug ID: 65430
Summary: false negative of -Wsequence-point
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
There is no warning on the expression on line 3, which has a sequence-point
issue. Either "a=3" or "a=0" could be executed first.
Moreover, it is odd that gcc does not warn that the value of the expression is
not used.
$: cat s.c
int a;
int fn1() {
(a = 3, 8) * (a = 0);
return a;
}
$: gcc-trunk -c -Wsequence-point s.c
$: clang-trunk -c -Wsequence-point -Wno-unused-value s.c
s.c:3:6: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
(a = 3, 8) * (a = 0);
^~
1 warning generated.
$:
$:
[Bug fortran/65429] ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-15 Ever confirmed|0 |1
[Bug fortran/65428] ICE on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-15 Blocks||32834 Summary|Segfault on nest array |ICE on nest array |constructor |constructor Ever confirmed|0 |1
[Bug fortran/65429] New: ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 Bug ID: 65429 Summary: ICE on implied-length character empty array constructor Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org $ cat c.f90 CHARACTER(*), PARAMETER :: animals(*) = [ CHARACTER(10) :: ] print *, animals end $ gfortran c.f90 f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) zsh: abort gfortran c.f90
[Bug fortran/65428] New: Segfault on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 Bug ID: 65428 Summary: Segfault on nest array constructor Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org $ cat a.f90 print *, [[ integer :: ]] end $ gfortran a.f90 a.f90: In function ‘MAIN__’: a.f90:1:0: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1065 print *, [[ integer :: ]] ^ a.f90:1:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) zsh: abort gfortran a.f90
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #7 from Andrew Pinski --- There is some memory issue going on here. If I rebuild libcpp/expr.o manually and not from full build we get: cmp x14, xzr csetw22, ne cmp x19, xzr csetw0, ne and w22, w22, w0 .loc 1 1956 0 ldr x8, [x29, 152] mov x0, x23 mov x1, x19 bl _ZL12num_part_mulmm But the built one gets: 0x00f712b8 <_cpp_parse_expr+1600>: cmp x14, xzr 0x00f712bc <_cpp_parse_expr+1604>: csetw22, ne 0x00f712c0 <_cpp_parse_expr+1608>: cmp x19, xzr 0x00f712c4 <_cpp_parse_expr+1612>: csetw0, ne 0x00f712c8 <_cpp_parse_expr+1616>: and w22, w22, w0 0x00f712cc <_cpp_parse_expr+1620>: mov x0, x23 0x00f712d0 <_cpp_parse_expr+1624>: mov x8, x16 0x00f712d4 <_cpp_parse_expr+1628>: mov x1, x19 0x00f712d8 <_cpp_parse_expr+1632>: bl 0xf6eee0 <_ZL12num_part_mulmm>
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #6 from Andrew Pinski --- I can reproduce this with the following options to configure: ../configure --prefix=/data/gcc-ubuntu --- CUT --- I am going to try a different base compiler to see what happens.
[Bug target/65413] inefficient code returning aggregates on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65413 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-14 CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Target Milestone|--- |6.0 Summary|inefficient code returning |inefficient code returning |aggregates on powepc64le|aggregates on powerpc64le Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- This is first expanded to a copy of the arg to a struct on stack; then CSE etc. keep everything in regs, and DSE removes the stores completely. We are left with copying 0 to a reg, and then copying parts of the arg to a zero_extract of that. Which combine will not handle (see combinable_i3pat, the "inner_dest != dest" branch). This will get better when we no longer write rl*imi as a zero_extract, hopefully completely solved even. We'll see. Mine.
[Bug tree-optimization/65426] Recognize byte-swaps when writing to buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65426 --- Comment #2 from Robert Clausecker --- I tried compiling this code (without static inline) on a trunk (r221432) gcc and it didn't recognize the pattern. Is there a pattern with the same effect that gets recognized?
[Bug tree-optimization/65427] New: ICE in emit_move_insn with wide vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65427 Bug ID: 65427 Summary: ICE in emit_move_insn with wide vector types Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: solar-gcc at openwall dot com Created attachment 35037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35037&action=edit testcase GCC 4.7.0 through at least 4.9.2 and 5.0 20150215 snapshot (I haven't tested newer ones) fails with ICE when compiling the attached md5slice.c testcase on and for Linux x86_64: $ gcc md5slice.c -o md5slice -O2 -DVECTOR -Wno-attributes -ftree-loop-vectorize md5slice.c: In function 'GG': md5slice.c:302:27: internal compiler error: in emit_move_insn, at expr.c:3609 static MAYBE_INLINE3 void GG(a, b, c, d, x, s, ac) ^ 0x6974d2 emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3608 0x5e5294 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3288 0x5e5294 expand_gimple_stmt ../../gcc/cfgexpand.c:3322 0x5e589b expand_gimple_basic_block ../../gcc/cfgexpand.c:5162 0x5e7b56 gimple_expand_cfg ../../gcc/cfgexpand.c:5741 0x5e7b56 execute ../../gcc/cfgexpand.c:5961 Without -ftree-loop-vectorize, compilation succeeds. With -O3, it fails slightly differently: $ gcc md5slice.c -o md5slice -O3 -DVECTOR -Wno-attributes md5slice.c: In function 'II.constprop': md5slice.c:328:27: internal compiler error: in emit_move_insn, at expr.c:3609 static MAYBE_INLINE3 void II(a, b, c, d, x, s, ac) ^ 0x6974d2 emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3608 0x5e5294 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3288 0x5e5294 expand_gimple_stmt ../../gcc/cfgexpand.c:3322 0x5e589b expand_gimple_basic_block ../../gcc/cfgexpand.c:5162 0x5e7b56 gimple_expand_cfg ../../gcc/cfgexpand.c:5741 0x5e7b56 execute ../../gcc/cfgexpand.c:5961 With -mavx or -mavx2, it succeeds (despite of -O3). GCC 4.7.0 does not have the -ftree-loop-vectorize option, but a similar problem is seen with -O3: $ gcc md5slice.c -o md5slice -O3 -DVECTOR -Wno-attributes md5slice.c: In function 'GG': md5slice.c:302:27: internal compiler error: in emit_move_insn, at expr.c:3435 So far, all of this is with: typedef element vector __attribute__ ((vector_size (32))); on line 41. Reducing the vector width to 16 makes the plain SSE2 compilation succeed with any optimizations. Conversely, increasing the vector width to 64 makes compilation to fail even with AVX/AVX2 enabled. Ideally, when the vector type width is in excess of the current target architecture's native SIMD vector width, GCC should transparently split it into multiple sub-vectors of the natively supported width. This is useful not only for being able to build/use wider-vector source code for/on older CPUs, but also to hide instruction latencies by having the compiler interleave operations on the sub-vectors due to the extra parallelism the excessive vector width provides. For example, once this is supported 32 could actually work faster than 16 on SSE2, and 64 faster than 32 on AVX2, for some applications (as long as the register pressure does not become too high). Failing that, at least the compiler should report that this is unsupported, rather than fail with an ICE. With GCC 4.6.2 and older, the ICE does not occur, for the rather unfortunate reason that (at least for me) these versions generate scalar code (so ~10x slower) when the type's vector width exceeds what's supported natively.
[Bug tree-optimization/65426] Recognize byte-swaps when writing to buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65426 --- Comment #1 from Andrew Pinski --- This one was implemented or maybe only where the load and stores happen.
[Bug tree-optimization/65426] New: Recognize byte-swaps when writing to buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65426
Bug ID: 65426
Summary: Recognize byte-swaps when writing to buffers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fuz at fuz dot su
Created attachment 35036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35036&action=edit
Various instances of the aforementioned pattern
It would be great if gcc could recognize code like this:
static inline void
wm32(uint8_t a[4], uint32_t x)
{
a[0] = x >> 24;
a[1] = x >> 16;
a[2] = x >> 8;
a[3] = x >> 0;
}
and turn it into a single unaligned write (and perhaps a byte swap on platforms
where this is supported). This kind of code appears when one tries to write
marshalling code in a portable fashion.
Attached is a file containing various instances of this pattern.
[Bug c/65423] No warning on always-true/false predicates containing bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65423 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Yes, that would be nice. I think we already have such a bug report, though. I'll look for it later.
[Bug tree-optimization/65425] New: code optimization leads to spurious FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425 Bug ID: 65425 Summary: code optimization leads to spurious FP exception Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: p.vanhoof at oma dot be Created attachment 35035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35035&action=edit program that triggers the bug Compile the attached test case with gcc -O3 -ftrapping-math -fno-math-errno bug.c -lm This produces no output. Running the executable will result in a spurious FP exception. This happens with all gcc versions I tested since 4.7.0. Versions 4.6.4 and earlier work correctly, so this is a regression. It looks like the code is being optimized with the implicit assumption that FP exceptions are not trapped. However, using the -ftrapping-math flag should prevent such optimizations (and should be the default as well). % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc492/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc492/configure --prefix=/usr/local/gcc492 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.9.2 (GCC)
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #5 from Matthias Klose --- I see two different ICEs in the ARM32 build. ../../../src/libgcc/libgcc2.c: In function '__gcc_bcmp': ../../../src/libgcc/libgcc2.c:2086:1: internal compiler error: in iv_ca_delta_commit, at tree-ssa-loop-ivopts.c:5622 __gcc_bcmp (const unsigned char *s1, const unsigned char *s2, size_t size) ^ and the segfault as before. Note this is in the soft-float multilib, which I build using a local patch. I'll see if I can reproduce it on the Debian armel architecture.
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 --- Comment #4 from Matthias Klose --- still seen with r221436 Configured with: -v --with-pkgversion='Ubuntu 5-20150314-1ubuntu11' --with-bugurl='file:///usr/share/doc/gcc-5/README.Bugs' --enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/5 --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-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 --with-arch-directory=arm64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu build logs at https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/4835737/+listing-archive-extra #0 0x00d3ca70 in num_part_mul(unsigned long, unsigned long) () #1 0x00d3ee44 in _cpp_parse_expr () #2 0x00d3ee44 in _cpp_parse_expr () [...] #675 0x00d3ee44 in _cpp_parse_expr () #676 0x00d3ee44 in _cpp_parse_expr () #677 0x00d3ee44 in _cpp_parse_expr () [...]
[Bug tree-optimization/65424] New: gcc does not recognize byte swaps implemented as loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65424
Bug ID: 65424
Summary: gcc does not recognize byte swaps implemented as loop.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fuz at fuz dot su
Created attachment 35034
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35034&action=edit
endianess-aware reading / writing macros
gcc (r221432) is able to recognize the following code and implements it with
either a bswap or a straight load on x86.
#include
extern uint32_t
rbe32(const uint8_t a[4])
{
uint32_t x = 0;
x |= a[0] << 24;
x |= a[1] << 16;
x |= a[2] << 8;
x |= a[3] << 0;
return x;
}
extern uint32_t
rle32(const uint8_t a[4])
{
uint32_t x = 0;
x |= a[0] << 0;
x |= a[1] << 8;
x |= a[2] << 16;
x |= a[3] << 24;
return x;
}
it isn't able to recognize the following two functions which yield identical
results:
extern uint32_t
rle32(const uint8_t a[4])
{
int i;
uint32_t x = 0;
for (i = 0; i < 4; i++)
x |= a[i] << 8 * i;
return x;
}
extern uint32_t
rbe32(const uint8_t a[4])
{
int i;
uint32_t x = 0;
for (i = 0; i < 4; i++)
x |= a[i] << 8 * (3 - i);
return x;
}
It would be great if gcc was able to recognize these implementations of
endianess-aware reads; this kind of code is produced by macros I use to
generate a bunch of read / write functions for differently sized types.
Attached is a file containing the macros I want to use.
[Bug fortran/61138] [4.8/4.9/5 Regression] Wrong code with pointer-bounds remapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61138 --- Comment #8 from Mikael Morin --- Author: mikael Date: Sat Mar 14 12:23:27 2015 New Revision: 221436 URL: https://gcc.gnu.org/viewcvs?rev=221436&root=gcc&view=rev Log: PR fortran/61138 fortran/ * trans-expr.c (gfc_trans_pointer_assignment): Clear DESCRIPTOR_ONLY field before reusing LSE. testsuite/ gfortran.dg/pointer_remapping_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_remapping_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Any specific configure options? aarch64-linux bootstrapped/regtested just fine last night for me with --enable-checking=release.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #38 from Jakub Jelinek --- Fixed.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #37 from Jakub Jelinek --- Author: jakub Date: Sat Mar 14 09:56:39 2015 New Revision: 221435 URL: https://gcc.gnu.org/viewcvs?rev=221435&root=gcc&view=rev Log: PR tree-optimization/65369 * tree-vect-stmts.c (vectorizable_load) : Set bump to vs * TYPE_SIZE_UNIT (elem_type) - 1 instead of (vs - 1) * TYPE_SIZE_UNIT (elem_type). * gcc.c-torture/execute/pr65369.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65369.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/65418] [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/65418] [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Sat Mar 14 09:55:41 2015 New Revision: 221434 URL: https://gcc.gnu.org/viewcvs?rev=221434&root=gcc&view=rev Log: PR tree-optimization/65418 * tree-ssa-reassoc.c (extract_bit_test_mask): If there are casts in the first PLUS_EXPR operand, ensure tbias and *totallowp are in the inner type. * gcc.c-torture/execute/pr65418-1.c: New test. * gcc.c-torture/execute/pr65418-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65418-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr65418-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug c/65423] New: No warning on always-true/false predicates containing bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65423
Bug ID: 65423
Summary: No warning on always-true/false predicates containing
bitwise operations
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
The condition "(a & 9) == 4" is always false, and it will be great if Gcc can
emit a warning on this.
$: cat bitwise.c
int f(int a) {
if ((a & 9) == 4) {
return 1;
} else {
return 0;
}
}
$: clang-trunk -Wtautological-compare -c bitwise.c
bitwise.c:2:15: warning: bitwise comparison always evaluates to false
[-Wtautological-compare]
if ((a & 9) == 4) {
^~~~
1 warning generated.
$: gcc-trunk -Wall -Wextra -Wtype-limits -c bitwise.c
[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65401 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|law at redhat dot com |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65401 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Mar 14 08:54:08 2015 New Revision: 221433 URL: https://gcc.gnu.org/viewcvs?rev=221433&root=gcc&view=rev Log: PR rtl-optimization/65401 * combine.c (rtx_equal_for_field_assignment_p): Add widen_x argument. If true, adjust_address_nv of x with big-endian correction for the mode widening to GET_MODE (y). (make_field_assignment): Don't do MEM mode widening here. Use MEM_P instead of GET_CODE == MEM. * gcc.c-torture/execute/pr65401.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65401.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
