https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #19 from John Paul Adrian Glaubitz ---
(In reply to Sam James from comment #18)
> See https://github.com/llvm/llvm-project/pull/111995 which fixes a problem
> that bisected to the same commit on ppc32.
Yes, I can confirm that this p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Sam James changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #17 from John Paul Adrian Glaubitz ---
(In reply to Sam James from comment #16)
> glaubitz, could you check with gcc-14.2 or trunk? I have a feeling honza's
> IPA fixes recently sort this.
No improvement here, unfortunately. clang s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #16 from Sam James ---
glaubitz, could you check with gcc-14.2 or trunk? I have a feeling honza's IPA
fixes recently sort this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #15 from Segher Boessenkool ---
(In reply to Jessica Clarke from comment #8)
> The clang/ subdirectory should be building itself with -fno-strict-aliasing
> on GCC already
"Should". I guess you mean "is", as in "we already conclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #14 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #7)
> This code gives me strict aliasing violation vibes:
> ```
> T **getAddressOfPointer(ExternalASTSource *Source) const {
> // Ensure the integer is in po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #7)
> `-fno-lifetime-dse` is already used but I get the feeling there might be
> strict aliasing issues in the code though. What happens if you add
> -fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #11 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Kewen Lin from comment #9)
> > Since it's a breakage during stage2, it's concluded that some built stage1
> > stuffs behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Kewen Lin from comment #9)
> Since it's a breakage during stage2, it's concluded that some built stage1
> stuffs behave unexpectedly. You probably can try to run regression testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #8 from Jessica Clarke ---
The clang/ subdirectory should be building itself with -fno-strict-aliasing on
GCC already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #7 from Andrew Pinski ---
`-fno-lifetime-dse` is already used but I get the feeling there might be strict
aliasing issues in the code though. What happens if you add
-fno-strict-aliasing ?
This code gives me strict aliasing violati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #6 from Andrew Pinski ---
The backtrace in the llvm bug report is not very useful either.
Maybe look into that first to see if it is obvious which function might be
compiling "incorrectly". Maybe there is a bug in the new clang code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #5 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> (In reply to Segher Boessenkool from comment #2)
> > We need a reduced testcase.
>
> Any suggestion on how to proceed here?
Nothing in particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #4 from Andrew Pinski ---
I should mention that LLVM has/had known issues with -flifetime-dse so it might
be useful also to show how stage1 of LLVM/clang was being built.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #1)
> This could still be a bug in LLVM too.
>
> Without much more information, it is hard to decide.
I fully agree. I filed this bug report to broaden t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #2 from Segher Boessenkool ---
We need a reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
20 matches
Mail list logo
