https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #13 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:75c4e4909ae2667f56487434f99c2915b4570794
commit r13-764-g75c4e4909ae2667f56487434f99c2915b4570794
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Wilco changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #12 from Wilco ---
(In reply to Jakub Jelinek from comment #11)
> How can changing the constructor priority in libgcc affect anything?
> Constructor priorities are within the same shared library or within the same
> executable, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
roc at ocallahan dot org changed:
What|Removed |Added
CC||roc at ocallahan dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #8 from Andrew Pinski ---
Oh one more note, the performance of the initialization code is going to be
very minor. So fixing this won't change the overall performance.
This is again a minor issue and you still might end up with LL/SC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #7 from Keno Fischer ---
I'm probably talking in circles at this point, but let me try just one more
time. I just want to clarify that I understand that this is not technically a
libgcc bug. But it's not really an rr bug either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #6 from Andrew Pinski ---
Again the bug is still in RR and RR should figure out a better way of fixing
this. If RR wants to support aarch64, they need to fix their code. I am sorry
but ARMv8-a requires ll/sc and any code which uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #5 from Keno Fischer ---
Yes, rr cannot record ll/sc. I'm happy to go into depth here, but this is not
really an aarch64 issue. rr doesn't work on ppc64le either for this reason. The
introduction of lse has made rr feasible on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #4 from Andrew Pinski ---
rr needs to be able to emulate ll/sc really. If it can't then there is not much
GCC can do because again people can and do use both in their programs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #3 from Keno Fischer ---
> I am going to close it as won't fix as the problem is with the rr emulator
> which needs to emulate ll/sc for correctness.
No currently shipping aarch64 chip provides hardware support that would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #2 from Andrew Pinski ---
There is no correctness issue here either since the check for atomics always
fall back to ll/sc style atomics if init_have_lse_atomics has not been run.
Once init_have_lse_atomics runs then it will use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
15 matches
Mail list logo
