This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RTL/VCG inconsistency (the check_match.7758 case)
- From: "Sunzir Deepur" <sunzird at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 24 Oct 2007 11:11:01 +0200
- Subject: RTL/VCG inconsistency (the check_match.7758 case)
Hello list,
I have enountered some inconsistency in the RTL/VCG output
and I wonder if it is fixable (and how).
This problem arises when compiling a C file with a nested routine. In this case
the symbol of the nested routine is added a numeric suffix (like
static definitions
from within a function). For example, if the nested routing is "check_match",
the actual symbol will be "check_match.7758" (while the number is dependant
on previous declarations in that file).
And indeed I can see that RTL call instructions use the new symbol name:
(call (mem:QI (symbol_ref:SI (\"check_match.7758\") [flags 0x3] <function_decl
0x404a3e80 check_match>) [0 S1 A8])
But the definition of the check_match function still uses the original
symbol name:
graph: { title: "check_match"
folding: 1
hidden: 2
node: { title: "check_match.0" }
...and so forth... all of the nodes and the edges are based on "check_match"
as the name of the function, and not on "check_match.7758".
(these are generated by the -dv -fdump-rtl-all flags).
Any idea on why this inconsistency happen and how to solve it
(probably the VCG dumper should somehow use "check_match.7758" as the base
of the function name and not "check_match") ?
Thank you,
sunzir.