[Bug analyzer/99854] gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99854 jseward at acm dot org changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #2 from jseward at acm dot org --- Thanks for the analyzer! I would add (not that it's relevant to this report) that anecdotally, it seems to use way less memory than when I tested it some months back. Maybe only 1/4 as much. A big improvement.
[Bug analyzer/99854] New: gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99854 Bug ID: 99854 Summary: gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jseward at acm dot org Target Milestone: --- Building Valgrind trunk on x86_64-linux with gcc (GCC) 11.0.1 20210328 (experimental) fails with In function ‘setregs’: lto1: fatal error: Cgraph edge statement index out of range This requires both LTO and -fanalyzer to fail. Either by itself does not fail. STR on x86_64-linux, Fedora 33: git clone git://sourceware.org/git/valgrind.git cd valgrind # apply one-line config patch below, so as to build with -fanalyzer ./autogen.sh && ./configure --prefix=`pwd`/Inst --enable-only64bit --enable-lto make -j8 Fails thusly: In function ‘myvprintf_str_XML_simplistic’: lto1: fatal error: Cgraph edge statement index out of range and In function ‘setregs’: lto1: fatal error: Cgraph edge statement index out of range (takes about 25 seconds). Sorry not to have minimised. Am willing to try out patches. Config patch as referred to above: diff --git a/Makefile.all.am b/Makefile.all.am index bcd29165d..c339b95c7 100644 --- a/Makefile.all.am +++ b/Makefile.all.am @@ -96,7 +96,7 @@ clean-noinst_DSYMS: # performance and get whatever useful warnings we can out of gcc. # -fno-builtin is important for defeating LLVM's idiom recognition # that somehow causes VG_(memset) to get into infinite recursion. -AM_CFLAGS_BASE = \ +AM_CFLAGS_BASE = -fanalyzer \ -O2 -g \ -Wall \ -Wmissing-prototypes \
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #22 from jseward at acm dot org --- Looking back at the above, it's now clearer what the problem is: # Park potentially live data in the red zone _savegpr0_14: std r14,-144(r1) _savegpr0_15: std r15,-136(r1) _savegpr0_16: std r16,-128(r1) _savegpr0_17: std r17,-120(r1) _savegpr0_18: std r18,-112(r1) _savegpr0_19: std r19,-104(r1) _savegpr0_20: std r20,-96(r1) _savegpr0_21: std r21,-88(r1) _savegpr0_22: std r22,-80(r1) _savegpr0_23: std r23,-72(r1) _savegpr0_24: std r24,-64(r1) _savegpr0_25: std r25,-56(r1) _savegpr0_26: std r26,-48(r1) _savegpr0_27: std r27,-40(r1) _savegpr0_28: std r28,-32(r1) _savegpr0_29: std r29,-24(r1) _savegpr0_30: std r30,-16(r1) _savegpr0_31: std r31,-8(r1) std r0, 16(r1) # And ka-zap! Memcheck paints -288(r1) .. -1(r1) as undefined. blr # So now they're all "unusable".
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #21 from jseward at acm dot org --- (In reply to Jakub Jelinek from comment #20) > Can you disable it just for these magic entrypoints (either by name or by > content)? In principle yes. I prefer by-content rather than by-name, in the case where all symbol names have disappeared or changed, etc. However, this would require having a reliable mechanism for detecting the entry points by inspecting their content. It would also require a certain amount of plumbing work, basically making `VexAbiInfo::guest_ppc_zap_RZ_at_blr` be a function rather than a Bool, in the same way that `VexAbiInfo::guest_ppc_zap_RZ_at_bl` already is. It might be a day or two's work to set up and test, once we had a reliable identify-by-content routine available.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 jseward at acm dot org changed: What|Removed |Added CC||jseward at acm dot org --- Comment #19 from jseward at acm dot org --- (In reply to Mark Wielaard from comment #18) (expanding marginally on Mark's comment) Currently the Memcheck ppc64be and ppc64le ports assume that the redzone (the 288 bytes below SP) is volatile across both calls and returns, and it enforces this behaviour by painting that area of memory as "undefined" for both calls and returns. But the optimisation discussed here appears to carry live data across a return (that's what a "blr" is, right?) So in effect the problem occurs because this optimisation changes the ABI semantics that Memcheck has thus far assumed. As Mark says, we can "fix" this just by disabling the zap-on-return instrumentation behaviour, but that comes at the cost of completely losing the ability to detect genuinely incorrect uses of the redzone across a return.
[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #7 from jseward at acm dot org --- (In reply to Jakub Jelinek from comment #3) > Because, say in the memcmp case, if the first 4 bytes are defined and are > not equal to the first bytes of the other value, then it will be non-equal > regardless of what the other bytes contain. Now, this should be only done > if the comparison is consumed as equality comparison by the conditional > jump, if it is >/>=/, >= etc, Memcheck has various levels of sophistication. For example it knows that |value
[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #6 from jseward at acm dot org --- (In reply to Martin Liška from comment #5) > > > > That should make it run clean even without using > > --expensive-definedness-checks=yes. Does it? > > Yes, as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9#c2 Confusion .. #c2 isn't about fixing it without the use of --expensive-definedness-checks=, afaics.
[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 jseward at acm dot org changed: What|Removed |Added CC||jseward at acm dot org --- Comment #4 from jseward at acm dot org --- This seems to me to be another rerun of the movie where a program does integer equality on partially defined operands, and still produces a defined result. Memcheck can already deal with this, but doesn't do so for 64-bit compares on amd64 by default, since it's expensive. In memcheck/mc_translate.c, around line 8354, find this # if defined(VGA_x86) mce.dlbo.dl_Add32 = DLauto; mce.dlbo.dl_CmpEQ32_CmpNE32 = DLexpensive; # elif defined(VGA_amd64) mce.dlbo.dl_Add64 = DLauto; mce.dlbo.dl_CmpEQ32_CmpNE32 = DLexpensive; # elif defined(VGA_ppc64le) // Needed by (at least) set_AV_CR6() in the front end. mce.dlbo.dl_CmpEQ64_CmpNE64 = DLexpensive; # endif and add to the VGA_amd64 case: mce.dlbo.dl_CmpEQ64_CmpNE64 = DLexpensive; That should make it run clean even without using --expensive-definedness-checks=yes. Does it?
[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80479 jseward at acm dot org changed: What|Removed |Added CC||jseward at acm dot org --- Comment #17 from jseward at acm dot org --- (In reply to acsawdey from comment #13) > The tests that I have done show that the inline code is 2-3x faster than > glibc (depending on which glibc you are testing). Are you sure this transformation is actually a win on real (big) programs? The inline translation is so verbose that I wonder how many instances you need before you wind up adversely affecting your icache miss rates.
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #2 from jseward at acm dot org --- (In reply to Andrew Pinski from comment #1) > -O3 produces the memset: Having to go to -O3 to get reasonable code isn't a great solution, though. Couldn't gcc at least produce a word-at-a-time loop, or "rep stosw" on x86s?
[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 --- Comment #10 from jseward at acm dot org --- Thank you for fixing this quickly!
[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 --- Comment #7 from jseward at acm dot org --- I tried the fix at PR70029 comment 7 (disabling a check) but that doesn't help, at least for the original, unreduced test case (Unified_cpp_dom_animation0.ii).
[Bug c++/70627] internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 --- Comment #2 from jseward at acm dot org --- Created attachment 38236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38236=edit Unified_cpp_dom_animation0.ii.bz2 Testcase .ii.bz2, compressed so as to get it under the 1MB limit :-(
[Bug c++/70627] internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 --- Comment #1 from jseward at acm dot org --- sewardj@dundee[6X]:~/MOZ$ c++ -c Unified_cpp_dom_animation0.ii -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wc++14-compat -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++11 -pthread -pipe -g -g -Og -fno-omit-frame-pointer -Wshadow In file included from /home/sewardj/MOZ/MC-MOCHI/ff-Og-linux64/dom/animation/Unified_cpp_dom_animation0.cpp:137:0: /home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp: In function ‘T&& mozilla::Forward(typename mozilla::RemoveReference::Type&) [with T = const mozilla::CSSPseudoElementType&]’: /home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1: error: type variant has different TREE_TYPE } // namespace mozilla ^ unit size align 8 symtab 1270682720 alias set -1 canonical type 0x7fb94bd98540 precision 8 min max pointer_to_this reference_to_this > sizes-gimplified asm_written static unsigned type_5 type_6 QI size unit size align 8 symtab 1173426976 alias set -1 canonical type 0x7fb946878498 precision 8 min max values local bindings <(nil)>> value readonly constant used VOID file /home/sewardj/MOZ/MC-MOCHI/layout/style/nsCSSPseudoElementList.h line 28 col 1 align 1 context initial > chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain value chain >>>>>> context pointer_to_this reference_to_this chain > /home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1: error: type variant's TREE_TYPE constant 8> unit size constant 1> align 8 symtab 1270682720 alias set -1 canonical type 0x7fb94bd98540 precision 8 min max pointer_to_this reference_to_this > /home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1: error: type's TREE_TYPE constant 8> unit size constant 1> align 8 symtab 1173427056 alias set -1 canonical type 0x7fb94bd98540 precision 8 min max > unit size align 8 symtab 1173427056 alias set -1 canonical type 0x7fb94bd98540 precision 8 min max > readonly sizes-gimplified static unsigned type_5 type_6 QI size unit size align 8 symtab 921920128 alias set -1 canonical type 0x7fb945f193f0 precision 8 min max values local bindings <(nil)>> value readonly constant used VOID file /home/sewardj/MOZ/MC-MOCHI/layout/style/nsCSSPseudoElementList.h line 28 col 1 align 1 context initial > chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain value chain >>>>>> context pointer_to_this reference_to_this > /home/sewardj/MOZ/MC-MOCHI/dom/animation/PendingAnimationTracker.cpp:124:1: internal compiler error: verify_type failed 0xf9f9e2 verify_type(tree_node const*) ../../gcc-6-20160410/gcc/tree.c:13908 0x9a1dd4 gen_type_die_with_usage ../../gcc-6-20160410/gcc/dwarf2out.c:22703 0x9a2439 gen_type_die_with_usage ../../gcc-6-20160410/gcc/dwarf2out.c:22805 0x9a31b6 gen_type_die ../../gcc-6-20160410/gcc/dwarf2out.c:22901 0x99b17f gen_decl_die ../../gcc-6-20160410/gcc/dwarf2out.c:23454 0x99b90e dwarf2out_decl ../../gcc-6-20160410/gcc/dwarf2out.c:23953 0x9b3078 dwarf2out_early_global_decl ../../gcc-6-20160410/gcc/dwarf2out.c:23626 0x9295ab symbol_table::finalize_compilation_unit() ../../gcc-6-20160410/gcc/cgraphunit.c:2556 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. sewardj@dundee[6X]:~/MOZ$ gcc --version gcc (GCC) 6.0.0 20160410 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/70627] New: internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 Bug ID: 70627 Summary: internal compiler error: verify_type failed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jseward at acm dot org Target Milestone: --- This is with gcc (GCC) 6.0.0 20160410 (experimental) building part of Firefox on x86_64-linux, on Fedora 21.
