https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0f4588141fcbe4e0f1fa12776b47200870f6c621
commit r12-60-g0f4588141fcbe4e0f1fa12776b47200870f6c621
Author: Jakub Jelinek
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a21f3b38c3b9a5c28c79be37b040e7d06d827d76
commit r11-8281-ga21f3b38c3b9a5c28c79be37b040e7d06d827d76
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|uros at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #8 from Jakub Jelinek ---
I think there are 8 those peephole2s rather than just 4 (I've been looking for
rtx_equal_p (XEXP.*, 0) in sync.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> I think there are 8 those peephole2s rather than just 4 (I've been looking
> for
> rtx_equal_p (XEXP.*, 0) in sync.md
No, the other are not problematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > I think there are 8 those peephole2s rather than just 4 (I've been looking
> > for
> > rtx_equal_p (XEXP.*, 0) in sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #11 from Uroš Bizjak ---
Jakub, do these two patches fix your failures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #12 from Jakub Jelinek ---
They do. Though, in the combined patch I'm still a little bit worried about
the first 4 modified peephole2s, the last 4 look good to me.
The last 4 are where the original insn did a normal DFmode store and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> They do. Though, in the combined patch I'm still a little bit worried about
> the first 4 modified peephole2s, the last 4 look good to me.
> The last 4 are wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #14 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #13)
> DFmode loads and stores *are* atomic, this is what the optimization is based
> on.
Loads and stores to/from x87 and SSE registers, to be clear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #15 from Jakub Jelinek ---
Yes, but do they preserve all the bits and never modify any bit patterns,
including qNaNs and sNaNs? I thought the point of using the fistp was that it
preserves everything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Yes, but do they preserve all the bits and never modify any bit patterns,
> including qNaNs and sNaNs? I thought the point of using the fistp was that
> it pres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > Yes, but do they preserve all the bits and never modify any bit patterns,
> > including qNaNs and sNaNs? I though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #18 from Jakub Jelinek ---
Indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #19 from Jakub Jelinek ---
Perhaps best would be to try to construct a testcase for each of the peephole2s
and try some bit pattern that isn't preserved through the FPU except for
fistp/fildp and see what enabling/disabling each of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Attachment #50649|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #22 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d2324a5ab3ff097864ae6828cb1db4dd013c70d1
commit r12-91-gd2324a5ab3ff097864ae6828cb1db4dd013c70d1
Author: Uros Bizjak
Date: Fri Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #23 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:c03f3077b1517a01c917f75179100f9d10b39156
commit r11-8313-gc03f3077b1517a01c917f75179100f9d10b39156
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #24 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:39e8bfe7217898e8d21bcc55efe6992fbde262f1
commit r10-9775-g39e8bfe7217898e8d21bcc55efe6992fbde262f1
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #25 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:be20ca1d4ff79baf7425a48bb887495e1ea8f788
commit r9-9472-gbe20ca1d4ff79baf7425a48bb887495e1ea8f788
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #26 from CVS Commits ---
The releases/gcc-8 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0d277114b4b2d0cb386c7abe409a81ca29d9d61d
commit r8-10926-g0d277114b4b2d0cb386c7abe409a81ca29d9d61d
Author: Uros Bizjak
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #29 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #28)
> 29_atomics/atomic_ref/wait_notify.c has the same issue on Linux/x86-64 with
> -m32:
Are you sure? The mentioned peephole2 patterns now emit only x87 or SSE DFmode
loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #30 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #29)
> (In reply to H.J. Lu from comment #28)
> > 29_atomics/atomic_ref/wait_notify.c has the same issue on Linux/x86-64 with
> > -m32:
>
> Are you sure? The mentioned peeph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #31 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #30)
> (In reply to Uroš Bizjak from comment #29)
> > (In reply to H.J. Lu from comment #28)
> > > 29_atomics/atomic_ref/wait_notify.c has the same issue on Linux/x86-64
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #32 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:6d4da4aeef5b20f7f9693ddc27d26740d0dbe36c
commit r12-2407-g6d4da4aeef5b20f7f9693ddc27d26740d0dbe36c
Author: Uros Bizjak
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #33 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f2060ae92f22e4877af21018cf3b8cc2eca4745e
commit r11-8783-gf2060ae92f22e4877af21018cf3b8cc2eca4745e
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #34 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:ff3a8cd277752fd6167c39c00391662e47f1d1c0
commit r10-9992-gff3a8cd277752fd6167c39c00391662e47f1d1c0
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #35 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:5972907bd0528a04eb8fa4f9897714724da53f04
commit r9-9634-g5972907bd0528a04eb8fa4f9897714724da53f04
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #37 from H.J. Lu ---
I still see 32-bit test hang at random on Skylake server:
(gdb) bt
#0 0xf7fc655d in __kernel_vsyscall ()
#1 0xf7bac46b in syscall () from /lib/libc.so.6
#2 0x0804995d in std::__detail::__platform_wait (
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #38 from H.J. Lu ---
This time is 29_atomics/atomic_ref/wait_notify.cc in 64-bit on Skylake server:
(gdb) bt
#0 0x7f897288cc1d in syscall () from /lib64/libc.so.6
#1 0x004018be in std::__detail::__platform_wait (
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #39 from Uroš Bizjak ---
Please open a new bugreport, failures in Comment 37 and Comment 38 have nothing
with r7-1112-gbeed3701c796842abbfb27d7484b35bd82818740 which was fully
reverted.
(FTR, fixed peepholes were ineffective, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #40 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #39)
> Please open a new bugreport, failures in Comment 37 and Comment 38 have
> nothing with r7-1112-gbeed3701c796842abbfb27d7484b35bd82818740 which was
> fully reverted.
>
36 matches
Mail list logo
