https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #15 from CVS Commits ---
The releases/gcc-11 branch has been updated by Ilya Leoshkevich
:
https://gcc.gnu.org/g:445ce3cfb6832ec838caa10f2337c3bd00213517
commit r11-8360-g445ce3cfb6832ec838caa10f2337c3bd00213517
Author: Ilya
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #14 from CVS Commits ---
The master branch has been updated by Ilya Leoshkevich :
https://gcc.gnu.org/g:4f48c335d36674f90046b2823f0ac1c0545dc082
commit r12-379-g4f48c335d36674f90046b2823f0ac1c0545dc082
Author: Ilya Leoshkevich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #13 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #12)
> For valgrind, the quick workaround would be -march=z13 when compiling the
> s390x tests that have register long double variables.
Yes, this works, if fpext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #12 from Jakub Jelinek ---
For valgrind, the quick workaround would be -march=z13 when compiling the s390x
tests that have register long double variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #11 from Mark Wielaard ---
BTW. Disabling that test in valgrind produces another crash in another test
that looks similar:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include
-I../../../coregrind -I../../../include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.0|11.2
--- Comment #10 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #9 from Ilya Leoshkevich ---
Created attachment 50679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50679=edit
regtesting this patch now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #8 from Ilya Leoshkevich ---
Yeah, inline asm seems to be problematic:
/home/iii/gcc/build/gcc/xgcc -B/home/iii/gcc/build/gcc/
/home/iii/gcc/gcc/testsuite/gcc.target/s390/vector/long-double-asm-hardreg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #7 from Jakub Jelinek ---
That said, I'm afraid I don't really understand what wrong happens with the
patch I've attached.
Trying something like:
long double
foo (void)
{
register long double f0 asm ("f0");
f0 = 1.0L;
f0 +=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #6 from Jakub Jelinek ---
(In reply to Ilya Leoshkevich from comment #5)
> That would be an ideal solution, but I wonder how to implement it? Suppose
> we find a way to convince expand to pick FPRX2mode for such a long double.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #5 from Ilya Leoshkevich ---
That would be an ideal solution, but I wonder how to implement it? Suppose we
find a way to convince expand to pick FPRX2mode for such a long double. What if
the following comes up?
register long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #4 from Jakub Jelinek ---
That seems like quite undesirable API change.
Can't the backend when it sees long double register vars for the fN registers
change the mode from TFmode to that new FPRX2mode, so that old code keeps
working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #2 from Jakub Jelinek ---
Created attachment 50658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50658=edit
gcc11-pr100217.patch
Untested fix. IMHO when we have a hard reg in the inline asm, we just need to
honor it, trying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #1 from Jakub Jelinek ---
Bet the new s390_md_asm_adjust code is unprepared to see hard registers there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
Ever confirmed|0
18 matches
Mail list logo
