https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #7 from Alexander Monakov ---
I wanted to understand what gets exposed in LTO mode that causes a blowup.
I'd say flatten is not appropriate for this function (I don't think you want to
force inlining of memset or _find_next_bit?), s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #6 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #5)
> I mean now, about compile time blowup with LTO.
No, LTO is not supported by upstream (yet) ;).
The point is what should I do when submitting the LTO support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #5 from Alexander Monakov ---
(In reply to Jiri Slaby from comment #4)
> > I am surprised that "flatten" blows up on this function. Is that with any
> > config, or again some specific settings like gcov? Is there an existing lkml
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #4 from Jiri Slaby ---
(In reply to Alexander Monakov from comment #3)
> It was added to force inlining of small helpers that outgrow limits when
> building with gcov profiling:
(with clang)
> I am surprised that "flatten" blows up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #2 from Richard Biener ---
The whole point of "flatten" is that there's _no_ limit. Looking at the
function I don't see why you'd ever use that?
If the desire is to force inlining a specific call then I think there's
currently
no g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-09-23
Status|UNCONFIRME
