Re: How can distinguish DECL in LTO mode?
Thanks for the info. On Sun, Aug 12, 2018, 23:30 Richard Biener wrote: > On August 12, 2018 12:30:26 PM GMT+02:00, zet wrote: > >Hello, everyone. > >Sorry to disturb you, but this question confused me several days, I > >have > >searched the GCC source code cannot find the answers. > > > >I know we can distinguish the different DECL tree using DECL_UID in a > >translation unit. But when in LTO mode, lto1 combine some input fat > >object > >files. How can I distinguish the different DECL tree may come from > >two different object files? > > Decl_uid is re-assigned during LTO streaming and thus still unique. > > Richard. > > > > >Thanks. > >
Re: issue with gt-lto-lto.h
On 08/11/2018 03:51 PM, Hrishikesh Kulkarni wrote: > Hi, > > With reference to GSOC project LTO dump tool. > https://github.com/hrisearch/gcc/tree/lto-dump-tool-v4 > > After refactoring lto.c into lto-common.c, there seems to be an issue > of gt-lto-lto.h not getting generated. I tried a few tweaks like > adding lto-common.c to config-lang.in, adding the include in > lto-common.c instead of lto.c, changing the include to > gt-lto-lto-common.h but none is working. I see that gt-lto-lto-lang.h > gets generated from lto-lang.c but not sure what's missing with > lto-common.c or refactored lto.c > Could you please suggest how to proceed ? The file is a generate file from garbage collector. You need to add also new files that you added: diff --git a/gcc/lto/config-lang.in b/gcc/lto/config-lang.in index ada21681c6a..5eee03303bf 100644 --- a/gcc/lto/config-lang.in +++ b/gcc/lto/config-lang.in @@ -20,7 +20,7 @@ language="lto" compilers="lto1\$(exeext) lto-dump\$(exeext)" -gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c \$(srcdir)/lto/lto.c \$(srcdir)/lto/lto.h" +gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c \$(srcdir)/lto/lto.c \$(srcdir)/lto/lto.h \$(srcdir)/lto/lto-common.h \$(srcdir)/lto/lto-common.c \$(srcdir)/lto/lto-dump.c" # LTO is a special front end. From a user's perspective it is not # really a language, but a middle end feature. However, the GIMPLE Martin > > Thanks! > > Hrishikesh >
Re: Proposal to extend -Wcoverage-mismatch diagnostic cases
On 08/09/2018 08:05 PM, Indu Bhagat wrote: > Wcoverage-mismatch is meant to "Warn in case profiles in -fprofile-use do not > match" > > Currently, gcc compiler warns about the following two cases of source code > changes which alert the programmer to re-generate the profiles : > > 1. Control flow mismatch > If functions' control flow has been altered after profile generation, the > profile count data will not be able to match the cfg_checksum. > Hence the warning, "warning: the control flow of function 'XXX' does not > match its profile data (counter 'YYY') [-Werror=coverage-mismatch]" > > 2. Function is physically moved to a different location > If existing functions are physically swapped in the source file, gcc alerts > the user about potentially stale profiles for all the affected functions. > > Hence the warning, "warning : source locations for function 'XXX' have > changed, the profile data may be out of date [-Werror=coverage-mismatch]" > > So, if new function foo() is added in the source file before existing > functions, gcc alerts the user about potentially stale profiles of the > already seen functions. > Note however, there is no warning about the new function foo(). > Hence, my > proposal #3 below which will cover foo() in this scenario. Hello. I would appreciate a warning for that. Will you work on a patch or should I do it myself? > > Proposing to add the following cases which are not currently covered : > > 3. If a new function foo() is added to the file. Proposal to add a warning > along > the lines of - > "warning : profile for function ‘XXX’ not found in profile data > [-Wcoverage-mismatch]" > The corner case of foo() being added to the end of the file is > exclusively > covered by #3. > > 4. A new source file is added to the project after profile generation phase. > Proposal to add a warning per function along the lines of - > "warning : profile count data file not found, regenerating profiles may > help [-Wcoverage-mismatch]" I was considering some time ago a warning when a profile is missing for a compilation unit. It's not only situation when a file is added. But one can also wipe somehow .gcda files in make clean and it worth informing a user. I tend to come up with a new warning maybe for it. Again are you planning to work on that? May I please ask you for a bugzilla entry both these issues? Thanks, Martin > > For both #3 and #4, gcc currently does not warn. Although, one can infer that > the count profile data for a specific function / file are missing from the > dump > files, adding warnings #3 and #4 makes the coverage-mismatch set of warnings > more complete for a better end user experience. >
gcov and flow control graph
Hello, After compilation of source code with flags -fprofile-arcs, -ftest-coverage and -fdump-tree-cfg-graph-lineno i get file with extension .cfg.dot which can be opened in graphviz, and files with extensions .gcda and .gcno when the program is executed. With gcov those files can be converted to coverage report with extension .gcov. Because control flow graph is created during compilation number of executions (FREQ) and percentage at which each branch is taken are equal to 0. Is there a way to update control flow graph with information from any of the files created after execution like .gcov or .gcda/.gcno? Thank you Best regards
Re: Static sem_item_optimizer instance in ipa-icf pass
On 08/01/2018 02:17 PM, Florian Rommel wrote: > Hi, > > I stumbled across this during my work on a gcc compiler plugin [1]. > > During the ipa-icf pass semantic items (`sem_function` and `sem_variable`) > are generated to find potential candidates for function or variable merging. Hello. Sorry for late answer. > > In `ipa-icf.c` there is a static variable `optimizer` (of type > `sem_item_optimizer`) which is initialized before and destroyed after the > ipa-icf pass. This variable is used by the semantic items. Therefore it is > not possible to use `sem_function` or `sem_variable` outside of the icf pass > (as the static optimizer is NULL). E.g. create a `sem_function` variable > with `sem_function::parse`. > > Is this intended? I would like to use `sem_function` objects (independently > from the icf pass) to compare functions that were generated by our gcc plugin > (or is this a bad idea). That can definitely done better, if I see correctly only reference from sem_item, sem_function and sem_variable is in sem_item::add_type. That can be removed. > > It seems that (non-static) member functions like > `sem_item_optimizer::parse_func_and_vars` use this static `optimizer` > instance (through some indirections [2]) which looks kinda wrong to me. Sure, that's strange. But I can't find the reference in current trunk. Can you please update to trunk and check the remaining problematic references? Thanks, Martin > > Regards, > Flo > > > [1] https://github.com/luhsra/multiverse > > [2] Calls: > sem_item_optimizer::parse_funcs_and_vars [ipa_icf.c:2666] > sem_function::parse [ipa_icf.c:1691] > sem_function::init [ipa_icf.c:1387] > sem_function::hash_stmt [ipa_icf.c:1617] > sem_function::add_type [ipa_icf.c:1547] > uses static sem_item_optimizer optimzer [ipa_icf.c:94] > > >
Re: gcov and flow control graph
On 08/13/2018 03:39 PM, daro...@o2.pl wrote: > Hello, After compilation of source code with flags -fprofile-arcs, > -ftest-coverage and -fdump-tree-cfg-graph-lineno i get file with extension > .cfg.dot which can be opened in graphviz, and files with extensions .gcda and > .gcno when the program is executed. With gcov those files can be converted to > coverage report with extension .gcov. Because control flow graph is created > during compilation number of executions (FREQ) and percentage at which each > branch is taken are equal to 0. Is there a way to update control flow graph > with information from any of the files created after execution like .gcov or > .gcda/.gcno? Thank you Best regards > Yes, if you use -fprofile-use and -fdump-tree-optimized-graph, then you'll see counts and frequencies as being read from .gcda profile. Profile is read from file in following IPA pass: main.c.065i.profile. 'optimized' is last tree pass, should be usable for you. Feel free to ask any further questions. Martin
Gcc 7 or higher for 32bit os
Hi respected, Hope you and your team is doing well. I need help about , that is there any gcc7 or higher package for Ubuntu 12 of 32bit os and Ubuntu 17 of 32bit os. If so can you share the link. Thanking yours Yogananda
Re: Gcc 7 or higher for 32bit os
On Mon, 13 Aug 2018 at 18:27, YOGAN wrote: > > Hi respected, > > Hope you and your team is doing well. > > I need help about , that is there any gcc7 or higher package for Ubuntu 12 > of 32bit os and Ubuntu 17 of 32bit os. This question is inappropriate on this mailing list, it belongs on the gcc-help list, not here. Even better, would be to ask in a Ubuntu forum. The GCC project does not provide binary packages.
Re: Gcc 7 or higher for 32bit os
Thanks, I'll look into it. On Mon 13 Aug, 2018, 11:01 PM Jonathan Wakely, wrote: > On Mon, 13 Aug 2018 at 18:27, YOGAN wrote: > > > > Hi respected, > > > > Hope you and your team is doing well. > > > > I need help about , that is there any gcc7 or higher package for Ubuntu > 12 > > of 32bit os and Ubuntu 17 of 32bit os. > > This question is inappropriate on this mailing list, it belongs on the > gcc-help list, not here. Even better, would be to ask in a Ubuntu > forum. The GCC project does not provide binary packages. >
Re: Error from dwarf2cfi.c in gcc vers 7.2.0
On 08/12/2018 02:38 PM, Dave Pitts wrote: I've been hacking with version 7.2.0 of gcc trying to adapt some old md files that I've got to this newer gcc. I've been getting errors from the dwarf2out_frame_debug_expr() function in dwarf2cfi.c line 1790 calling gcc_unreachable(). The expression being processed is a SET. The src operand is a MEM reference and the dest operand is a REG reference. If I run the compiler with the option -fno-asynchronous-unwind-tables I do NOT get the error and the generated code looks reasonable. (set (REG) (MEM)) is not one of the patterns handled by dwarf2out_frame_debug_expr. If this is an epilogue instruction to restore a register, then it should have a REG_CFA_RESTORE regnote which takes you to dwarf2out_frame_debug_cfa_restore instead. If you are missing REG_CFA_RESTORE regnotes, then you are probably missing other CFA related regnotes too. If this is not an epilogue register restore instruction, then you need to figure out why it was marked as frame related, and figure out what should have been done instead. Jim
Re: Proposal to extend -Wcoverage-mismatch diagnostic cases
On 08/13/2018 06:32 AM, Martin Liška wrote: On 08/09/2018 08:05 PM, Indu Bhagat wrote: Wcoverage-mismatch is meant to "Warn in case profiles in -fprofile-use do not match" Currently, gcc compiler warns about the following two cases of source code changes which alert the programmer to re-generate the profiles : 1. Control flow mismatch If functions' control flow has been altered after profile generation, the profile count data will not be able to match the cfg_checksum. Hence the warning, "warning: the control flow of function 'XXX' does not match its profile data (counter 'YYY') [-Werror=coverage-mismatch]" 2. Function is physically moved to a different location If existing functions are physically swapped in the source file, gcc alerts the user about potentially stale profiles for all the affected functions. Hence the warning, "warning : source locations for function 'XXX' have changed, the profile data may be out of date [-Werror=coverage-mismatch]" So, if new function foo() is added in the source file before existing functions, gcc alerts the user about potentially stale profiles of the already seen functions. Note however, there is no warning about the new function foo(). Hence, my proposal #3 below which will cover foo() in this scenario. Hello. I would appreciate a warning for that. Will you work on a patch or should I do it myself? Thanks for your response. Yes, I will work on this. I will create a bugzilla for both these new warnings. Indu Proposing to add the following cases which are not currently covered : 3. If a new function foo() is added to the file. Proposal to add a warning along the lines of - "warning : profile for function ‘XXX’ not found in profile data [-Wcoverage-mismatch]" The corner case of foo() being added to the end of the file is exclusively covered by #3. 4. A new source file is added to the project after profile generation phase. Proposal to add a warning per function along the lines of - "warning : profile count data file not found, regenerating profiles may help [-Wcoverage-mismatch]" I was considering some time ago a warning when a profile is missing for a compilation unit. It's not only situation when a file is added. But one can also wipe somehow .gcda files in make clean and it worth informing a user. I tend to come up with a new warning maybe for it. Again are you planning to work on that? May I please ask you for a bugzilla entry both these issues? Thanks, Martin For both #3 and #4, gcc currently does not warn. Although, one can infer that the count profile data for a specific function / file are missing from the dump files, adding warnings #3 and #4 makes the coverage-mismatch set of warnings more complete for a better end user experience.
