https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #3 from Lukas Grätz ---
(In reply to Marc Glisse from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am 99% sure this is falls under don't do this as flatten inlines
> > everything it can that the function calls ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #4 from Lukas Grätz ---
Sorry, just to clarify, whether I understood your two comments correctly.
Should foo() be inlined in the following example because flatten works
recursively?
void foo (void) {
// CODE
}
int bar_original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Bug ID: 111643
Summary: __attribute__((flatten)) with -O1 runs out of memory
(killed cc1)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111786
Bug ID: 111786
Summary: No tail recursion for simple program
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111786
--- Comment #3 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #1)
> We completely intentionally don't emit tail calls to noreturn functions, so
> that e.g. in case of abort one doesn't need to virtually reconstruct
> backtrace.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #9 from Lukas Grätz ---
Thanks for everything, it seemed to be a misunderstanding from my side anyway
and the documentation fix should help others.
I am sorry for being silent, I was sick for a few days. As for my original
problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #14 from Lukas Grätz ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Gcc does have tail call optimization which should allow the instrumentation
> > with less overhead. Though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #11 from Lukas Grätz ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Lukas Grätz from comment #9)
> > I also wondered whether
> >
> > int bar_alias (void) { return bar_original(); }
> >
> > could be a portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896
Bug ID: 111896
Summary: call with wrong stack alignment
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896
--- Comment #2 from Lukas Grätz ---
(In reply to Andrew Pinski from comment #1)
> No I think you are looking into the wrong location.
>
> When a call happens, it pushes a value on the stack aligning the stack that
> is incoming into that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896
--- Comment #5 from Lukas Grätz ---
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #18 from Lukas Grätz ---
On another thought: I think something like -fignore-backtrace could be a
reasonable optimization flag (enabled by default for -O4). By ignoring the
backtrace we could do other optimizations on size and speed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #17 from Lukas Grätz ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to gooncreeper from comment #15)
> > May I suggest we just add something like __attribute__((trace)) for the
> > special abort case? Noreturn was added for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #7 from Lukas Grätz ---
(In reply to H.J. Lu from comment #4)
> When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> most of C++ exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
Lukas Grätz changed:
What|Removed |Added
CC||lukas.graetz@tu-darmstadt.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #9 from Lukas Grätz ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #4)
> > > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #11 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++. I fixed it by
> keeping callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #12 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++. I fixed it by
> keeping callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #13 from Lukas Grätz ---
(In reply to Lukas Grätz from comment #12)
> CODE, uses loop unwinding functions
>a) restores all callee-saved registers in f3(), f2()
>b) restores %rsp and %rip from stack of f2()
I meant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #14 from Lukas Grätz ---
Never mind my above comments. I just realized that attribute nothrow has no
effect in C, unless -fexceptions. So nothrow is not needed (only
-fno-exceptions). Furthermore, most noreturn functions throw in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #27 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Lukas Grätz from comment #25)
> > (In reply to Jakub Jelinek from comment #19)
> > > (In reply to H.J. Lu from comment #18)
> > > > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #25 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Jakub Jelinek from comment #17)
> > > E.g. shouldn't it at least be disabled for -O0 and -Og and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #20 from Lukas Grätz ---
(In reply to Petr Skocik from comment #19)
> IMO(In reply to Xi Ruoyao from comment #16)
>
> > In practice most _Noreturn functions are abort, exit, ..., i.e. they are
> > only executed one time so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #29 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #31 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
> > trusted comment #10 here, as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #33 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #32)
> (In reply to Lukas Grätz from comment #31)
> > Even when I compile a simple program with gcc -O2 -g:
> >
> > #include
> > int main(int argc, char** argv) {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #14 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 57545 [details]
> gcc14-pr114116.patch
>
> This seems to fix it, so far tested just on the small testcase, back to the
> expected backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #13 from Lukas Grätz ---
(In reply to H.J. Lu from comment #12)
> (In reply to Lukas Grätz from comment #11)
> >
> > I applied it, double checked, make distclean, configure, make again.
> >
> > But your result seems different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #36 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #35)
> If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
> + .cfi_undefined 3
> + .cfi_undefined 12
> + .cfi_undefined 13
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #38 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.
I see, this gives me:
(gdb) frame 4
#4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #40 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > I belief this could and should be somehow be fixed by adding DWARF info that
> > certain callee-saved registers (=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114144
Bug ID: 114144
Summary: Variables optimized out by -Og
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #42 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #41)
> (In reply to Lukas Grätz from comment #40)
> > It seems that the reason for is ultimately -Og, not this
> > patch. See Bug 78685.
>
> No. When PR78685 would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #43 from Lukas Grätz ---
(In reply to Lukas Grätz from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> >
> > No. When PR78685 would be fixed by adding artificial hidden uses of
> > variables at the end of their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
Lukas Grätz changed:
What|Removed |Added
CC||lukas.graetz@tu-darmstadt.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #11 from Lukas Grätz ---
(In reply to H.J. Lu from comment #10)
> (In reply to Lukas Grätz from comment #9)
>
> >
> > Not on my computer. When I used -g I got:
> >
> >
> > no_return_to_caller:
> > .LFB0:
> > .loc 1 16 1 view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #9 from Lukas Grätz ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #6)
> > > (In reply to Jakub Jelinek from comment #5)
> > > > Yeah. Not to mention, one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #44 from Lukas Grätz ---
(In reply to Tom Tromey from comment #39)
> (In reply to Lukas Grätz from comment #36)
>
> > > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > > d=,
> > > e=, f= > > reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #45 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with
39 matches
Mail list logo
