https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #10 from Jakub Jelinek ---
(In reply to Ulrich Weigand from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> > (or could be) involved, then G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #9 from Ulrich Weigand ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Ulrich Weigand from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > What is done on other arches?
> >
> > That depends on the pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #8 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #5)
> Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> (or could be) involved, then GDB needs to punt.
The only way a tail call could h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #7 from Andrew Pinski ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
>
> That depends on the platform ABI. On some arches, including x86/x86_64 and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.
There is ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #4 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #3)
> What is done on other arches?
That depends on the platform ABI. On some arches, including x86/x86_64 and
arm/aarch64, the ABI requires the generated code relo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #3 from Jakub Jelinek ---
What is done on other arches? I mean the situation is basically the same on
x86_64,
where the artificial return value pointer argument is spilled early, then
clobbered
on calls and again b debug info is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #2 from Jakub Jelinek ---
I think there are several open PRs about var-tracking at -O0, which would be
nice e.g. for VLAs. The main problem is that var-tracking is very expensive,
so if we do it, it should track a very small subset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-03
Ever confirmed|0
10 matches
Mail list logo
