https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #32 from Alexander Monakov ---
Ranger ICE is PR 109841 (reduced so it doesn't need LTO).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #31 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #28)
> "To put it simply, operator delete for class User inspects memory of the
> object after the end of its lifetime. This shows as a use-after-dtor error
> when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #30 from Xi Ruoyao ---
https://reviews.llvm.org/D150505.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #29 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #28)
> (In reply to Alexander Monakov from comment #21)
> > (In reply to Xi Ruoyao from comment #18)
> > > Maybe. Should we send a patch?
> >
> > Yes, if we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #28 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Xi Ruoyao from comment #18)
> > Maybe. Should we send a patch?
>
> Yes, if we have a volunteer.
I'm creating it, but from the description of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #27 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #26)
> Would that help? GCC raises its own stack limit to 64MB:
>
> gcc.cc: stack_limit_increase (64 * 1024 * 1024);
> toplev.cc: stack_limit_increase (64 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #26 from Alexander Monakov ---
Would that help? GCC raises its own stack limit to 64MB:
gcc.cc: stack_limit_increase (64 * 1024 * 1024);
toplev.cc: stack_limit_increase (64 * 1024 * 1024);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #25 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #24)
> Appreciate the advice. So far I've managed to reduce the number of LTO
> inputs down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also
> built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #24 from Alexander Monakov ---
Appreciate the advice. So far I've managed to reduce the number of LTO inputs
down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also built
gcc-12.3 with lineinfo and have a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Andrew Pinski changed:
What|Removed |Added
Keywords|wrong-code |ice-on-valid-code
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #22 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #19)
> It would be really nice to have the ranger bug fixed. Since lifetime
> DSE is all handled in C++ FE there is no good reason why it should not
> work to LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #21 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #18)
> Maybe. Should we send a patch?
Yes, if we have a volunteer.
> If I read the LLVM code correctly, -fno-strict-aliasing is enabled for
> Clang, but not other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #20 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #19)
> > > Is there any need to over-engineer this like that? I would hope enabling
> > > -fno-lifetime-dse globally would not be controversial for LLVM
>
> It would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #19 from Jan Hubicka ---
> > Is there any need to over-engineer this like that? I would hope enabling
> > -fno-lifetime-dse globally would not be controversial for LLVM
It would be really nice to have the ranger bug fixed. Since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #18 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #12)
> Is there any need to over-engineer this like that? I would hope enabling
> -fno-lifetime-dse globally would not be controversial for LLVM
Maybe. Should we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #17 from Alexander Monakov ---
Right, thanks, I think SUSE build log confirms that (careful, large file):
https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/llvm16/_log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #16 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #14)
> (In reply to Jan Hubicka from comment #13)
> > Indeed it is quite long time problem with clang not building with lifetime
> > DSE and strict aliasing. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #15 from Jan Hubicka ---
> > Indeed it is quite long time problem with clang not building with lifetime
> > DSE and strict aliasing. I wonder why this is not fixed on clang side?
>
> Because the problems were not communicated? I
> > Indeed it is quite long time problem with clang not building with lifetime
> > DSE and strict aliasing. I wonder why this is not fixed on clang side?
>
> Because the problems were not communicated? I knew that Firefox needed
> -flifetime-dse=1, but it's the first time I hear that any such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #14 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #13)
> Indeed it is quite long time problem with clang not building with lifetime
> DSE and strict aliasing. I wonder why this is not fixed on clang side?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #12 from Alexander Monakov ---
That would not fix the problem, lifetime-dse affects code that creates 'class
User' objects, not the implementation of its 'operator new' override.
(also the linked bug says "MDNode has the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #11 from Xi Ruoyao ---
Is it supported to use different -flifetime-dse settings for TUs when LTO is
enabled? If yes we can submit a LLVM change to add -flifetime-dse=1 for
User.cpp.o and mark this MOVED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #10 from Alexander Monakov ---
Indeed, that makes things easier, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #8 from Alexander Monakov ---
Ah, forgot to mention that compiler the offending User.cpp without -flto also
avoids the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #7 from Alexander Monakov ---
This problem seems to go way back. I'm told even gcc-9 broke LLVM like that.
For my investigation, I took latest gcc-11 snapshot and llvm-13.0.1.
My conclusion that it is a lifetime-dse violation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #5 from Immolo ---
How would I go about creating a reduce for this as I'd assume it's to with
running something llvm-reduce with
`/var/tmp/portage/sys-libs/compiler-rt-sanitizers-15.0.0/work/compiler-rt/lib/sanitizer_common/..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-09-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #3 from Immolo ---
I just rebuilt to test and yes it does still fail with the graphite flags
disabled with the same warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #2 from Andrew Pinski ---
Does it happen it you don't build with -fgraphite-identity
-floop-nest-optimize ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #1 from Immolo ---
https://github.com/llvm/llvm-project/issues/57740
34 matches
Mail list logo
