[Bug libstdc++/56538] no way to disable shared_ptr's use of atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56538 Jan Kratochvil changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Jan Kratochvil --- With gcc-11.2.1-1.fc34.x86_64 and i7-8650U there isn't any performance difference of the reproducer. I can check why it is so when I have more time in the future.
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #17 from Jan Kratochvil --- Yes, the testcase TestTypeCompletion.py category 'dwo' is now fixed with the patch from Comment 15.
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #14 from Jan Kratochvil --- DW_AT_addr_base is for .debug_addr in the main file, I agree, my mistake. That should be inherited from the skeleton to the split-unit. But DW_AT_loclists_base, DW_AT_rnglists_base and DW_AT_str_offsets_base point to .debug_loclists.dwo, .debug_rnglists.dwo and .debug_str_offsets.dwo respectively. As there is only one CU in a DWO they make no sense to be inherited from the skeleton unit to split-unit.
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #12 from Jan Kratochvil --- That looks as a DWARF5 bug to me. DW_AT_str_offsets_base, DW_AT_addr_base and DW_AT_rnglists_base do not make any sense for a split unit. Split unit contains only one CompileUnit (and optionally one TypeUnit where only DW_AT_str_offsets_base would have some sense).
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #10 from Jan Kratochvil --- clang is using DW_AT_ranges+DW_FORM_rnglistx+DW_AT_rnglists_base in the main file but in the DWO file it assumes DW_AT_rnglists_base is right after the .debug_rnglists header (as it does not make sense to point it anywhere else in a DWO file having single CU). It makes sense although I do not see it specified in DWARF-5: .debug_info contents: ... 0x0014: DW_TAG_skeleton_unit [1] ... DW_AT_ranges [DW_FORM_rnglistx] (indexed (0x0) rangelist = 0x0010 [0x00401110, 0x0040) [0x00401120, 0x00401121) [0x00401130, 0x00401171)) ... DW_AT_rnglists_base [DW_FORM_sec_offset] (0x000c) .debug_info.dwo contents: ... 0x0014: DW_TAG_compile_unit [1] * ... DW_AT_ranges [DW_FORM_rnglistx] (indexed (0x0) rangelist = 0x0010 [0x0004, 0x0016) [0x0022, 0x0034)) https://github.com/llvm/llvm-project/blob/523d7bc6f427f9ae32e54dbf1764826cfb269d21/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp#L388
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #7 from Jan Kratochvil --- It would be nice if you could provide the .s/.o/.dwo files so that one does not have to rebuild the patched GCC.
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #3 from Jan Kratochvil ---
LLDB testsuite failure from it is:
PASS: LLDB (/usr/bin/gcc-x86_64) :: test_with_run_command_dwarf
(TestTypeCompletion.TypeCompletionTestCase)
error: a.out {0x5850}: DIE has DW_AT_ranges(0x0) attribute, but range
extraction failed (missing or invalid range list table), please file a bug and
attach the file at the start of this error message
FAIL: LLDB (/usr/bin/gcc-x86_64) :: test_with_run_command_dwo
(TestTypeCompletion.TypeCompletionTestCase)
Failed Tests (1):
lldb-api :: functionalities/type_completion/TestTypeCompletion.py
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #2 from Jan Kratochvil --- Created attachment 50341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50341=edit range-gcc.s
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #1 from Jan Kratochvil --- Created attachment 50340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50340=edit range-clang.s
[Bug debug/99490] New: -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
Bug ID: 99490
Summary: -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main
file, not .dwo file
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
FAIL: gcc-11.0.0-0.19.fc35.x86_64
PASS: clang-12.0.0-0.1.rc1.fc35.x86_64
double p_ext=3.14,e_ext=2.71;
int main(void) {
double q,f;
{ volatile double p=p_ext;
q=p/1.1;
}
{ volatile double e=e_ext;
f=e/1.1;
}
return q+f;
}
clang -o range-clang range.c -Wall -O3 -gdwarf-5 -gsplit-dwarf;gcc -o
range-gcc.s range.c -Wall -O3 -gdwarf-5 -gsplit-dwarf
llvm-readelf -WS range-{clang,gcc}{,.dwo} | egrep '^File:|debug_rnglists'
File: range-clang
File: range-clang.dwo
[ 6] .debug_rnglists.dwo PROGBITS 0001d4 17 00 E
0 0 1
Actual:
File: range-gcc
[33] .debug_rnglists PROGBITS 004c0a 49 00
0 0 1
File: range-gcc.dwo
Expected:
File: range-gcc
File: range-gcc.dwo
[33] .debug_rnglists PROGBITS 004c0a 49 00
0 0 1
DWARF-5 spec:
"The .debug_rnglists.dwosection contains range lists referenced by any
DW_AT_ranges attributes in the split DWARF object."
"Range lists are contained in a separate object file section called
.debug_rnglists or .debug_rnglists.dwo (in split units)."
Reproducer from attached .s files:
: clang -S -o range-clang.s range.c -Wall -O3 -gdwarf-5 -gsplit-dwarf;clang -o
range-clang range-clang.s -Wall -gdwarf-5 -gsplit-dwarf;: gcc -S -o range-gcc.s
range.c -Wall -O3 -gdwarf-5 -gsplit-dwarf;gcc -o range-gcc range-gcc.s -Wall
-gdwarf-5 -gsplit-dwarf
[Bug c++/92598] explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #3 from Jan Kratochvil ---
LLVM has workarounded it by:
https://reviews.llvm.org/rG0e3d7e61867d69721b28e557272bdf4b66010327
template <>
- struct DenseMapInfo> {
+ struct llvm::DenseMapInfo> {
[Bug c++/92598] explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #2 from Jan Kratochvil ---
Created attachment 50210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50210=edit
2j.cpp.xz
gcc-11.0.0-0.19.fc34.x86_64
g++ -c 2j.cpp
/home/jkratoch/redhat/llvm-monorepo/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:86:8:
error: explicit specialization of 'template struct llvm::DenseMapInfo'
outside its namespace must use a nested-name-specifier [-fpermissive]
86 | struct DenseMapInfo> {
|
^~~
[Bug c++/92598] explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
--- Comment #1 from Jan Kratochvil ---
Created attachment 50209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50209=edit
1j.cpp.xz
gcc-10.2.1-9.fc33.x86_64
g++ -c 1j.cpp
/home/jkratoch/redhat/llvm-monorepo/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:86:8:
error: explicit specialization of ‘template struct llvm::DenseMapInfo’
outside its namespace must use a nested-name-specifier [-fpermissive]
86 | struct DenseMapInfo> {
|
^~~
[Bug debug/96472] New: ICE: c++: dwarf2out_abstract_function, at dwarf2out.c: -g -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96472 Bug ID: 96472 Summary: ICE: c++: dwarf2out_abstract_function, at dwarf2out.c: -g -fdebug-types-section Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- Created attachment 48998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48998=edit 1.cc.xz reproducer 2ac7fe2769890fe4c146da9cfa6d0eabb185d7db = 2020-08-03 g++ -c -o 1 1.cc -O2 -g -fdebug-types-section during IPA pass: inline describe.cc: In destructor ‘describe_feature_wide(const coord_def&)::feat_info::~feat_info()’: describe.cc:2365:7: internal compiler error: in dwarf2out_abstract_function, at dwarf2out.c:22538 0xc3591d dwarf2out_abstract_function ../../gccgitclean/gcc/dwarf2out.c:22538 0x1063ac5 tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*, basic_block_def*) ../../gccgitclean/gcc/tree-inline.c:6219 0xde233b save_inline_function_body ../../gccgitclean/gcc/ipa-inline-transform.c:639 0xde233b inline_transform(cgraph_node*) ../../gccgitclean/gcc/ipa-inline-transform.c:697 0xf0acad execute_one_ipa_transform_pass ../../gccgitclean/gcc/passes.c:2240 0xf0acad execute_all_ipa_transforms(bool) ../../gccgitclean/gcc/passes.c:2279 0xbc9a63 cgraph_node::expand() ../../gccgitclean/gcc/cgraphunit.c:2294 0xbcafff expand_all_functions ../../gccgitclean/gcc/cgraphunit.c:2472 0xbcafff symbol_table::compile() ../../gccgitclean/gcc/cgraphunit.c:2835 0xbcd422 symbol_table::compile() ../../gccgitclean/gcc/cgraphunit.c:2748 0xbcd422 symbol_table::finalize_compilation_unit() ../../gccgitclean/gcc/cgraphunit.c:3013
[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471 --- Comment #2 from Jan Kratochvil --- Created attachment 48997 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48997=edit .tar.xz reproducer for: gnat
[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #1 from Jan Kratochvil --- Created attachment 48996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48996=edit .tar.xz reproducer for: fortran
[Bug debug/96471] New: ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471 Bug ID: 96471 Summary: ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- 2ac7fe2769890fe4c146da9cfa6d0eabb185d7db = 2020-08-03 gfortran -O2 -g -fdebug-types-section -fallow-argument-mismatch -fopenmp -c 1.F -o 1.o internal compiler error: in build_abbrev_table, at dwarf2out.c:9086 0x641d76 build_abbrev_table ../../gccgitclean/gcc/dwarf2out.c:9086 0xa63da7 build_abbrev_table ../../gccgitclean/gcc/dwarf2out.c:9143 0xa63da7 build_abbrev_table ../../gccgitclean/gcc/dwarf2out.c:9143 0xa64233 output_comdat_type_unit ../../gccgitclean/gcc/dwarf2out.c:11277 0xa8f19e dwarf2out_finish ../../gccgitclean/gcc/dwarf2out.c:31567 gcc -c -g -fdebug-types-section gnatcoll-storage_pools-alignment.adb +===GNAT BUG DETECTED==+ | 11.0.0 20200803 (experimental) (x86_64-pc-linux-gnu) GCC error: | | in build_abbrev_table, at dwarf2out.c:9086 | | Error detected around /quad/home/jkratoch/redhat/gccgitclean-root/lib/gcc/x86_64-pc-linux-gnu/11.0.0/adainclude/s-stoele.adb:70:31| ... raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 Possibly a duplicate of: lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 ICE: in build_abbrev_table, at dwarf2out.c:10477 with -g -feliminate-dwarf2-dups https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47361
[Bug debug/88878] .debug_pubnames/types empty with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 --- Comment #9 from Jan Kratochvil --- (In reply to Richard Biener from comment #8) > The .debug_types section isn't supposed to be output when in_lto_p > (that's for the LTRANS units where we generally do not output any > types into DWARF). Instead .debug_types has to be output during > dwarf2out_early_finish when we write the declaration dwarf units, > the "early" debug info. That should now be done. Thanks for the explanation, I see -fdebug-types-section -flto does work with trunk without any patch, great! > You can verify with a small testcase and -gpubnames [-flto] where > with -flto both .debug_pubtype and .debug_pubnames are missing. I do not think anyone is interested in those, for DWARF-5 they are officially removed: http://www.dwarfstd.org/doc/DWARF5.pdf * Replace the .debug_pubnames and .debug_pubtypes sections with a single and more functional name index section, .debug_names . And for DWARF-4 those were replaced by GNU .gdb_index .
[Bug debug/88878] .debug_pubnames/types empty with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #7 from Jan Kratochvil --- Hello, @rguenth could you suggest what problem does -fdebug-types-section -flto still have? When I remove the use_debug_types's "&& !in_lto_p" part it looks to me as working fine. (I haven't done any non-trivial debuginfo testing.) Contents of the .debug_info section: Compilation Unit @ offset 0x0: Version: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer: (indirect string, offset: 0x0): GNU GIMPLE 10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g -g -fno-openmp -fno-openacc -fno-pie -fdebug-types-section -fltrans <11> DW_AT_name: (indirect string, offset: 0xa8): Compilation Unit @ offset 0xc9: Version: 4 <0>: Abbrev Number: 11 (DW_TAG_compile_unit) DW_AT_producer: (indirect string, offset: 0x35a): GNU C++14 10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g -fdebug-types-section -flto DW_AT_name: (indirect string, offset: 0x20e): main.C <1>: Abbrev Number: 12 (DW_TAG_class_type) DW_AT_signature : signature: 0xf1df7e53d0fa1d2e Compilation Unit @ offset 0x15a: Version: 4 <0><165>: Abbrev Number: 11 (DW_TAG_compile_unit) <166> DW_AT_producer: (indirect string, offset: 0x35a): GNU C++14 10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g -fdebug-types-section -flto <16b> DW_AT_name: (indirect string, offset: 0x479): lib.C Contents of the .debug_types section: Compilation Unit @ offset 0x0: Version: 4 Signature: 0xf1df7e53d0fa1d2e Type Offset: 0x25 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit) <19> DW_AT_GNU_odr_signature: 0xddd94cb16fdd687a <1><25>: Abbrev Number: 2 (DW_TAG_class_type)
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Jan Kratochvil changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #2 from Jan Kratochvil --- These fixes are very simple, maybe you can check it in as obvious? BTW the file was written by Alexandre Oliva, I wrote no single line there.
[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299 --- Comment #7 from Jan Kratochvil --- OK, true, thanks, sorry.
[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
--- Comment #3 from Jan Kratochvil ---
(In reply to Andrew Pinski from comment #1)
> #1 0x7fffdb147b04 in
> lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
> llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int)
> (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/
> liblldb.so.11git+0x3dd5b04)
>
> Correspond to?
(gdb) frame
#14 lldb_private::CommandObject::CommandObject (this=0x612133c0,
interpreter=..., name=..., help=..., syntax=..., flags=) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Interpreter/CommandObject.cpp:47
47m_cmd_help_short = std::string(help);
llvm::StringRef help is from
#15 0x7fffdb14d6b3 in lldb_private::CommandObjectRaw::CommandObjectRaw
(flags=0, syntax=..., help=..., name=..., interpreter=..., this=0x612133c0)
at
/home/jkratoch/redhat/llvm-monorepo3/lldb/include/lldb/Interpreter/CommandObject.h:396
llvm::StringRef help = ""
which is from
#16 lldb_private::CommandObjectRegexCommand::CommandObjectRegexCommand
(this=0x612133c0, interpreter=..., name=..., help=..., syntax=...,
max_matches=10, completion_type_mask=0, is_removable=true) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Interpreter/CommandObjectRegexCommand.cpp:24
llvm::StringRef help
which is from
#18 CommandObjectCommandsAddRegex::DoExecute (this=,
command=..., result=...) at
/home/jkratoch/redhat/llvm-monorepo3/lldb/source/Commands/CommandObjectCommands.cpp:991
991 m_regex_cmd_up = std::make_unique(
992 m_interpreter, name, m_options.GetHelp(),
m_options.GetSyntax(), 10, 0,
993 true);
m_options.GetHelp()
which is
llvm::StringRef GetHelp() { return (m_help.empty() ? "" : m_help); }
llvm::StringRef GetSyntax() { return (m_syntax.empty() ? "" : m_syntax); }
std::string m_help;
std::string m_syntax;
Surprisingly replacing it by:
llvm::StringRef GetHelp() { return m_help; }
llvm::StringRef GetSyntax() { return m_syntax; }
std::string m_help;
std::string m_syntax;
"fixes" the problem.
Compiling with -O0 (instead of -O1) by using
-DLLVM_OPTIMIZE_SANITIZED_BUILDS=OFF also "fixes" the problem.
[Bug sanitizer/94299] New: false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299 Bug ID: 94299 Summary: false positive: AddressSanitizer: stack-use-after-scope on address Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com 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, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48103=edit reproducer patch I believe it is a false positive. gcc-9.2.1-1.fc31.x86_64 git clone https://github.com/llvm/llvm-project.git (cd llvm-project;git checkout b6ae8937e031cde2e70e6a83d46c21e940fdf4ac;patch -p1 <../asan.patch) mkdir llvm-project-gccassertdebugasanO1 cd llvm-project-gccassertdebugasanO1 cmake ../llvm-project-gccassertdebugasanO1/llvm/ -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" -DLLVM_USE_SPLIT_DWARF=ON -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index" -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index" -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_USE_SANITIZER=Address make gdb -batch -ex 'catch syscall exit_group' -ex r -ex bt -ex 'frame 19' -ex 'info source' --args ./bin/lldb -o 'command regex -h h -s s foo s/1/2/' Catchpoint 1 (syscall 'exit_group' [231]) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Detaching after vfork from child process 1526560] [Detaching after vfork from child process 1526576] [New Thread 0x7fffd1ad2700 (LWP 1526592)] (lldb) command regex -h h -s s foo s/1/2/ = ==1526553==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffa410 at pc 0x7fffd9c497ec bp 0x7fff9c10 sp 0x7fff9c00 READ of size 1 at 0x7fffa410 thread T0 #0 0x7fffd9c497eb in void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x28d77eb) #1 0x7fffdb147b04 in lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&, llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd5b04) #2 0x7fffdb14d6b2 in lldb_private::CommandObjectRegexCommand::CommandObjectRegexCommand(lldb_private::CommandInterpreter&, llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int, unsigned int, bool) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3ddb6b2) #3 0x7fffe2c80c35 in CommandObjectCommandsAddRegex::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0xb90ec35) #4 0x7fffdb1432c3 in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd12c3) #5 0x7fffdb12c344 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dba344) #6 0x7fffdb1319be in lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__cxx11::basic_string, std::allocator >&) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dbf9be) #7 0x7fffdad4286f in lldb_private::IOHandlerEditline::Run() (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x39d086f) #8 0x7fffdacb1d2d in lldb_private::Debugger::RunIOHandlers() (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x393fd2d) #9 0x7fffdb0e5ade in lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3d73ade) #10 0x7fffd9e51ed9 in lldb::SBDebugger::RunCommandInterpreter(bool, bool, lldb::SBCommandInterpreterRunOptions&, int&, bool&, bool&) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x2adfed9) #11 0x412c7e in Driver::MainLoop() (/quad/home/jkratoch/redhat/llvm-monorepo3-gcc
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
Jan Kratochvil changed:
What|Removed |Added
Version|4.8.2 |9.2.1
--- Comment #6 from Jan Kratochvil ---
libstdc++-devel-9.2.1-1.fc31.x86_64
cat >gcc59675b.C <
int main() { std::shared_ptr sp; return *sp; }
EOH
g++ -o gcc59675b gcc59675b.C -Wall -g -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
$ ./gcc59675b 2>/dev/null
/usr/include/c++/9/bits/shared_ptr_base.h:1007: std::__shared_ptr_access<_Tp,
_Lp, , >::element_type& std::__shared_ptr_access<_Tp,
_Lp, , >::operator*() const [with _Tp = int;
__gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic; bool = false;
bool = false; std::__shared_ptr_access<_Tp, _Lp, ,
>::element_type = int]: Assertion '_M_get() != nullptr' failed.
Aborted
$ ./gcc59675b >/dev/null
Aborted
[Bug target/93269] 32bit-pointer to uint64_t cast sign-extends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93269 --- Comment #4 from Jan Kratochvil --- Thanks.
[Bug target/93269] New: 32bit-pointer to uint64_t cast sign-extends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93269
Bug ID: 93269
Summary: 32bit-pointer to uint64_t cast sign-extends
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
#include
#include
#include
int main() {
void *p=(void *)0x8000;
printf( "%p""\n", p );// 0x8000
printf("0x%" PRIxPTR "\n",(uintptr_t)p );// 0x8000
printf("0x%" PRIx64 "\n",reinterpret_cast(p));// 0x8000
printf("0x%" PRIx64 "\n",(uint64_t) p );// 0x8000
printf("0x%" PRIx64 "\n", (uint64_t)(uintptr_t)p );// 0x8000
}
gcc-9.2.1-1.fc30.x86_64
g++ -o addr_t2 addr_t2.cpp -Wall -g -m32
0x8000
0x8000
0x8000
0x8000
0x8000
clang-8.0.0-3.fc30.x86_64
clang++ -o addr_t2 addr_t2.cpp -Wall -g -m32 ;./addr_t2
0x8000
0x8000
0x8000
0x8000
0x8000
It may be in some standard but it looks suspicious to me.
[Bug c++/86900] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 --- Comment #2 from Jan Kratochvil --- Created attachment 44523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44523=edit 1.cc.xz Sorry, the 1.cc file somehow did not get attached.
[Bug c++/86900] New: -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 Bug ID: 86900 Summary: -gdwarf-5 -O2 -ffunction-sections = assembler error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- g++ -gdwarf-5 -O2 -ffunction-sections -c 1.cc -o 1.o /tmp/ccnCmT6w.s: Assembler messages: /tmp/ccnCmT6w.s:61840: Error: invalid operands (.text.unlikely._ZN4base27HistogramDeltaSerialization11RecordDeltaERKNS_13HistogramBaseERKNS_16HistogramSamplesE and .text._ZN4base27HistogramDeltaSerialization11RecordDeltaERKNS_13HistogramBaseERKNS_16HistogramSamplesE sections) for `-' ... FAIL: gcc-8.2.1-1dwarf64.fc28.x86_64 FAIL: gcc-8.1.1-5.fc28.x86_64
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #13 from Jan Kratochvil --- Why the example code should not work with "a user-provided non-member function with the same signature defined anywhere in the program, in any source file, replaces the default version. Its declaration does not need to be visible."? I would do the real libstdc++ sources patch as that would comply with these requirements but I wanted to know first if there are some technical reasons why it gets rejected, so far I do not see any.
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #11 from Jan Kratochvil --- (In reply to Jonathan Wakely from comment #10) > Does your !=##n check still work if operator new is replaced in a > different translation unit, but the default one is the only one in scope in > the current TU? alias##n is expected to be a visibility-hidden symbol of libstdc++ so there will be no ld.so relocation. n will be relocated by ld.so as R_X86_64_GLOB_DAT to the real function wherever it comes from in the final process. It will not point to the PLT slot of libstdc++. ISO C++ does not specify the replacement specifics, they say only "displaces the default version defined by the C ++ standard library". Here they talk about them: http://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements I expect replacing an allocator needs to be done globally for a process as one may pass allocated objects ownership between program/libraries. That is typically from the main program or by LD_PRELOAD. Although cppreference talks about visibility so I guess they think replacing 'operator new' only in one ELF image (program / shared library) with -fvisibility=hidden is also valid. They talk about undefined behavior if the replacement is specific only to some TU which I also find obvious.
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #8 from Jan Kratochvil --- Created attachment 44236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44236=edit incredibleshrinkingvector.C What's wrong with this implementation? The permitted operator new symbols interposition was suggested by Pavel Labath at: https://reviews.llvm.org/D47492#1122080
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #6 from Jan Kratochvil --- (In reply to Marc Glisse from comment #5) > I can't find anywhere a guarantee that realloc doesn't move stuff when the > new size is smaller than the old. In practice it does not. > What would be the point of shrink_to_fit() otherwise? It was created as a > nicer alternative for people who were copying to a new temporary vector and > swapping them. It should be implemented in the most optimal way. ISO C++ standard does not talk about any copying: https://stackoverflow.com/questions/2664051/why-is-shrink-to-fit-non-binding/2664094
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #2 from Jan Kratochvil --- You apparently know better all the pitfalls, I just got shocked that a squeezing shrink_to_fit() does a copy.
[Bug libstdc++/86013] New: std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 Bug ID: 86013 Summary: std::vector::shrink_to_fit() could sometimes use realloc() Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- std::vector::shrink_to_fit() when reducing the size it still calls new()+copy. It could use realloc() when the objects are trivially copyable resulting in no copy during size reduction. Maybe it could even always call realloc() for size reduction of any type of objects and just assert the returned pointer did not change.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #10 from Jan Kratochvil --- It should affect all functions, not just main. But then GDB already needlessly expands so many CUs that usually when some function is needed its CU is already expanded. So maybe it is seen just accidentally on one trivial testcase.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #8 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #7) > Thanks. Is that something that can be fixed in GDB easily? Expecting a significant performance hit on initial scan of a file when .gdb_index/.debug_names is not present there. But personally I do not think that matters as such scanning without any index was always very slow, that is what the index is there for. I am leaving the fix and/or assignment of the fix up to Pedro.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #6 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #5) > where gdb sees the difference and why doesn't it make the file > containing main the default? pr43051-1.exe.good <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_low_pc : 0x400410 <124> DW_AT_high_pc : 0x3d ... pr43051-1.exe.bad <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_ranges : 0x0 ... GDB read_partial_die() does support DW_AT_low_pc+DW_AT_high_pc but not DW_AT_ranges. Therefore for pr43051-1.exe.bad GDB considers it only as a declaration of main() and not its definition, not worth expanding its CU.
[Bug driver/56062] Enhance -fuse-ld= option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #5 from Jan Kratochvil --- A use case would be: -fuse-ld=lld
[Bug driver/83243] New: -fuse-ld=lld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83243 Bug ID: 83243 Summary: -fuse-ld=lld Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- There is already: -fuse-ld=bfd -fuse-ld=gold but missing: -fuse-ld=lld -rwxr-xr-x 1 root root 1279512 Aug 2 20:35 /usr/bin/ld.bfd* -rwxr-xr-x 1 root root 3303248 Aug 2 20:35 /usr/bin/ld.gold* lrwxrwxrwx 1 root root 3 Aug 4 00:04 /usr/bin/ld.lld -> lld* $ rpm -qf /usr/bin/ld.* binutils-2.29-6.fc27.x86_64 binutils-2.29-6.fc27.x86_64 lld-4.0.1-4.fc27.x86_64 https://lld.llvm.org/
[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199 --- Comment #6 from Jan Kratochvil --- The Comment 5 binaries SEGV and do not start on Fedora 26 armv7l. But I do not see some wrong DWARF there. (In reply to Jan Kratochvil from comment #3) > Addresses are missing when the function is inlined. > But these testfiles do not use -O optimization so I find wrong if GCC has > inlined anything. I was sure wrong here, in this case the address is not displayed when it matches the first instruction of a source line. It could be rather bugreported to GDB how to make it reproducible (I haven't built GCC trunk on that Fedora 26 armv7l, though).
[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #3 from Jan Kratochvil --- Addresses are missing when the function is inlined. But these testfiles do not use -O optimization so I find wrong if GCC has inlined anything. Sorry I have not built trunk GCC (moreover on arm) to check it, maybe submitter can attach the binary files here?
[Bug c++/61940] Wrong error location for error in initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940 --- Comment #8 from Jan Kratochvil --- Still valid for: gcc-7.1.1-3.fc26.x86_64
[Bug c++/65188] improve error for member operator applied to non-class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65188 Jan Kratochvil changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Jan Kratochvil --- gcc-7.1.1-3.fc26.x86_64 1.C:2:23: error: invalid use of member function ‘void C::f()’ (did you forget the ‘()’ ?) It looks as fixed now.
[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132 Jan Kratochvil changed: What|Removed |Added Version|5.0 |7.1.1 --- Comment #3 from Jan Kratochvil --- gcc-7.1.1-3.fc26.x86_64 1.C:1:20: error: lvalue required as left operand of assignment Still not useful.
[Bug go/81183] New: -gdwarf-5: fatal error: unrecognized DWARF version in .debug_info at 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81183 Bug ID: 81183 Summary: -gdwarf-5: fatal error: unrecognized DWARF version in .debug_info at 6 Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jan.kratochvil at redhat dot com CC: cmang at google dot com Target Milestone: --- gcc-7.1.1-2.fc27.x86_64 cat >foo.go <
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 Jan Kratochvil changed: What|Removed |Added CC||palves at redhat dot com --- Comment #5 from Jan Kratochvil --- Returning gdb.Value means for GDB the pretty printer is printing its elements which are printed in a simplified way - suppressing their addresses - since: Message-Id: <20091110021158.c3c2576...@ppluzhnikov.mtv.corp.google.com> https://sourceware.org/ml/gdb/2009-11/msg00105.html Message-Id: <20091110214517.49a3e76...@ppluzhnikov.mtv.corp.google.com> https://sourceware.org/ml/gdb-patches/2009-11/msg00234.html commit 269f82e5eb0aa5d5b4c1accc858f95b62bc16df4 Printing an iterator means GDB should print the referenced element in its normal form - the referenced element are not data items of the iterator itself. The str() cast has a side-effect GDB will print format the data without the simplification from patch above. It may be weird that GDB value_print_options::deref_ref is off, therefore GDB then prints neither the reference address nor the referenced value. But that is unrelated IMO. No matter how weird the GDB printing is in the end I find str() does the right thing for GDB in this case.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #12 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized, safely updated to a valid value, but is
> not dereferenceable after the last statement.
>
> "print it" should not automatically dereference.
Therefore (at least with -D_GLIBCXX_DEBUG) "print it" (IMO) should
automatically dereference as it is safe - the iterator always does know if it
is valid or not.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #11 from Jan Kratochvil --- (In reply to Jonathan Wakely from comment #9) > Most developers don't even know the debug mode exists. That's a problem communicating it to users. -O0 -g would be best to always use -D_GLIBCXX_DEBUG if there is a way how to solve the ABI compatibility problem. > I don't know what "code for debugging with pretty printers" means. Users > don't do anything special for debugging with pretty printers, There are various kinds of bugs/crashes I am used to debug. For code where I benefit from pretty printers I can+do use -O0 -g -D_GLIBCXX_DEBUG during edit-compile-debug cycles. For system packages crashes (-O2 -g, no _GLIBCXX_DEBUG) there are so many variables, missing method instantiations and interleaved code there is no chance to start investigating data structures so thoroughly to benefit even from a pretty printer. YMMV. (In reply to Jonathan Wakely from comment #10) > This is all already done, isn't it? Wow, it really is. I remembered some worse experience with it. Thank you very much for this notification.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #8 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized, safely updated to a valid value, but is
> not dereferenceable after the last statement.
At the "}" line container gets destructed which should invalidate "it"
according to my last paragraph of Comment 6 and then "print it" would print a
message "invalidated iterator". Sure fully-managed iterators are a larger
feature request than this PR.
> "print it" should not automatically dereference.
This is GCC maintainers opinion; not mine.
> But most code isn't compiled with debug mode enabled.
IMO all code for debugging with pretty printers is compiled with debug mode
enabled. The other case are Linux system -O2 -g packages which are not really
debuggable up to the level of C++ containers at all. One is glad to get a
partially readable backtrace for a crash of a system package.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #6 from Jan Kratochvil --- (In reply to Jonathan Wakely from comment #5) > I think it's simply wrong to automatically dereference iterators. GDB > doesn't do that when printing pointers, so why do the pretty printers do it > for iterators? The difference is that pointer is memory-unmanaged and this is not fixable. But C++ data structures have memory management (at least they should have). > There are loads of cases where it does the wrong thing, not only for > past-the-end iterators but also for default-constructed ones that might > contain uninitialized pointers. Default-constructed iterators can be detected by _M_sequence==nullptr (-D_GLIBCXX_DEBUG). This all depends more on a different non-pretty-printers feature I plan to file for libstdc++ for years but I have never done so yet. With -D_GLIBCXX_DEBUG the iterators could be memory-managed - they already track their container by _M_sequence. The container could also track all its live iterators, elements could track iterators pointing at them (and properly invalidate them upon container updates) etc. Deleting the container would invalidate all its iterators etc. Accessing an invalidated iterator would then immediately assert. Then it is safe to pretty print any iterator as the iterator itself knows whether it has been invalidated or not.
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org Component|libstdc++ |debug Version|4.9.0 |6.2.1 --- Comment #3 from Jan Kratochvil --- valid for: gcc-6.2.1-2.fc26.x86_64
[Bug debug/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org Version|4.8.2 |6.2.1 --- Comment #4 from Jan Kratochvil --- gcc-6.2.1-2.fc26.x86_64
[Bug debug/59171] pretty printers: reverse iterator off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171 Jan Kratochvil changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #2 from Jan Kratochvil --- valid for: gcc-6.2.1-2.fc26.x86_64
[Bug driver/49726] [4.4/5/6/7 Regression] -g0 file.S -g does not produce debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726 Jan Kratochvil changed: What|Removed |Added Summary|-g0 file.S -g does not |[4.4/5/6/7 Regression] -g0 |produce debug info |file.S -g does not produce ||debug info --- Comment #3 from Jan Kratochvil --- I have forgotten this PR and I have hit it again: PASS: gcc (GCC) 4.2.5 20090330 (prerelease) FAIL: gcc (GCC) 4.4.7 FAIL: gcc (GCC) 7.0.0 20161107 (experimental) PASS: gcc-4.1.2-55.el5.x86_64 FAIL: gcc-6.2.1-2.fc24.x86_64 FAIL: gcc-4.4.7-17.el6.x86_64 FAIL: gcc-4.8.5-4.el7.x86_64 Unaware if it is a 4.3 regression or not, I do not have that version ready here.
[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204 --- Comment #2 from Jan Kratochvil --- Yes, that would be the best, to stay compatible with clang. Or is there some other way how to disable -fsanitize=float-divide-by-zero only for one function / block of code?
[Bug sanitizer/78204] New: ‘no_sanitize’ attribute directive ignored [-Wattributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
Bug ID: 78204
Summary: ‘no_sanitize’ attribute directive ignored
[-Wattributes]
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
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
Target Milestone: ---
g++ -o 44 44.C -Wall -g -fsanitize=bool -fsanitize=float-divide-by-zero;./44
-
int intzero(0);
//__attribute__((no_sanitize_undefined))
__attribute__((no_sanitize("float-divide-by-zero")))
int main() {
union { char c; bool b; } u={42};
double d(double(10)/intzero);
return u.b + d;
}
-
gcc-6.2.1-2.fc24.x86_64
clang 1:3.8-34 Ubuntu x86_64
- Fedora clang does not support ubsan
-
//__attribute__((no_sanitize_undefined))
__attribute__((no_sanitize("float-divide-by-zero")))
FAIL gcc: I want to suppress the "division by zero" message.
44.C:4:10: warning: ‘no_sanitize’ attribute directive ignored [-Wattributes]
int main() {
44.C:6:22: runtime error: division by zero
44.C:7:12: runtime error: load of value 42, which is not a valid value for type
'bool'
PASS clang++:
44.C:7:12: runtime error: load of value 42, which is not a valid value for type
'bool'
-
__attribute__((no_sanitize_undefined))
//__attribute__((no_sanitize("float-divide-by-zero")))
FAIL gcc: Missing "load of value 42, which is not a valid value for type
'bool'"
-
[Bug c++/72822] libiberty/ demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822 --- Comment #4 from Jan Kratochvil --- Comment 3 is for: https://bugzilla.redhat.com/show_bug.cgi?id=1377020
[Bug c++/72822] libiberty/ demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822 --- Comment #3 from Jan Kratochvil --- Without a fix I do not know if it is the same problem or not: _ZSt7forwardIRZZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmENUlRT_E_clIS7_EEDaSA_EUlvE_EOS9_RNSt16remove_referenceIS9_E4typeE https://bugzilla.redhat.com/show_bug.cgi?id=1367131
[Bug debug/77589] fortran: Missing DW_AT_byte_stride for an array record array selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589 --- Comment #1 from Jan Kratochvil --- Created attachment 39617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39617=edit dwarf-stridex.f90
[Bug debug/77589] New: fortran: Missing DW_AT_byte_stride for an array record array selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589 Bug ID: 77589 Summary: fortran: Missing DW_AT_byte_stride for an array record array selection Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- Fedora testcase: gdb.fortran/dwarf-stride.exp ! File written by Alan Matsuoka. FAIL: gcc-6.2.1-1.fc26.x86_64 PASS: gcc-4.8.5-4.el7.x86_64 gfortran -o dwarf-stridex dwarf-stridex.f90 -Wall -g;../gdb ./dwarf-stridex -batch -ex 'b 14' -ex r -ex 'p c40pt(2)' p c40pt(2)^M $2 = '\001\000\000\000\061-hello', ' ' ^M (gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2) p c40pt(2)^M $2 = '1-hello', ' ' ^M (gdb) PASS: gdb.fortran/dwarf-stride.exp: p c40pt(2) FAIL: <2><174>: Abbrev Number: 18 (DW_TAG_subrange_type) <175> DW_AT_lower_bound : (DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref) <17a> DW_AT_upper_bound : (DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref) PASS: <2><127>: Abbrev Number: 14 (DW_TAG_subrange_type) <128> DW_AT_lower_bound : (DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref) <12d> DW_AT_upper_bound : (DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref) <132> DW_AT_byte_stride : (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_fbreg: -80; DW_OP_deref; DW_OP_mul)
[Bug c++/72822] libiberty/ demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822 --- Comment #2 from Jan Kratochvil --- Without a fix I do not know if it is the same problem or not: _ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv
[Bug c++/72822] New: libiberty/ demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822 Bug ID: 72822 Summary: libiberty/ demangler crash Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- https://bugzilla.redhat.com/show_bug.cgi?id=1364588 r239179 2016-08-05 _ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv echo -e '\n_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv'|./test-demangle Segmentation fault [...] #44 0x0040cb94 in d_print_comp (dpi=0x7fffa190, options=, dc=) at cp-demangle.c:5594 #45 0x00408fa8 in d_print_comp_inner (dpi=0x7fffa190, options=275, dc=) at cp-demangle.c:4544 #46 0x0040cb94 in d_print_comp (dpi=0x7fffa190, options=, dc=) at cp-demangle.c:5594 #47 0x00408fe8 in d_print_comp_inner (dpi=0x7fffa190, options=275, dc=) at cp-demangle.c:4742 #48 0x0040afcf in d_print_comp (dc=, options=275, dpi=0x7fffa190) at cp-demangle.c:5594 #49 d_print_conversion (dc=0x7fffb018, options=275, dpi=0x7fffa190) at cp-demangle.c:5995 #50 d_print_comp_inner (dpi=0x7fffa190, options=275, dc=0x7fffb018) at cp-demangle.c:5212 #51 0x0040cb94 in d_print_comp (dpi=0x7fffa190, options=, dc=) at cp-demangle.c:5594 #52 0x00408fa8 in d_print_comp_inner (dpi=0x7fffa190, options=275, dc=) at cp-demangle.c:4544 #53 0x0040cb94 in d_print_comp (dpi=0x7fffa190, options=, dc=) at cp-demangle.c:5594 #54 0x00408fe8 in d_print_comp_inner (dpi=0x7fffa190, options=275, dc=) at cp-demangle.c:4742 #55 0x0040afcf in d_print_comp (dc=, options=275, dpi=0x7fffa190) at cp-demangle.c:5594 #56 d_print_conversion (dc=0x7fffb018, options=275, dpi=0x7fffa190) at cp-demangle.c:5995 #57 d_print_comp_inner (dpi=0x7fffa190, options=275, dc=0x7fffb018) at cp-demangle.c:5212 [...] #79591 0x00400fdd in main (argc=, argv=0x7fffd7a8) at test-demangle.c:317
[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906 --- Comment #3 from Jan Kratochvil --- Could you attach here the ICC .s file if you have it handy? Thanks.
[Bug debug/71906] New: Fortran allocatable strings debug info type size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906 Bug ID: 71906 Summary: Fortran allocatable strings debug info type size regression Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target Milestone: --- Description of problem: Some GDB testcases started to failing gcc-5.3.1 -> gcc-6.1.1. Version-Release number of selected component (if applicable): PASS: gcc-5.3.1-2.fc23.x86_64 FAIL: gcc-6.1.1-3.fc24.x86_64 FAIL: 7.0.0 20160716 (experimental) How reproducible: Always. Steps to Reproduce: cat >stringalloc.f90 < ( character*1 ) <2>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x111): var_char DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type: <0xd1> DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) <1>: Abbrev Number: 11 (DW_TAG_string_type) <1>: Abbrev Number: 6 (DW_TAG_pointer_type) DW_AT_byte_size : 8 DW_AT_type: <0xd0> Expected results: type = PTR TO -> ( character*10 ) <2><4c>: Abbrev Number: 3 (DW_TAG_variable) <4d> DW_AT_name: (indirect string, offset: 0x111): var_char <51> DW_AT_decl_file : 1 <52> DW_AT_decl_line : 2 <53> DW_AT_type: <0x7d> <57> DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) <1><78>: Abbrev Number: 6 (DW_TAG_string_type) <79> DW_AT_string_length: 2 byte block: 91 64 (DW_OP_fbreg: -28) <7c> DW_AT_byte_size : 4 <1><7d>: Abbrev Number: 7 (DW_TAG_pointer_type) <7e> DW_AT_byte_size : 8 <7f> DW_AT_type: <0x78> Additional info: There is also some additional unknown DIE but that does not seem to be related: <2><5a>: Abbrev Number: 4 (DW_TAG_variable) <5b> DW_AT_name: (indirect string, offset: 0x110): .var_char <5f> DW_AT_type: <0x83> <63> DW_AT_artificial : 1 <63> DW_AT_location: 2 byte block: 91 64 (DW_OP_fbreg: -28) <1><83>: Abbrev Number: 8 (DW_TAG_base_type) <84> DW_AT_byte_size : 4 <85> DW_AT_encoding: 5(signed) <86> DW_AT_name: (indirect string, offset: 0xeb): integer(kind=4) GDB above is Fedora gdb-7.11.1-75.fc24.x86_64, upstream GDB is not usable. But readelf -wi is enough for analysis of this problem.
[Bug c/70143] New: [6 Regression?] false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143
Bug ID: 70143
Summary: [6 Regression?] false strict-aliasing warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
struct a {
int i;
};
struct b {
struct a a;
int j;
};
int main(void) {
static struct b b;
struct a *ap=(struct a *)
return ((struct b *)>i)->j;
}
---
-Wall -O2
aliasing.c: In function ‘main’:
aliasing.c:11:19: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return ((struct b *)>i)->j;
^
FAIL:
gcc (GCC) 6.0.0 20160308 (experimental)
gcc-6.0.0-0.15.fc24
gcc-6.0.0-0.15.fc25
PASS:
gcc-6.0.0-0.14.fc24
gcc-5.3.1-2.fc23.x86_64
Pedro Alves said it is a GCC Bug so I am filing it here.
https://sourceware.org/ml/binutils/2016-03/msg00120.html
[Bug debug/65821] [4.9/5/6 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 --- Comment #9 from Jan Kratochvil --- -O2 -g does not show this problem so I am testing it with -O0 -g below: g++ (GCC) 4.7.3 20130221 (prerelease) 0x00400748 <+4>: sub$0x10,%rsp => 0x0040074c <+8>: mov0x200906(%rip),%eax# 0x601058 0x00400752 <+14>:add$0x3,%eax .debug_line: [0x0078] Special opcode 36: advance Address by 2 to 0x400744 and Line by 3 to 30 [0x0079] Special opcode 118: advance Address by 8 to 0x40074c and Line by 1 to 31 [0x007a] Extended opcode 4: set Discriminator to 1 [0x007e] Advance PC by constant 17 to 0x40075d [0x007f] Special opcode 104: advance Address by 7 to 0x400764 and Line by 1 to 32 Not OK, the line 5 of inlined function foo() is not present there at all. g++ (GCC) 6.0.0 20160205 (Red Hat 6.0.0-0.10) 0x00400645 <+4>: sub$0x10,%rsp => 0x00400649 <+8>: mov0x2009e5(%rip),%eax# 0x601034 0x0040064f <+14>:add$0x3,%eax .debug_line: [0x0104] Special opcode 50: advance Address by 3 to 0x400641 and Line by 3 to 30 [0x0105] Advance Line by -25 to 5 [0x0107] Special opcode 117: advance Address by 8 to 0x400649 and Line by 0 to 5 [0x0108] Advance Line by 26 to 31 [0x010a] Special opcode 173: advance Address by 12 to 0x400655 and Line by 0 to 31 This is basically OK, inlined function foo() is shown for its lines of code. The bug is that in both cases .debug_info does not contain DW_AT_inline-d DW_TAG_subprogram foo() as a child of DW_TAG_subprogram main() with its proper PC range 0x400649..0x400655 excl. This is why GDB shows: 5 /* 5 */ inline void foo(const int = (b+3)) (gdb) bt #0 main () at t.cc:5 while GDB should show: 5 /* 5 */ inline void foo(const int = (b+3)) (gdb) bt #0 foo (...) at t.cc:5 #1 main () at t.cc:31 But that would be still look wrong as it would show the latter case even after $ gdb -ex start ./t (therefore stopping at line 5 instead of expected line 31) because GDB currently shows the innermost inlined frame after stopping at a breakpoint. That is IMO a GDB bug and Fedora GDB was showing the outermost frame (so that then one "step"ped into the inlined functions without changing $pc) for some time. But current Fedora GDB is back again aligned with upstream GDB to the "buggy" behavior.
[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448 Jan Kratochvil changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Kratochvil --- Checked in trunk and 5.x.
[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448 --- Comment #1 from Jan Kratochvil --- https://bugzilla.redhat.com/show_bug.cgi?id=1279406
[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448 --- Comment #2 from Jan Kratochvil --- [patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448) https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html
[Bug libstdc++/68448] New: Python Pretty Printers get disabled on libstdc++ reload by GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
Bug ID: 68448
Summary: Python Pretty Printers get disabled on libstdc++
reload by GDB
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230621
138bc75d-0d04-0410-961f-82ee72b054a4
echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'
Actual:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = {<std::_Vector_base<int, std::allocator >> = {_M_impl =
{<std::allocator> = {<__gnu_cxx::new_allocator> = {},
}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}},
}
Expected:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = std::vector of length 0, capacity 0
[Bug libstdc++/68303] performance: unordered_map up to 7x speedup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68303 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #1 from Jan Kratochvil --- Created attachment 36694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36694=edit findbench.C
[Bug libstdc++/68303] New: performance: unordered_map up to 7x speedup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68303
Bug ID: 68303
Summary: performance: unordered_map up to 7x speedup
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
libstdc++ spends most of the time on:
div %rdi
computing modulo even when commonly the container is empty().
Moreover for small size()s it is more effective to iterate the container rather
than calculating the modulo.
-
template class unordered_map_find:public
unordered_map<From,To> {
private:
const size_t find_max_size=20;
public:
/***/ iterator find(const From ) /***/ {
if (unordered_map<From,To>::size()>find_max_size) // too big?
return unordered_map<From,To>::find(k);
for (auto it=unordered_map<From,To>::begin();;++it) // small => iterate
if (it==unordered_map<From,To>::end()||it->first==k)
return it;
}
};
#define unordered_map unordered_map_find
-
gcc-5.1.1-4.fc23.x86_64
g++ -o findbench findbench.C -Wall -g -std=c++11 -O3;sync;for i in `seq 0
30`;do ./findbench $i;done
orig wrapped
--- ---
0=1.094465 0=0.157921
1=1.119786 1=0.183768
2=1.169548 2=0.279629
3=1.347452 3=0.407056
4=1.479790 4=0.415102
5=1.301983 5=0.516378
6=1.326878 6=0.629252
7=1.467088 7=0.672654
8=1.681829 8=0.632880
9=1.755480 9=0.656492
10=1.712439 10=0.900121
11=1.515782 11=0.791073
12=1.351241 12=0.837695
13=1.434103 13=0.948055
14=1.671421 14=1.114046
15=1.683168 15=1.055906
16=1.521289 16=1.295058
17=1.537086 17=1.219568
18=1.766316 18=1.304961
19=1.807524 19=1.544631
20=1.848499 20=2.530600
21=1.895775 21=1.911767
22=1.792831 22=1.813895
23=1.562995 23=1.399753
24=1.560324 24=1.583886
25=1.419246 25=1.481225
26=1.609419 26=1.625853
27=1.482955 27=1.498665
28=1.483937 28=1.509582
29=1.506504 29=1.680078
30=1.522410 30=1.564460
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Kratochvil jan.kratochvil at redhat dot com --- Checked in Comment 4 fix.
[Bug c++/52960] Missing warnings on ambiguous source : function decl vs local var decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jan.kratochvil at redhat dot com --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- Missing keyword: diagnostic Valid for: g++ (GCC) 6.0.0 20150530 (experimental) clang-3.6.0-2.fc23.x86_64
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- Checked in.
[Bug debug/66069] New -fkeep-all-method-instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66069 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|6.0 |5.1.1 Resolution|--- |INVALID --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- PASS: gcc-5.1.1-1.fc22.x86_64 FAIL: gcc-4.9.2-6.fc21.x86_64 It is in fact already fixed thanks to Python xmethods. The option would still make some sense for custom non-libstdc++ templates if one does not write xmethods for them but that has probably only marginal usefulness.
[Bug debug/66069] New: New -fkeep-all-method-instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66069
Bug ID: 66069
Summary: New -fkeep-all-method-instances
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
Target: x86_64-linux-gnu
For debugging (-O0 -g) code there could be a way to provide all instantiable
methods for TYPE when anything from templateTYPE gets used. The problem:
---
1 #include memory
2 class C { public: int i; };
3 int main() {
4 std::unique_ptrC cp(new C());
5 return cp-i;
6 }
(gdb) p cp
$1 = std::unique_ptrC containing 0x603010
(gdb) p *cp
Could not find operator*.
---
compiled-in:
std::unique_ptrC, std::default_deleteC ::get() const
std::unique_ptrC, std::default_deleteC ::get_deleter()
std::unique_ptrC, std::default_deleteC ::operator-() const
std::unique_ptrC, std::default_deleteC ::unique_ptr(C*)
std::unique_ptrC, std::default_deleteC ::~unique_ptr()
---
The current workaround:
---
1 #include memory
2 class C { public: int i; };
3 int main() {
4 std::unique_ptrC cp(new C());
5 __attribute__((unused)) const C gdbstub(*cp);
^^
6 return cp-i;
7 }
(gdb) p *cp
$1 = (C ) @0x603010: {i = 0}
---
added method:
std::unique_ptrC, std::default_deleteC ::operator*() const
---
Similar problems are with operator[], operator- for maps etc.
[Bug debug/66069] New -fkeep-all-method-instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66069 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||pmuldoon at redhat dot com --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- I think so but that would require the source files available. So far 'compile print' (for C) generates all the context only from DWARF - this case was this PR's goal. The source files may not match well for *-debuginfo.rpm packaged binaries but IMO there is no chance for more complex debugging due to the -O2 -g debug info limitations.
[Bug libstdc++/59161] GDB pretty printers: iterator-reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- valid for: gcc-5.1.1-1.fc23.x86_64
[Bug debug/59171] pretty printers: reverse iterator off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171 --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- valid for: gcc-5.1.1-1.fc23.x86_64
[Bug debug/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- -D_GLIBCXX_DEBUG gcc-5.1.1-1.fc23.x86_64 (gdb) p end._M_current == ((std::__debug::vectorint, std::allocatorint *)end._M_sequence)._M_impl._M_finish $11 = true
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com ---
gcc-4.9.2-6.fc21.x86_64:
gcc-5.1.1-1.fc23.x86_64
#include debug/string
int main() { __gnu_debug::string s((const char *)0); }
g++ -o gcc59675b gcc59675b.C -Wall -g -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
./gcc59675b 2/dev/null
/usr/include/c++/5.1.1/debug/functions.h:315: const _CharT*
__gnu_debug::__check_string(const _CharT*) [with _CharT = char]: Assertion '__s
!= 0' failed.
Aborted
I was hitting this issue often on some older GCC versions but now I find it
very difficult to reproduce. __glibcxx_assert() is probably no longer too much
used. For some reason I could no longer even reproduce it with std::string.
[Bug plugins/65817] New: libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Bug ID: 65817
Summary: libcc1: ICE: SEGV: c_incomplete_type_error()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
r30
Current libcc1 uses just: make_node (RECORD_TYPE)
which crashes on:
if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
as TYPE_NAME (type) == NULL .
Actual:
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_PRE_GENERICIZE| libcc1plugin
PLUGIN_GGC_MARKING | libcc1plugin
PLUGIN_PRAGMAS | libcc1plugin
gdb command line:1:1: internal compiler error: Segmentation fault
0xb1c4af crash_signal
../../gccgitatsign/gcc/toplev.c:383
0x618794 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:282
0x623750 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:235
0x623750 build_component_ref(unsigned int, tree_node*, tree_node*)
../../gccgitatsign/gcc/c/c-typeck.c:2304
0x654fb3 c_parser_postfix_expression_after_primary
../../gccgitatsign/gcc/c/c-parser.c:7925
0x6478f6 c_parser_postfix_expression
../../gccgitatsign/gcc/c/c-parser.c:7715
0x649f5a c_parser_unary_expression
../../gccgitatsign/gcc/c/c-parser.c:6602
0x65122f c_parser_cast_expression
../../gccgitatsign/gcc/c/c-parser.c:6440
0x651412 c_parser_binary_expression
../../gccgitatsign/gcc/c/c-parser.c:6255
0x651f75 c_parser_conditional_expression
../../gccgitatsign/gcc/c/c-parser.c:6031
0x652560 c_parser_expr_no_commas
../../gccgitatsign/gcc/c/c-parser.c:5949
0x652c52 c_parser_expression
../../gccgitatsign/gcc/c/c-parser.c:8022
0x653689 c_parser_expression_conv
../../gccgitatsign/gcc/c/c-parser.c:8055
0x661978 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:5115
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x661a67 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:4964
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x65fc80 c_parser_declaration_or_fndef
../../gccgitatsign/gcc/c/c-parser.c:1982
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.
Compilation failed.
Expected:
gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’
1586c8fbaf0116931ffacd1746a6540c81c2d438 GDB commit
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35368
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35368action=edit
GDB patch
GDB patch to crash GCC.
together with:
cat 1.c EOH
// b tree.c:build_qualified_type
// p TYPE_SIZE (type)
volatile struct sv { volatile struct sv *p; } sv; // CRASH: compile code sv.p =
sv;
volatile struct s { int i; } s, *sp; // OK: compile code sp = s;
int main(void) { return 0; }
EOH
gcc -o 1 1.c -Wall -g;noGDBHOOK=1
PATH=/home/jkratoch/redhat/gccgitatsign-root/bin:$PATH
LD_LIBRARY_PATH=/home/jkratoch/redhat/gccgitatsign-root/lib64 ../gdb ./1 -ex
start -ex 'set debug compile 0' -ex 'compile code sv.p = sv;printf(%p
%p\n,sv,sv.p);'
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35369
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35369action=edit
Attempted GCC fix.
With this GCC fix and the GDB reproducer it looks as fixed:
gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’
But after running gdb.compile/compile.exp one gets another crash so this GCC
fix is probably not right.
compile code struct_object.selffield = struct_object^M
gdb command line:1:1: error: cannot convert gdb type to gcc type^M
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.^M
Event| Plugins^M
PLUGIN_PRE_GENERICIZE| libcc1plugin^M
PLUGIN_GGC_MARKING | libcc1plugin^M
PLUGIN_PRAGMAS | libcc1plugin^M
gdb command line:1:1: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in plugin_build_add_field, at
libcc1/plugin.cc:533^M
0xd7d007 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)^M
../../gccgitatsign/gcc/tree.c:9350^M
0x7f61d20f1084 tree_class_check(tree_node*, tree_code_class, char const*, int,
char const*)^M
../../gccgitatsign/libcc1/../gcc/tree.h:2969^M
0x7f61d20ef461 plugin_build_add_field(cc1_plugin::connection*, unsigned long
long, char const*, unsigned long long, unsigned long, unsigned long)^M
../../gccgitatsign/libcc1/plugin.cc:533^M
0x7f61d20f6407 cc1_plugin::connection::do_wait(bool)^M
../../gccgitatsign/libcc1/connection.cc:144^M
0x7f61d20f12be cc1_plugin::connection::wait_for_result()^M
../../gccgitatsign/libcc1/connection.hh:72^M
0x7f61d20f1edd cc1_plugin::status cc1_plugin::callint, gcc_c_oracle_request,
char const*(cc1_plugin::connection*, char const*, int*, gcc_c_oracle_request,
char const*)^M
../../gccgitatsign/libcc1/rpc.hh:227^M
0x7f61d20ee778 plugin_binding_oracle^M
../../gccgitatsign/libcc1/plugin.cc:278^M
0x5fe398 i_symbol_binding^M
../../gccgitatsign/gcc/c/c-decl.c:268^M
0x5fe398 lookup_name(tree_node*)^M
../../gccgitatsign/gcc/c/c-decl.c:3896^M
0x645e44 c_lex_one_token^M
../../gccgitatsign/gcc/c/c-parser.c:363^M
0x663633 c_parser_peek_token^M
../../gccgitatsign/gcc/c/c-parser.c:440^M
0x663633 c_parser_next_token_is^M
../../gccgitatsign/gcc/c/c-parser.c:452^M
0x663633 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4557^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x661a67 c_parser_statement_after_labels^M
../../gccgitatsign/gcc/c/c-parser.c:4964^M
0x663173 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4701^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x65fc80 c_parser_declaration_or_fndef^M
../../gccgitatsign/gcc/c/c-parser.c:1982^M
0x669a97 c_parser_external_declaration^M
../../gccgitatsign/gcc/c/c-parser.c:1452^M
0x66a359 c_parser_translation_unit^M
../../gccgitatsign/gcc/c/c-parser.c:1339^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
Compilation failed.^M
(gdb) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield =
struct_object
BTW the GDB patch is wrong, it is used only as a reproducer of the GCC crash.
[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168 --- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com --- (In reply to Manuel López-Ibáñez from comment #3) Does this patch work in your real-world code? There were just many tests like: if (!r) return 0; So it should really work, thanks.
[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168 --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- It should check the '!r' condition which makes no sense. The variable initialization in real world programs is too complicated to be able to figure out it may be NULL.
[Bug other/65366] gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366 --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- [patch] PR other/65366: Fix gdbhooks.py for GDB with Python3 https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00502.html
[Bug other/65366] New: gdbhooks.py is incompatible with Python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
Bug ID: 65366
Summary: gdbhooks.py is incompatible with Python3
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Host: x86_64-linux-gnu
GDB Python support upstream has always been compatible with Python3.
Fedora since F-22 builds GDB with Python3 by default (=F-21 GDB used Python2).
gdbhooks.py in GCC trunk is compatible with Python2 but not Python3.
gdb-7.9-10.fc23.x86_64
(gdb) source /home/jkratoch/redhat/gcchead/gcc/c/../gdbhooks.py
File /home/jkratoch/redhat/gcchead/gcc/c/../gdbhooks.py, line 372
print format_[i]
^
SyntaxError: Missing parentheses in call to 'print'
Additionally after fixing the 'print' incompatibility one gets randomly:
dependence_info = {clique = 257, Python Exception class 'NameError' name
'long' is not defined:
base = 1}}}, type = },
I have a patch, going to post it.
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 --- Comment #8 from Jan Kratochvil jan.kratochvil at redhat dot com --- Great, thanks.
[Bug other/65228] New: libcc1: ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Bug ID: 65228 Summary: libcc1: ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com CC: pmuldoon at redhat dot com Host: x86_64-linux-gnu Target: x86_64-linux-gnu FAIL: gcc (GCC) 5.0.0 20150226 (experimental) PATH=/home/jkratoch/redhat/gcchead-root/bin:$PATH LD_LIBRARY_PATH=/home/jkratoch/redhat/gcchead-root/lib64 /home/jkratoch/redhat/gdb-clean/gdb/gdb -nx gdb -ex start -ex 'compile code -r __auto_type qwe = def' gdb command line:1:19: error: ‘def’ undeclared here (not in a function) *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event| Plugins PLUGIN_PRE_GENERICIZE| libcc1plugin PLUGIN_GGC_MARKING | libcc1plugin PLUGIN_PRAGMAS | libcc1plugin gdb command line:2:1: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl, at c/c-decl.c:4469 0xd41bd4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /home/jkratoch/redhat/gcchead/gcc/tree.c:9462 0x605649 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /home/jkratoch/redhat/gcchead/gcc/tree.h:2960 0x605649 start_decl(c_declarator*, c_declspecs*, bool, tree_node*) /home/jkratoch/redhat/gcchead/gcc/c/c-decl.c:4469 0x640dec c_parser_declaration_or_fndef /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1802 0x65d317 c_parser_external_declaration /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1452 0x65dbd9 c_parser_translation_unit /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1339 0x65dbd9 c_parse_file() /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:15418 0x6b4062 c_common_parse_file() /home/jkratoch/redhat/gcchead/gcc/c-family/c-opts.c:1057 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. Compilation failed. (gdb) _ For gcc-5.0.0-0.15.fc23.x86_64 the same reproducer hangs due to FD not closed by the driver but that is a different bug. Filing as a tracker, I guess it is libcc1 specific so we should fix it.
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Component|other |c Host|x86_64-linux-gnu| Summary|libcc1: ICE: expected tree |ICE: expected tree that |that contains ‘decl |contains ‘decl minimal’ |minimal’ structure, have|structure, have |‘error_mark’ in start_decl |‘error_mark’ in start_decl --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- echo '__auto_type qwe = def'|/home/jkratoch/redhat/gcchead-root/bin/gcc -x c - produces the same internal error
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- Interesting that FSF GCC r220934 which should be gcc-5.0.0-0.16.fc23.x86_64 still crashes while that Fedora GCC does not crash.
[Bug c++/65188] New: diagnostic: missing: reference to non-static member function must be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65188
Bug ID: 65188
Summary: diagnostic: missing: reference to non-static member
function must be called
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-linux-gnu
class C { public: void f() {} } c;
int main() { return c.f.a; }
-Wall
g++ (GCC) 5.0.0 20150224 (experimental)
---
10.C: In function ‘int main()’:
10.C:2:21: error: ‘c.C::f’ does not have class type
int main() { return c.f.a; }
^
---
clang-3.5.0-6.fc21.x86_64
---
10.C:2:23: error: reference to non-static member function must be called; did
you mean to call it with no arguments?
int main() { return c.f.a; }
~~^
()
10.C:2:24: error: member reference base type 'void' is not a structure or union
int main() { return c.f.a; }
~~~^~
2 errors generated.
---
I had no idea what GCC errors on until I asked clang. It may be obvious here
but with complicated classes the better error message is really helpful.
[Bug c++/65188] improve error for member operator applied to non-class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65188
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
(In reply to Manuel López-Ibáñez from comment #1)
How does Clang message help in this case? The suggested fix 'c.f().a' will
just give 'invalid use of void type'
I have minimized the testcase maybe more than appropriate, it was in fact:
class D { public: int a; } d;
class C { public: D f() { return d; } } c;
int main() { return c.f.a; }
g++ (GCC) 5.0.0 20150224 (experimental)
---
10.C: In function ‘int main()’:
10.C:3:21: error: ‘c.C::f’ does not have class type
int main() { return c.f.a; }
^
---
clang-3.5.0-6.fc21.x86_64
---
10.C:3:23: error: reference to non-static member function must be called; did
you mean to call it with no arguments?
int main() { return c.f.a; }
~~^
()
1 error generated.
---
4) For types that have declarations, we could point to the declaration with
a note: 'c.C::f' declared here
Yes, that would be very useful.
[Bug c++/65168] New: diagnostic: missing: reference cannot be bound to dereferenced null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
Bug ID: 65168
Summary: diagnostic: missing: reference cannot be bound to
dereferenced null pointer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-linux-gnu
int main() {
int *p=static_castint *(0),r=*p;
return !r;
}
-Wall
g++ (GCC) 5.0.0 20150221 (experimental)
nothing
clang++ (clang-3.5.0-6.fc21.x86_64):
ref.C:3:12: warning: reference cannot be bound to dereferenced null pointer in
well-defined C++ code; pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
I have no idea if it can be miscompiled by either compiler. Still I find
useful to be notified I write non-conforming C++ code.
[Bug c++/65132] New: diagnostics: missing: bitfield member cannot have an in-class initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132
Bug ID: 65132
Summary: diagnostics: missing: bitfield member cannot have an
in-class initializer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
class C { bool x:1=false; };
g++ (GCC) 5.0.0 20150219 (experimental):
field.C:1:20: error: an assignment cannot appear in a constant-expression
clang-3.5.0-6.fc21.x86_64:
field.C:1:19: error: bitfield member cannot have an in-class initializer
I had no idea what GCC errors on until I asked clang.
[Bug debug/58123] [4.8/4.9/5 Regression] debug line not tracked for last autovariable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 --- Comment #8 from Jan Kratochvil jan.kratochvil at redhat dot com --- (In reply to Aldy Hernandez from comment #7) Putting this aside for a second, my question is, do we really want a debugging experience where we jump from back from the end of scope, back to the declaration of the class? I do not think so. Or if so then the destructor call needs to be marked with is_stmt=false; but GDB currently ignores is_stmt. It would then show the declaration line during backtrace from crashed destructor (I am not sure it would be better than the 4.7 last statement of the block).
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com --- libgcc2.i from Comment 0 builds for me now, thanks.
[Bug target/64300] New: s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300
Bug ID: 64300
Summary: s390x, ICE, unable to generate reloads, in
curr_insn_transform, at lra-constraints.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Host: x86_64-linux-gnu
Target: s390x-linux-gnu
Created attachment 34274
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34274action=edit
libgcc2.i
../gcchead/configure --prefix=/home/jkratoch/redhat/gccheads390x-root
--enable-languages=c --target=s390x-linux-gnu
I get the same ICE with:
CFLAGS=-g CXXFLAGS=-g CFLAGS_FOR_TARGET=-g CXXFLAGS_FOR_TARGET=-g
../gcchead/configure --prefix=/home/jkratoch/redhat/gccheads390x-root
--enable-languages=c --target=s390x-linux-gnu
r218702 | ian | 2014-12-13 02:58:46 +0100 (Sat, 13 Dec 2014) | 3 lines
/home/jkratoch/redhat/gccheads390x-build/./gcc/xgcc
-B/home/jkratoch/redhat/gccheads390x-build/./gcc/
-B/home/jkratoch/redhat/gccheads390x-root/s390x-linux-gnu/bin/
-B/home/jkratoch/redhat/gccheads390x-root/s390x-linux-gnu/lib/ -isystem
/home/jkratoch/redhat/gccheads390x-root/s390x-linux-gnu/include -isystem
/home/jkratoch/redhat/gccheads390x-root/s390x-linux-gnu/sys-include-g -O2
-m31 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC
-mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcchead/libgcc
-I../../../../gcchead/libgcc/. -I../../../../gcchead/libgcc/../gcc
-I../../../../gcchead/libgcc/../include -DHAVE_CC_TLS -o _addvdi3.o -MT
_addvdi3.o -MD -MP -MF _addvdi3.dep -DL_addvdi3 -c
../../../../gcchead/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
-save-temps
../../../../gcchead/libgcc/libgcc2.c: In function ‘__addvdi3’:
../../../../gcchead/libgcc/libgcc2.c:109:1: error: unable to generate reloads
for:
}
^
(insn 7 3 8 2 (parallel [
(set (reg/v:DI 48 [ w ])
(plus:DI (reg/v:DI 50 [ a ])
(reg/v:DI 51 [ b ])))
(clobber (reg:CC 33 %cc))
]) ../../../../gcchead/libgcc/libgcc2.c:103 324 {*adddi3_31}
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)))
../../../../gcchead/libgcc/libgcc2.c:109:1: internal compiler error: in
curr_insn_transform, at lra-constraints.c:3383
0x9aa548 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcchead/gcc/rtl-error.c:110
0x8df546 curr_insn_transform
../../gcchead/gcc/lra-constraints.c:3383
0x8e026e lra_constraints(bool)
../../gcchead/gcc/lra-constraints.c:4324
0x8d0621 lra(_IO_FILE*)
../../gcchead/gcc/lra.c:2277
0x891909 do_reload
../../gcchead/gcc/ira.c:5391
0x891909 execute
../../gcchead/gcc/ira.c:5561
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.
