comp_type_attributes
Hello, I am trying to understand comp_type_attributes, which checks whether attributes are compatible. From what I understand, on many platforms, that function can only ever return 1. Indeed, it does some checks to know whether it can answer 1, and if not it forwards to the target, which by default just returns 1. It looks like it could directly forward to the target. Which would leave the pretty printer as the only user of the affects_type_identity property of an attribute... Now the reason I looked at this is because I was expecting a different behavior. I added a new (function type) attribute in a front-end and specified that it affects type identity. When comp_type_attributes sees this attribute in one type but not the other, it can't answer yes, so it forwards to the target. The target just answers yes by default (some check for their own attributes, but they ignore the rest). Is that what's supposed to happen? I can use another mechanism than attributes, but this looks suspicious. -- Marc Glisse
Getting rid of duplicate .debug_ranges
Hi,
I noticed that when you generate dwarf for an inlined function it often
comes with duplicate range lists for both the DW_TAG_inlined_subroutine
and the child DW_TAG_lexical_block DIE. For example:
static int k;
static int foo (int i)
{
int j = i + 42;
return k + (j > 14 ? j : i);
}
int main (int argc, char **argv)
{
int c = argc;
k = 2 * c;
c = foo (c);
return c;
}
Generates with -O2 -gdwarf-4:
DWARF section [27] '.debug_info' at offset 0x895:
[Offset]
Compilation unit at offset 0:
Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
[...]
[a8] inlined_subroutine
abstract_origin (ref4) [31]
entry_pc (addr) 0x00400360
ranges (data4) range list [ 0]
call_file(data1) 1
call_line(data1) 13
[bb]formal_parameter
abstract_origin (ref4) [42]
location (block1)
[ 0] reg5
[c2]lexical_block
ranges (data4) range list [40]
[c7] variable
abstract_origin (ref4) [4b]
location (data4) location list [23]
[...]
DWARF section [32] '.debug_ranges' at offset 0xb4e:
[ 0] 0x00400360 ..0x00400363
0x00400366 ..0x00400369
0x0040036f ..0x00400374
[40] 0x00400360 ..0x00400363
0x00400366 ..0x00400369
0x0040036f ..0x00400374
[80] 0x00400360 ..0x00400375
So range list 0 for the inlined_subroutine DIE a8 is the same as range
list 40 for the lexical_block DIE c2.
I had hoped I could detect and then reduce the duplication of the range
lists in this case with the attached patch where I just check that the
basic block numbers for the ranges are the same as the ranges of its
context DIE. But that doesn't actually work since by looking at the
generated assembly the basic block asm labels are in the same place,
the block numbers are actually different (and so there are actually
two differently named/numbered labels generated at the same place). e.g:
.LVL0:
.LBB4:
.LBB5:
.loc 1 5 0
leal42(%rdi), %eax
.LBE5:
.LBE4:
.loc 1 12 0
leal(%rdi,%rdi), %edx
.LBB8:
.LBB6:
.loc 1 6 0
cmpl$14, %eax
.LBE6:
.LBE8:
.loc 1 12 0
movl%edx, k(%rip)
.LVL1:
.LBB9:
.LBB7:
.loc 1 6 0
cmovle %edi, %eax
.LVL2:
addl%edx, %eax
.LBE7:
.LBE9:
.loc 1 15 0
ret
.cfi_endproc
[...]
.section.debug_ranges,"",@progbits
.Ldebug_ranges0:
.quad .LBB4
.quad .LBE4
.quad .LBB8
.quad .LBE8
.quad .LBB9
.quad .LBE9
.quad 0
.quad 0
.quad .LBB5
.quad .LBE5
.quad .LBB6
.quad .LBE6
.quad .LBB7
.quad .LBE7
.quad 0
.quad 0
.quad .LFB1
.quad .LFE1
.quad 0
.quad 0
Is there a way to detect that basic blocks have the same range even
though they have different block numbers? Or am I not looking/thinking
about this issue correctly?
Thanks,
Mark
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f9f4295..53776f7 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3291,6 +3291,7 @@ static int same_dw_val_p (const dw_val_node *, const
dw_val_node *, int *);
static int same_attr_p (dw_attr_ref, dw_attr_ref, int *);
static int same_die_p (dw_die_ref, dw_die_ref, int *);
static int same_die_p_wrap (dw_die_ref, dw_die_ref);
+static int same_range_p (tree, dw_die_ref, unsigned int *);
static void compute_section_prefix (dw_die_ref);
static int is_type_die (dw_die_ref);
static int is_comdat_die (dw_die_ref);
@@ -6586,6 +6587,47 @@ same_die_p_wrap (dw_die_ref die1, dw_die_ref die2)
return ret;
}
+/* Is the range of the tree the same as that of the (context) die? */
+
+static int
+same_range_p (tree stmt, dw_die_ref die, unsigned int *off)
+{
+ dw_attr_ref attr;
+ unsigned i;
+ int num;
+ tree chain;
+
+ attr = get_AT (die, DW_AT_ranges);
+ if (! attr)
+return 0;
+
+ *off = attr->dw_attr_val.v.val_offset;
+
+ i = ((*off) / 2) / DWARF2_ADDR_SIZE;
+ num = ranges_table[i].num;
+
+ if (num != BLOCK_NUMBER (stmt))
+return 0;
+
+ chain = BLOCK_FRAGMENT_CHAIN (stmt);
+ do
+{
+ i++;
+ num = ranges_table[i].num;
+ if (num != BLOCK_NUMBER (chain))
+ return 0;
+ chain = BLOCK_FRAGMENT_CHAIN (chain);
+}
+ while (chain);
+
+ i++;
+ num = ranges_table[i].num;
+ if (num != 0)
+return 0;
+
+ return 1;
+}
+
/* The prefix to attach to symbols on DIEs in the current comdat debug
info section. */
static char *co
[wwwdocs PATCH] for Re: GCC mirror
On Wed, 11 Jan 2012, NetGull Administrator wrote: > I've just set up a new GCC mirror. Information is as follows: > > URL: http://www.netgull.com/gcc/ > Frequency:once a day > Location:San Jose, California, United States, North America > Contact: ad...@netgull.com > > Please, add my GCC mirror to your mirror list; > for any further clarification don't hesitate to contact me. I just added your server, per the patch below. Thanks for mirroring us and letting us know about it! Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.214 diff -u -3 -p -r1.214 mirrors.html --- mirrors.html25 Oct 2011 17:46:07 - 1.214 +++ mirrors.html15 Jan 2012 19:48:01 - @@ -53,6 +53,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet.bs) US, Phoenix: http://fileboar.com/gcc/";>fileboar.com, thanks to Grigory Rayskin (rayskin73 at gmail.com) US, Saint Louis: http://gcc.petsads.us";>http://gcc.petsads.us, thanks to Sergey Kutserey (s.kutserey at gmail.com) +US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin at netgull.com US, Tampa: http://mirrors-us.seosue.com/gcc/";>http://mirrors-us.seosue.com/gcc/, thanks to Peter Vrzak (petervrzak at gmail.com)
trouble emilinating redundant compares
In the port I'm working on I have used the newer CC tracking technique
(i.e. not cc0). I have followed the directions at the top of
compare-elim.c and have the following pattern for addhi3
(define_insn "addhi3"
[
(set (match_operand:WORD 0 "register_operand" "=r,r,r")
(plus:WORD (match_operand:WORD 1 "register_operand"
"0,0,0")
(match_operand:WORD 2 "rhs_operand"
"m,r,i")))
(set (reg:CC CC_REGNUM)
(compare:CC
(plus:WORD
(match_dup 1)
(match_dup 2))
(const_int 0)))
]
""
"@
add\t\t%0,[%2]
add\t\t%0,%2
add\t\t%0,#%2"
[(set_attr "length" "4,2,2")]
)
the following code snippet
int x, y;
char ch1 = 1, ch2 = -2;
...
if( --x )
{
ch1 = ch2;
}
produces the following rtl
(insn 5 2 6 2 (set (reg:HI 0 r0 [orig:17 x ] [17])
(mem/c/i:HI (symbol_ref:HI ("x") ) [0
x+0 S2 A16])) t.c:6 60 {*movhihi}
(expr_list:REG_EQUIV (mem/c/i:HI (symbol_ref:HI ("x") 0xb76fe0c0 x>) [0 x+0 S2 A16])
(nil)))
+(insn 6 5 7 2 (parallel [
+(set (reg:HI 0 r0 [orig:15 x.1 ] [15])
+(plus:HI (reg:HI 0 r0 [orig:17 x ] [17])
+(const_int -1 [0x])))
+(set (reg:CC 6 flags)
+(compare:CC (plus:HI (reg:HI 0 r0 [orig:17 x ] [17])
+(const_int -1 [0x]))
+(const_int 0 [0])))
+]) t.c:6 20 {addhi3}
+ (nil))
(insn 7 6 8 2 (set (mem/c/i:HI (symbol_ref:HI ("x") x>) [0 x+0 S2 A16])
(reg:HI 0 r0 [orig:15 x.1 ] [15])) t.c:6 61 {*storehihi}
(nil))
?(insn 8 7 9 2 (set (reg:CC 6 flags)
?(compare:CC (reg:HI 0 r0 [orig:15 x.1 ] [15])
?(const_int 0 [0]))) t.c:6 53 {comparehi3}
? (nil))
(jump_insn 9 8 10 2 (set (pc)
(if_then_else (eq (reg:CC 6 flags)
(const_int 0 [0]))
(label_ref:HI 15)
(pc))) t.c:6 73 {cbranchcc4}
(expr_list:REG_BR_PROB (const_int 3900 [0xf3c])
(nil))
-> 15)
(insn 18 11 12 3 (set (reg:QI 0 r0)
(mem/v/c/i:QI (symbol_ref:HI ("ch2") [flags 0x2] 0xb76fe240 ch2>) [0 ch2+0 S1 A8])) t.c:8 62 {*movqiqi}
(nil))
(insn 12 18 15 3 (set (mem/v/c/i:QI (symbol_ref:HI ("ch1") [flags 0x2]
) [0 ch1+0 S1 A8])
(reg:QI 0 r0)) t.c:8 62 {*movqiqi}
(nil))
I've marked the (plus-1) operation with + in the left border and the
subsequent compare the duplicates the CC_REG setting with ? in the left
border.
As you can see, the redundant compare hasn't been eliminated and there
are no clobbers that should require a re-compare.
I've used gdb to trace through compare-elim.c and discovered that the
problem is
conforming_compare (rtx insn)
calling
set = single_set (insn);
on the parallel [plus:compare] operation and not finding the compare:CC
sub-operation because the plus::HI operation doesn't include a DEAD_REG
note (and I can't see that it should).
I'm clearly missing something... can anyone provide a hint ?
Paul S
Changes to GNAT Library - is this the right place?
I would like to make a change to the GNAT.SHA1 library. I hope this is the right mailing list. Currently, this library only supports the return of a String digest of the SHA1 sum. I would like to be able to access the H member of the Context so that I can work with the 5x32-bit integers that make up the hash. I am happy to make the change myself, but I am a first-time contributer and am unsure of the process.
Re: Changes to GNAT Library - is this the right place?
On 1/15/2012 7:21 PM, Mr Anthony Arnold wrote: I would like to make a change to the GNAT.SHA1 library. I hope this is the right mailing list. Currently, this library only supports the return of a String digest of the SHA1 sum. I would like to be able to access the H member of the Context so that I can work with the 5x32-bit integers that make up the hash. I am happy to make the change myself, but I am a first-time contributer and am unsure of the process. Any change to the interface of a GNAT hierarchy package has to be done very carefully to absolutely minimize non-upward compatibility. With this in mind, feel free to propose a patch. You will need to make sure you have a copyright assignment form on file with the FSF before you can make any contributions.
Re: question on inconsistent generated codes for builtin calls
On Fri, Jan 13, 2012 at 10:17 PM, Amker.Cheng wrote:
> On Fri, Jan 13, 2012 at 5:33 PM, Richard Guenther
> wrote:
>>
>> No, I think the check is superfluous and should be removed. I also wonder
>> why we exempt BUILT_IN_FREE here ... can you dig in SVN history a bit?
>> For both things?
Hi Richard,
The BUILT_IN_FREE was introduced in r138362 fixing PR36970,
in which gcc did not give warning on freeing non-heap memory, as in program:
main ()
{
char array[100];
free (array);
}
I will run make check to see whether it's ok we do not check
DECL_ASSEMBLER_NAME_SET_P and send a patch then.
BTW, should I create a bug for this?
Thanks.
