https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63623
Bug ID: 63623
Summary: Lots of functions get -fvar-tracking silently turned
off unnecessarily
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
I have got a report that when glibc is compiled with gcc 4.8.x, the debug info
for the bytes parameter to __libc_malloc is wrong in the prologue (and
epilogue).
Here is a reduced testcase for x86_64-linux:
-std=gnu99 -fgnu89-inline -O2 -fmerge-all-constants -frounding-math -g -dA
-fPIC:
void *a;
extern void *(*d) (__SIZE_TYPE__, const void *);
void *foo (void *, __SIZE_TYPE__);
void *bar (void *, __SIZE_TYPE__);
void *
__libc_malloc (__SIZE_TYPE__ bytes)
{
void *b, *c;
if (__builtin_expect (d != 0, 0))
return d (bytes, 0);
b = a;
if (!b)
return 0;
c = foo (b, bytes);
if (!c)
b = bar (b, bytes);
return b;
}
r203167 on the trunk "fixed" this by slightly changing the CFG (because of the
__builtin_expect), so the bug went latent on this testcase.
I've investigated this and found that this is because the function doesn't have
frame pointer and vt_stack_adjustments failed on the function, which precludes
not just -fvar-tracking-assignments, but also -fvar-tracking altogether.
And the reason for that is that it doesn't handle i?86/x86_64 pop instructions,
like:
(insn/f:TI 76 81 77 8 (set (reg:DI 3 bx)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8])) rh1151226.i:19 75
{*popdi1}
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
where it doesn't account for any stack adjustment in such functions. Thus,
stack_adjust values may be either wrong in the VTA info, leading to wrong
debug, or, if because of that there is some disagreement on the edges between
what the stack_adjust value should be, it gives up on -fvar-tracking
altogether.
