https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #7 from rdapp at linux dot ibm.com ---
The patch fixes the problem for me. I did a full bootstrap with enabled
len_load support. No new regressions with -march=arch14. Thanks again!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
--- Comment #2 from rdapp at linux dot ibm.com ---
I did not get back to this until now. The patch works, of course and a
testsuite run looks good so far. I assume we're too late in the cycle to still
get this in, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #7 from rdapp at linux dot ibm.com ---
This
diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
index 8cc173519ab..e9ea90631a2 100644
--- a/gcc/config/arc/arc.cc
+++ b/gcc/config/arc/arc.cc
@@ -2254,6 +2254,8 @@ gen_compare_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #7 from rdapp at linux dot ibm.com ---
Sorry for not getting back to this earlier, talked to Segher off-list about
this quickly.
>> The check
>>
>> if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))
>
> With compare_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #6 from rdapp at linux dot ibm.com ---
Created attachment 52406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52406&action=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #3 from rdapp at linux dot ibm.com ---
Power(10) also saw a similar problem where the backend was not prepared to
handle what we are passing now. I'm starting to become a bit concerned now
that more backends might (latently) not be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #2 from rdapp at linux dot ibm.com ---
Yes, your guess was right again. We ICE here:
gcc_assert (cmode == SImode || cmode == SFmode || cmode == DFmode);
but cmode == E_CCmode with the patch.
This already helps and the resulting seq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #1 from rdapp at linux dot ibm.com ---
Strange, I didn't receive a mail/notification for this PR all, otherwise I
would have looked into it earlier. This has been happening a few times lately,
grml. Looking into it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #4 from rdapp at linux dot ibm.com ---
Hi Segher,
originally ifcvt would only pass e.g.
(unle (reg:SF 129 [ _29 ])
(reg/v:SF 118 [ highScore ]))
as condition to rs6000_emit_cmove via emit_conditional_move (). (This is the
exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
--- Comment #15 from rdapp at linux dot ibm.com ---
Testsuite is same as before the original patch now. Going to post a patch to
the mailing list later.
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=104198
--- Comment #14 from rdapp at linux dot ibm.com ---
Ok, this is triggered by the copy_rtx I introduced for the or1k failure:
+ rtx rev_cc_cmp = copy_rtx (cond_exec_get_condition (jump, /* get_reversed */
true));
because copy_rtx is called with
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=104198
--- Comment #13 from rdapp at linux dot ibm.com ---
I was away for some days, going to look into this again today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52297&action=edit
Tentative patch
I now have something that successfully bootstraps on s390x, PowerPC and SPARC
but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
--- Comment #9 from rdapp at linux dot ibm.com ---
I believe I know what's happening and it's indeed something that could also
happen on other targets.
I did not anticipate backends re-creating the initial condition for the case
when we pass it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
--- Comment #8 from rdapp at linux dot ibm.com ---
One of the s390-"specific" execution testcases fails on SPARC using the wrong
order of operands. I'm pretty sure this is the problem. Going to investigate
further.
Seeing this, it might make se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
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 #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=104026
--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52192&action=edit
Proposed patch
Could you try the proposed patch? Bootstraps cleanly for me and no regressions
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104026
--- Comment #8 from rdapp at linux dot ibm.com ---
I think you're right. In one of the last iterations of the patch I moved
+ LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) = partial_load_bias;
after the unsupported check. It is now only se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104026
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
--- Comment #5 from rdapp at linux dot ibm.com ---
git bisect bad5f6a6c91d7c592cb49f7c519f289777eac09bb74 is the first bad commit
commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74
Author: Richard Earnshaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
Bug ID: 100756
Summary: vect: Superfluous epilog created on s390x
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
28 matches
Mail list logo
