[Bug middle-end/86957] New: gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 Bug ID: 86957 Summary: gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ibhagatgnu at gmail dot com CC: mliska at suse dot cz Target Milestone: --- When using -fprofile-use in the FDO build, gcc currently does not warn about about the following two cases. Both the cases are related to a missing profiles. Discussed here on mailing list https://gcc.gnu.org/ml/gcc/2018-08/msg00048.html CASE 1 : Missing profile for a new function --- If a new function foo() is added to the file, gcc only warns about those existing functions whose source locations have been impacted by foo() by issuing the following : "warning : source locations for function 'XXX' have changed, the profile data may be out of date [-Werror=coverage-mismatch]" Proposal to add a warning for the new function foo() along the lines of - "warning : profile for function ‘XXX’ not found in profile data [-Wmissing-profile]" Note that, the corner case of foo() being added to the end of the file is exclusively covered by the proposed -Wmissing-profile CASE 2 : Missing profile for a compilation unit --- This is the case when, e.g., a new source file is added to the project after profile generation phase. Also, the case when somehow .gcda files are wiped out in a make clean etc. It is worth informing the user that profile generation is due. Proposal to add a warning per file along the lines of - "warning : profile count data file not found, regenerating profiles may help [-Wmissing-profile]" To contrast, -Wcoverage-mismatch covers the cases when profiles are STALE. -Wmissing-profile is intended to cover the cases when there is NO profile. I propose to keep the behaviour of -Wmissing-profile to be consistent with -Wcoverage-mismatch in that : 1. Both should be on by default and treated as errors by default in -fprofile-use FDO build 2. A user must use -Wno-error to just see them as warnings (with -fprofile-use).
[Bug gcov-profile/86957] gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 --- Comment #3 from Indu Bhagat --- Currently, GCC dumps some information in the dump files regarding functions not being executed in the training run (And, I agree its not satisfactorily direct). First, in the "Symbol table:" dump section in the .*i.profile dumpfile - a. functions which are not executed in the training run (hence, zero count profiles) are shown as "unlikely_executed". Thats the case when profiles are not estimated. b. If function profiles are estimated however (in -O1, -fguess-branch-probability is enabled), an "estimated_locally" appears alongside "unlikely_executed", e.g., ["Function flags: count: XXX (estimated locally, globally 0) body unlikely_executed"]. I see deeper classification in profile_count::dump (FILE *f) const API (which needs closer look), but I agree that we can improve the presented information regarding the quality of the profile. Perhaps abstracting out the somewhat superfluous information (in the current context), e.g., "globally 0" vs "globally 0 adjusted"... Why not additionally dump a clear "Profile Feedback" : "Run/Not run" per function in the dump file ? I need to take a closer look at the information being dumped currently before I make a proposal. But I agree that gcc can give clearer information. Will be happy to work on this as another CR.
[Bug gcov-profile/86957] gcc should warn about missing profiles for a compilation unit or a new function with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 --- Comment #5 from Indu Bhagat --- Proposed patch https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00367.html
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 --- Comment #1 from Indu Bhagat --- Thanks for the bug report. This is reproducible. Will look into it.
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 --- Comment #2 from Indu Bhagat --- I found the issue. I will send a fix soon, once testing on powerpc64, x86_64 finishes.
[Bug debug/102195] New: Missing DW_TAG_typedef when using qualified variable of typedef'd array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102195
Bug ID: 102195
Summary: Missing DW_TAG_typedef when using qualified variable
of typedef'd array
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ibhagatgnu at gmail dot com
Target Milestone: ---
$ cat typedef1.c
typedef int A[2][3];
const A a = {{4, 5, 6}, {7, 8, 9}};
$ gcc -g -c typedef1.c
$ objdump --dwarf=info typedef1.o
<1><1e>: Abbrev Number: 3 (DW_TAG_array_type)
<1f> DW_AT_type: <0x40>
<23> DW_AT_sibling : <0x34>
<2><27>: Abbrev Number: 1 (DW_TAG_subrange_type)
<28> DW_AT_type: <0x39>
<2c> DW_AT_upper_bound : 1
<2><2d>: Abbrev Number: 1 (DW_TAG_subrange_type)
<2e> DW_AT_type: <0x39>
<32> DW_AT_upper_bound : 2
<2><33>: Abbrev Number: 0
<1><34>: Abbrev Number: 4 (DW_TAG_const_type)
<35> DW_AT_type: <0x1e>
<1><39>: Abbrev Number: 5 (DW_TAG_base_type)
<3a> DW_AT_byte_size : 8
<3b> DW_AT_encoding: 7(unsigned)
<3c> DW_AT_name: (indirect string, offset: 0x52): long unsigned
int
<1><40>: Abbrev Number: 6 (DW_TAG_base_type)
<41> DW_AT_byte_size : 4
<42> DW_AT_encoding: 5(signed)
<43> DW_AT_name: int
<1><47>: Abbrev Number: 7 (DW_TAG_variable)
<48> DW_AT_name: a
<4a> DW_AT_decl_file : 1
<4b> DW_AT_decl_line : 2
<4c> DW_AT_decl_column : 9
<4d> DW_AT_type: <0x34>
<51> DW_AT_external: 1
<51> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><5b>: Abbrev Number: 0
If typedef'd type is a base type / struct, DW_TAG_typedef shows up.
$ cat typedef3.c
typedef struct foo
{
int a;
int b;
} bar;
const bar ba;
$ objdump --dwarf=info typedef3.o
<1><1e>: Abbrev Number: 3 (DW_TAG_structure_type)
<1f> DW_AT_name: foo
<23> DW_AT_byte_size : 8
<24> DW_AT_decl_file : 1
<25> DW_AT_decl_line : 1
<26> DW_AT_decl_column : 16
<27> DW_AT_sibling : <0x3e>
<2><2b>: Abbrev Number: 1 (DW_TAG_member)
<2c> DW_AT_name: a
<2e> DW_AT_decl_file : 1
<2e> DW_AT_decl_line : 3
<2f> DW_AT_decl_column : 7
<2f> DW_AT_type: <0x3e>
<33> DW_AT_data_member_location: 0
<2><34>: Abbrev Number: 1 (DW_TAG_member)
<35> DW_AT_name: b
<37> DW_AT_decl_file : 1
<37> DW_AT_decl_line : 4
<38> DW_AT_decl_column : 7
<38> DW_AT_type: <0x3e>
<3c> DW_AT_data_member_location: 4
<2><3d>: Abbrev Number: 0
<1><3e>: Abbrev Number: 4 (DW_TAG_base_type)
<3f> DW_AT_byte_size : 4
<40> DW_AT_encoding: 5(signed)
<41> DW_AT_name: int
<1><45>: Abbrev Number: 5 (DW_TAG_typedef)
<46> DW_AT_name: bar
<4a> DW_AT_decl_file : 1
<4b> DW_AT_decl_line : 5
<4c> DW_AT_decl_column : 3
<4d> DW_AT_type: <0x1e>
<1><51>: Abbrev Number: 6 (DW_TAG_const_type)
<52> DW_AT_type: <0x45>
<1><56>: Abbrev Number: 7 (DW_TAG_variable)
<57> DW_AT_name: ba
<5a> DW_AT_decl_file : 1
<5b> DW_AT_decl_line : 6
<5c> DW_AT_decl_column : 11
<5d> DW_AT_type: <0x51>
<61> DW_AT_external: 1
<61> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><6b>: Abbrev Number: 0
[Bug debug/102195] Missing DW_TAG_typedef when using qualified variable of typedef'd array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102195 --- Comment #2 from Indu Bhagat --- (In reply to Andrew Pinski from comment #1) > I think this is a dup of bug 8354. Possible. It looks like two distinct symptoms, but seem to be originating from the same underlying issue. I don't have enough expertise here to comment further. When I looked around a bit, the difference I noted is that in the function dwarf2out.c:modified_type_die, the qualified_type returned is NULL for typedef1.c but non-NULL for typedef3.c. dwarf2out.c:modified_type_die () : /* See if we already have the appropriately qualified variant of this type. */ qualified_type = get_qualified_type (type, cv_quals); Noting that the TREE information is organized differently for array vs not.
[Bug testsuite/101269] [12 Regression] new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101269 Indu Bhagat changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #3 from Indu Bhagat --- This should be fixed now. Is it ok to close the bug now ?
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #20 from Indu Bhagat --- Commit https://gcc.gnu.org/g:f007a638a86e4b59bef0a0d8efa5bb8c5e5b200a added support for targets to opt out of CTF/BTF support.
[Bug debug/102507] New: ICE in btf_finalize when compiling with -gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507 Bug ID: 102507 Summary: ICE in btf_finalize when compiling with -gbtf Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ibhagatgnu at gmail dot com Target Milestone: --- Noticed this ICE (in gmp) when bootstrapping GCC with -gbtf as an experiment. Program received signal SIGSEGV, Segmentation fault. 0x00ce775c in simple_hashmap_traits, unsigned int>::is_empty, unsigned int> >::hash_entry> (entry=...) at /gcc/gcc/hash-map-traits.h:75 75return H::is_empty (entry.m_key); Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.0.9.el7.x86_64 libgcc-4.8.5-16.el7.x86_64 libstdc++-4.8.5-16.el7.x86_64 (gdb) bt #0 0x00ce775c in simple_hashmap_traits, unsigned int>::is_empty, unsigned int> >::hash_entry> (entry=...) at /gcc/gcc/hash-map-traits.h:75 #1 0x00ce7bab in hash_map, unsigned int> >::hash_entry::is_empty (e=...) at /gcc/gcc/hash-map.h:71 #2 0x00ce8623 in hash_table, unsigned int> >::hash_entry, false, xcallocator>::is_empty (v=...) at /gcc/gcc/hash-table.h:541 #3 0x00ce8d30 in hash_table, unsigned int> >::hash_entry, false, xcallocator>::~hash_table (this=0x7088fe10, __in_chrg=) at /gcc/gcc/hash-table.h:681 #4 0x00ce8c20 in hash_map, unsigned int> >::~hash_map (this=0x7088fe10, __in_chrg=) at /gcc/gcc/hash-map.h:39 #5 0x00ce8c3a in finalize, unsigned int> > > (p=0x7088fe10) at /gcc/gcc/ggc.h:162 #6 0x00c31dd2 in finalizer::call (this=0x3fd29f8) at /gcc/gcc/ggc-page.c:333 #7 0x00c304be in ggc_handle_finalizers () at /gcc/gcc/ggc-page.c:1928 #8 0x00c30bd7 in ggc_collect (mode=GGC_COLLECT_HEURISTIC) at /gcc/gcc/ggc-page.c:2228 #9 0x01244668 in execute_one_pass (pass=0x3f2e730) at /gcc/gcc/passes.c:2639 #10 0x012446dd in execute_pass_list_1 (pass=0x3f2e730) at /gcc/gcc/passes.c:2656 #11 0x01244764 in execute_pass_list (fn=0x7077f600, pass=0x3f2e6d0) at /gcc/gcc/passes.c:2667 #12 0x012426a6 in do_per_function_toporder (callback=0x1244727 , data=0x3f2e6d0) at /gcc/gcc/passes.c:1773 #13 0x01245384 in execute_ipa_pass_list (pass=0x3f2e670) at /gcc/gcc/passes.c:3003 #14 0x00d1299a in ipa_passes () at /gcc/gcc/cgraphunit.c:2154 #15 0x00d12dcc in symbol_table::compile (this=0x708c6000) at /gcc/gcc/cgraphunit.c:2289 #16 0x00d13326 in symbol_table::finalize_compilation_unit (this=0x708c6000) at /gcc/gcc/cgraphunit.c:2537 #17 0x013a19fd in compile_file () at /gcc/gcc/toplev.c:483 #18 0x013a4b11 in do_compile () at /gcc/gcc/toplev.c:2233 #19 0x013a4df7 in toplev::main (this=0x7fffdcf0, argc=24, argv=0x7fffddf8) at /gcc/gcc/toplev.c:2372 #20 0x029109f2 in main (argc=24, argv=0x7fffddf8) at /gcc/gcc/main.c:39 Looks like the garbage collector, when cleaning up the btf_var_ids hash_map, is working on invalid memory and bails out.
[Bug testsuite/101269] new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101269 --- Comment #1 from Indu Bhagat --- Confirmed. This is reproducible with -m32.
[Bug debug/101283] Several tests fail on Darwin with -gctf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 Indu Bhagat changed: What|Removed |Added CC||ibhagatgnu at gmail dot com --- Comment #2 from Indu Bhagat --- I see that .section directive needs a different semantic for Darwin. The DWARF debug_info section, for example, appears as: .section __DWARF,__debug_info,regular,debug Lsection__debug_info: Ldebug_info0: This implies GCC needs to emit the .ctf section adhering to the required semantics. I see now that this recent commit adds the required CTF section name strings explicitly for Darwin (config/darwin.h). Not only that, accompanying changes need to be made in gas/bfd to support the new __CTF category or the CTF section ?
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #10 from Indu Bhagat --- (In reply to Iain Sandoe from comment #9) > (In reply to Iain Sandoe from comment #8) > > we are now left with (where I suspect that the remaining fails are an > > artefact of the way in which Darwin represents offsets instead of > > relocations in DWARF debug sections): > > on a bit more looking, that is probably not the reason - I guess we will > have to look at what the represented structures are and why they have > different renderings for Darwin. I am looking into these failures one by one.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #12 from Indu Bhagat ---
The intention is to be able to generate CTF/BTF correctly irrespective of the
DWARF version.
The case of DW_TAG_restrict_type is unique though, and looks like we will need
special handling. To be specific, the 'restrict' keyword related failures are:
- gcc.dg/debug/ctf/ctf-cvr-quals-1.c
- gcc.dg/debug/btf/btf-cvr-quals-1.c
DW_TAG_restrict_type is not generated for DWARF-2. So, adding a target specific
option for these looks like a reasonable way forward.
So for the btf testcase, something like -
/* { dg-options "-O0 -gbtf -dA -gdwarf-4" { target { *-*-darwin* } } } */
Next, for some of the *-bitfield-*.c test failures, the issue can be masked
away by forcing -gdwarf-4, yes. But the correct fix can be done in dwarf2ctf.c
and with that, there is not need to force a -gdwarf-4 in those tests.
I will post a patch for these two soon.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #14 from Indu Bhagat --- With the two patches (commit r12-2044-ga3543b5e8002c033b2304d7ac1d1e58218eebb51 + the other in review) only two further failures remain to be looked into: FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x2[\t ]+[^\n]*btm_type 1 FAIL: gcc.dg/debug/ctf/ctf-attr-mode-1.c scan-assembler-times [\t ]0x3[\t ]+[^\n]*ctv_typeidx 1 I will look into them next.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #18 from Indu Bhagat --- (In reply to Richard Biener from comment #4) > It might make sense to provide targets a means to opt-out of CTF/BTF support > and thus diagnose -gctf as unsupported on them. Yes, I agree. It makes sense to have provide some means to opt out of CTF/BTF support. I will look into this.
[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 Indu Bhagat changed: What|Removed |Added CC||ibhagatgnu at gmail dot com --- Comment #5 from Indu Bhagat --- The issue here is in the testcase. It is relying on the order of the generated CTF types. Adding -fno-short-enums might have masked the issue, ideally the testcase should be fixed by removing such a non-portable check. I noticed similar issues on Darwin for PR debug/101283 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 I think the following commit should have fixed this issue on arm-eabi as well. The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:d9e9532bb3bf5db4cd6afd49d343ede5b27c3c9f commit r12-2094-gd9e9532bb3bf5db4cd6afd49d343ede5b27c3c9f Author: Indu Bhagat Date: Tue Jul 6 16:11:47 2021 -0700 BTF testsuite: Remove explicit check on btm_type The value of btm_type is the BTF type ID of the referred type. The order in which the BTF types are added can change across platforms and also as the code evolves, hence changing the BTF type ID. As there is no direct and portable method of testing that a BTF type refers to another BTF type of a specific kind, remove the explicit check on btm_type. This patch adjusts the testcase without affecting the test coverage as other testcases already have similar constructs. It also fixes a subset of failures as seen on Darwin. 2021-07-06 Indu Bhagat gcc/testsuite/ChangeLog: PR debug/101283 * gcc.dg/debug/btf/btf-bitfields-3.c: Remove the check on btm_type. PS: I let -fno-short-enums remain in the testcase for now. If the patch fixes the issue while removing -fno-short-enums, the testcase can be updated to not have -fno-short-enums anymore.
