https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85600
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=85600
--- Comment #6 from rdapp at linux dot ibm.com ---
This hunk causes the double pop():
@@ -4650,8 +4648,6 @@ build_delete (tree otype, tree addr,
special_function_kind auto_delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
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=89123
--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 45621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45621=edit
Tentative patch for libgo on s390x
I didn't manage to make much progress with analyzing the remain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277
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=89123
--- Comment #11 from rdapp at linux dot ibm.com ---
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #7 from rdapp at linux dot ibm.com ---
I did a full debug build of libgo and noticed that this changes the behavior of
the executable. When it would segfault with default -O2 before, it now seems
to rapidly allocate gigabytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #5 from rdapp at linux dot ibm.com ---
I performed a bisect using const-1.go as check and got the following likely
culprit:
b0751b120f1b83d8e48a7c2cac831aabbb0bc048 is the first bad commit
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
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=89123
--- Comment #9 from rdapp at linux dot ibm.com ---
Thanks for the pointer, I implemented the functions and now the startup seems
to be fully functional again. I'm still checking whether the remaining 50ish
libgo test suite failures I see are due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #4 from rdapp at linux dot ibm.com ---
Would this be ok?
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
index 44d85c04bfb..0d83384cd0a 100644
--- a/gcc/testsuite/gcc.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #8 from rdapp at linux dot ibm.com ---
> Yes, I think so.
Is this an OK to commit? :)
I checked it on s390 and x86_64 with -m64 and -m31/-m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #6 from rdapp at linux dot ibm.com ---
(In reply to Uroš Bizjak from comment #5)
> This approach is not OK, you should use lp64 effective target instead of
> -m64 option. Please see many examples in testsuite/gcc.dg.
>
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #3 from rdapp at linux dot ibm.com ---
This fails a lot more than it should. I'm looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
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=91628
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=91628
--- Comment #9 from rdapp at linux dot ibm.com ---
(In reply to Florian Weimer from comment #8)
> Calling functions from inline assembly is always a bit iffy. For example,
> your code lacks clobbers for the vector registers (if p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #13 from rdapp at linux dot ibm.com ---
Created attachment 46859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46859=edit
__tls_get_offset in separate .S files
As there were no further remarks as to which version is prefer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #15 from rdapp at linux dot ibm.com ---
Any feedback on the two options I proposed? Is the .S file variant (I posted
last) ok?
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at linux dot ibm.com
Target Milestone: ---
Since g:d846f225c25c5885250c303c8d118caa08c447ab we create an epilog loop on
s390 for the following test case:
/* { dg-do compile } */
/* { dg-options "-O3 -m
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=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=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=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
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=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=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
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 #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=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=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 #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
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=edit
Tentative patch
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) &&
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
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
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=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
--- 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
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=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
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
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=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=104026
--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52192=edit
Proposed patch
Could you try the proposed patch? Bootstraps cleanly for me and no regressions
on Po
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
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
47 matches
Mail list logo
