[Bug debug/111847] Debug info for structure member is not generated for structure in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111847 Jiří Engelthaler changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jiří Engelthaler --- Wrong bug report
[Bug debug/111847] New: Debug info for structure members is not generated for structure in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111847
Bug ID: 111847
Summary: Debug info for structure members is not generated for
structure in template class
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: EngyCZ at gmail dot com
Target Milestone: ---
Created attachment 56131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56131=edit
Sample source code
Source code attached.
No debug information for "a" member of structure variable *Str (A.Str->a)
GDB reports "No data fields":
(gdb) print
$1 = 0x7fffe1cf ""
(gdb) print A
$2 = {> = {Str = 0x7fffe1cf}, }
^^
[Bug pch/88219] New: Precompiled headers Segmentation fault in Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88219 Bug ID: 88219 Summary: Precompiled headers Segmentation fault in Cygwin Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: EngyCZ at gmail dot com Target Milestone: --- Created attachment 45099 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45099=edit Sample Hi, Precompiled headers feature doesn't work in Cygwin. Compilation terminates with Segmentation fault in cc1. Sample file attached. Same file is working in Linux I searched why and found that the result here https://github.com/gcc-mirror/gcc/blob/gcc-7_3_0-release/gcc/ggc-common.c#L626 is 1 in Linux and -1 in CygWin. GCC had to relocate PCH but it fails in fatal_error function call on line 629. Cygwin behavior can be "emulated" by commenting out "if (result < 0)" on line 628 With this the Linux version also fails with Segmentation fault. Thread 1 "cc1" received signal SIGSEGV, Segmentation fault. linemap_macro_map_lookup (line=480, set=0xffbdda40) at ../../gcc-7.3.0/libcpp/line-map.c:1021 1021 if (line >= MAP_START_LOCATION (cached)) (gdb) backtrace #0 linemap_macro_map_lookup (line=480, set=0xffbdda40) at ../../gcc-7.3.0/libcpp/line-map.c:1021 #1 linemap_lookup (set=set@entry=0xffbdda40, line=, line@entry=480) at ../../gcc-7.3.0/libcpp/line-map.c:946 #2 0x00f5467b in linemap_macro_loc_to_def_point (original_map=, location=480, set=) at ../../gcc-7.3.0/libcpp/line-map.c:1450 #3 linemap_resolve_location (set=0xffbdda40, loc=loc@entry=480, lrk=lrk@entry=LRK_MACRO_DEFINITION_LOCATION, map=map@entry=0xd43c2ac) at ../../gcc-7.3.0/libcpp/line-map.c:1582 #4 0x00f2f411 in diagnostic_report_current_module (context=context@entry=0x182fec0 , where=480) at ../../gcc-7.3.0/gcc/diagnostic.c:551 #5 0x008a406a in diagnostic_report_current_function (context=context@entry=0x182fec0 , diagnostic=diagnostic@entry=0xd43c3ec) at ../../gcc-7.3.0/gcc/tree-diagnostic.c:39 #6 0x008a40c9 in default_tree_diagnostic_starter (context=0x182fec0 , diagnostic=0xd43c3ec) at ../../gcc-7.3.0/gcc/tree-diagnostic.c:48 #7 0x00f3017d in diagnostic_report_diagnostic (context=, diagnostic=, diagnostic@entry=0xd43c3ec) at ../../gcc-7.3.0/gcc/diagnostic.c:962 #8 0x00f306af in diagnostic_impl (richloc=richloc@entry=0xd43c444, opt=opt@entry=-1, gmsgid=gmsgid@entry=0x11223ba <(anonymous namespace)::pass_data_rtl_pre+122> "had to relocate PCH", ap=ap@entry=0xd43c440, kind=kind@entry=DK_FATAL) at ../../gcc-7.3.0/gcc/diagnostic.c:1084 #9 0x00f30f6d in fatal_error (loc=480, gmsgid=gmsgid@entry=0x11223ba <(anonymous namespace)::pass_data_rtl_pre+122> "had to relocate PCH") at ../../gcc-7.3.0/gcc/diagnostic.c:1379 #10 0x006382ad in gt_pch_restore (f=f@entry=0x20052d80) at ../../gcc-7.3.0/gcc/ggc-common.c:629 #11 0x004a9104 in c_common_read_pch (pfile=0x2007dfe0, name=0x20109128 "largefile.h.gch", fd=4, orig_name=0x20109110 "largefile.h") at ../../gcc-7.3.0/gcc/c-family/c-pch.c:368 #12 0x00f4c86f in should_stack_file (loc=40964908, import=false, file=0x20109300, pfile=0x2007dfe0) at ../../gcc-7.3.0/libcpp/files.c:814 #13 _cpp_stack_file (pfile=0x2007dfe0, file=0x20109300, import=false, loc=40964908) at ../../gcc-7.3.0/libcpp/files.c:900 #14 0x00f4cd71 in _cpp_stack_include (pfile=pfile@entry=0x2007dfe0, fname=fname@entry=0x201090a8 "largefile.h", angle_brackets=0, type=type@entry=IT_INCLUDE, loc=40964908) at ../../gcc-7.3.0/libcpp/files.c:1049 #15 0x00f41f80 in do_include_common (pfile=0x2007dfe0, type=IT_INCLUDE) at ../../gcc-7.3.0/libcpp/directives.c:858 #16 0x00f429bd in _cpp_handle_directive (pfile=pfile@entry=0x2007dfe0, indented=0) at ../../gcc-7.3.0/libcpp/directives.c:547 #17 0x00f530b5 in _cpp_lex_token (pfile=pfile@entry=0x2007dfe0) at ../../gcc-7.3.0/libcpp/lex.c:2566 #18 0x00f5888d in cpp_get_token_1 (pfile=pfile@entry=0x2007dfe0, location=location@entry=0xd43c8a8) at ../../gcc-7.3.0/libcpp/macro.c:2462 #19 0x00f58d5d in cpp_get_token_with_location (pfile=0x2007dfe0, loc=loc@entry=0xd43c8a8) at ../../gcc-7.3.0/libcpp/macro.c:2648 #20 0x004a2805 in c_lex_with_flags (value=value@entry=0xd43c8ac, loc=loc@entry=0xd43c8a8, cpp_flags=cpp_flags@entry=0xd43c8b0 "", lex_flags=0) at ../../gcc-7.3.0/gcc/c-family/c-lex.c:398 #21 0x00437790 in c_lex_one_token (parser=parser@entry=0xd43c8a0, token=token@entry=0xd43c8a4) at ../../gcc-7.3.0/gcc/c/c-parser.c:248 #22 0x0045da0d in c_parser_peek_token (parser=0xd43c8a0) at ../../gcc-7.3.0/gcc/c/c-parser.c:435 #23 c_parse_file () at ../../gcc-7.3.0/gcc/c/c-parser.c:18171 #24 0x004a85fd in c_common_parse_file () at ../../gcc-7.3.0/gcc/c-family/c-opts.c:1107 #25 0x00865442 in compile_file () at ../../gcc-7.3.0/gcc/toplev.c:467 #26 0x01094f94 in do_compile () at ../../g
[Bug c++/80596] g++ generates incomplete DWARF debug information for array-typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80596 Jiří Engelthaler changed: What|Removed |Added CC||EngyCZ at gmail dot com --- Comment #3 from Jiří Engelthaler --- (In reply to Richard Biener from comment #1) > It works for me on the GCC 6 branch but is still broken on the gcc 5 branch > and with GCC 6.3.0. I believe there's a duplicate bugreport for this, it > looks like > PR77363. The patch (r239930) is included in 6.3.0 release (r243837)
[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363 Jiří Engelthaler changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiří Engelthaler --- Confirmed that the patch fixes my case in GCC 5.4.0. Please backport the patch to gcc-5 branch.
[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363 --- Comment #3 from Jiří Engelthaler --- This pr68162 breaks the function
[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363 Jiří Engelthaler changed: What|Removed |Added Known to work||5.3.0 --- Comment #2 from Jiří Engelthaler --- Investigating the bug I found that GCC 5.3.0 is partially correct, same way as 4.8 and 4.9. The bug was introduced by this revision https://gcc.gnu.org/viewcvs/gcc?view=revision=231673 GIT 0c4341e59b724e51deb033a64e057159f27de7dd
[Bug c++/77363] New: Missing debug information in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363 Bug ID: 77363 Summary: Missing debug information in DWARF Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: EngyCZ at gmail dot com Target Milestone: --- Created attachment 39489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39489=edit example.c I have found a missing debug information in dwarf for file compiled with g++. Same file compiled with gcc has correct debug information. I have compiled the file as g++ -c -g example.c Export debug information as readelf -wi example.o >deb There is a missing information for type tHash1 <1><2b>: Abbrev Number: 3 (DW_TAG_typedef) <2c> DW_AT_name: (indirect string, offset: 0x23): tHash1 <30> DW_AT_decl_file : 1 <31> DW_AT_decl_line : 4 but for the type tHash2 the information is correct <1><39>: Abbrev Number: 4 (DW_TAG_typedef) <3a> DW_AT_name: (indirect string, offset: 0x2a): tHash2 <3e> DW_AT_decl_file : 1 <3f> DW_AT_decl_line : 5 <40> DW_AT_type: <0x44><--- OK I ask someone to confirm the bug. example.c attached
[Bug driver/68029] Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #10 from Jiří Engelthaler --- Will this bug be resolved in 6.0 release?
[Bug driver/68029] Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #7 from Jiří Engelthaler --- Created attachment 36638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36638=edit diag_color.patch fdiagnostics_color_idx can by on first place so comparing as > 1 will miss it. There should be >= 1
[Bug driver/68029] Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #9 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #8) > > Good catch! In principle your patch seems correct. I think you are only > missing a testcase. This patch is small enough to not require a copyright > assignment: > > https://gcc.gnu.org/wiki/GettingStarted#Basics: > _Contributing_to_GCC_in_10_easy_steps Hi. I'm not able to create a test case because first xgcc parameters are controlled by GCC testsuite itself.
[Bug driver/68029] Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #5 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #4) > (In reply to Jiří Engelthaler from comment #3) > > (In reply to Manuel López-Ibáñez from comment #2) > > > What does -### show for the call to cc1 ? My commit r228094 to > > > opts-common.c > > > should have fixed this. > > > > $ gcc -fdiagnostics-color=never a.c -### > > cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a -o > > /tmp/cclEySGP.s > > To be honest, I don't have any clue why this is happening. This output seems > to happen before calling any code in opts-common.c as a result of the specs. > But why the specs will be touching -fdiagnostics-color=? I don't know much > about how the specs work. > > If reverting the patch fixes the problem, please go ahead and just reopen > the bug fixed by it. I have tested GCC with reverted r228094 and there is not problem reported by this bug. I'm asking someone with rights to reopen the bug 67640 and link it to this one.
[Bug driver/68029] Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #3 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #2) > What does -### show for the call to cc1 ? My commit r228094 to opts-common.c > should have fixed this. $ gcc -fdiagnostics-color=never a.c -### cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a -o /tmp/cclEySGP.s --- $ gcc -### -fdiagnostics-color=never a.c cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a "-fdiagnostics-color=never" -o /tmp/ccSOGrIR.s --- $ gcc a.c -fdiagnostics-color=never -### cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a "-fdiagnostics-color=never" -o /tmp/ccR4q0g6.s --- $ gcc -### a.c -fdiagnostics-color=never cc1.exe -quiet -D__USES_INITFINI__ a.c -quiet -dumpbase a.c -auxbase a "-fdiagnostics-color=never" -o /tmp/ccc7zgdo.s
[Bug c/68029] New: Strange behavior of -fdiagnostics-color option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 Bug ID: 68029 Summary: Strange behavior of -fdiagnostics-color option Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: EngyCZ at gmail dot com Target Milestone: --- Hi. In current trunk version of GCC 6.0 compiler I have found strange behavior of -fdiagnostics-color option gcc.exe -fdiagnostics-color=never a.c will output colored error: a.c: No such file or directory gcc.exe a.c -fdiagnostics-color=never will output not colored error: a.c: No such file or directory gcc --version gcc (GCC) 6.0.0 20151020 (experimental)
