https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #10 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:d0d4601ccde3c4849f6e7244035f1a899d608cb7
commit r12-7114-gd0d4601ccde3c4849f6e7244035f1a899d608cb7
Author: Robin Dapp
Date: Tue Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #9 from Stafford Horne ---
Note, I said glibc but of course error I listed was when compiling gcc during
glibc toolchain building.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Stafford Horne changed:
What|Removed |Added
CC||shorne at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #7 from Jeffrey A. Law ---
Sorry, I wasn't able to debug those additional failures until the weekend.
They ultimately turned out to be a bug in some recent newlib refactoring. I
got clean or1k builds once I applied your patch and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #6 from rdapp at linux dot ibm.com ---
One thing wrong with the previous snippet is that cc_cmp and rev_cc_cmp can be
NULL. This can also be the reason for your failures as seen on SPARC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #5 from rdapp at linux dot ibm.com ---
I would speculate that some of the FAILs are due to the same problem seen in
the other PR (104198), i.e. that for the second seq I wrongly assumed that the
backend does not recreate the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #4 from Jeffrey A. Law ---
That seems to get newlib building. But I'm also seeing a ton of testsuite
failures. Not sure what's going on with those yet. I'll have to make some
time tomorrow to look at them a bit deeper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-24
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #3 from rdapp at linux dot ibm.com ---
Both of your guesses are correct :) or1k_expand_compare () indeed modifies the
condition/comparison in-place. As I use cc_cmp directly from the condition of
the jump it is changed but never rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #2 from Jeffrey A. Law ---
I'd bet the or1k expanders are changing the passed-in RTL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #1 from rdapp at linux dot ibm.com ---
I was able to reproduce the ICE on a cross compiler. Curiously, we do not even
succeed with if-conversion here but nevertheless emit an insn
(jump_insn 78 9 79 6 (set (pc)
(if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--
14 matches
Mail list logo
