https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #17 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #16 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #15 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #14 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-g4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #13 from Andrew Pinski ---
Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
(lharx/sthcx.) instruction support was added (which was for Power8;
r0-123873-g4b02c96265fb52).
But that was 9 years ago.
Is powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #12 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #2)
> >Reason: 259 at address: 0x3109
>
> Yes that does seem like an alignment disagreement.
>
> I suspect the code is broken for allocation and it is allocati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #11 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #8)
> No preprocessed source of the code going wrong.
> Not even register state or instructions where the segfault is happening
> (this is would be very useful but n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #10 from Sergey Fedorov ---
Created attachment 53876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53876&action=edit
Preprocessed spinlock_test from 10.6
36-172% /opt/local/bin/g++-mp-11 --save-temps -v spinlock_test.cpp
-I/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #9 from Peter Dimov ---
The easiest way to reproduce the issue is with the following test:
https://github.com/boostorg/smart_ptr/blob/c577d68b0272fd0bddc88ea60a8db07219391589/test/spinlock_test.cpp
This crashes because - presumably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #8 from Andrew Pinski ---
(In reply to Peter Dimov from comment #7)
> I don't see an alignment requirement being mentioned here.
I think you misunderstood the alignment issue. There might be no alignment
requirement directly on __a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #6 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #5)
> I'm away from my usual sources of information but I'd suggest exploring the
> possibility that someone has assumed that either the spinlock or a bool is
> 8bits; A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #5 from Iain Sandoe ---
I'm away from my usual sources of information but I'd suggest exploring the
possibility that someone has assumed that either the spinlock or a bool is
8bits; As far as my memory serves both are 32b on power d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #4 from Andrew Pinski ---
(In reply to Sergey Fedorov from comment #3)
> > Also inside gdb can you do the following:
> >
> > disassemble $pc-0x10 $pc+0x10
> > info registers
>
> I could try that tomorrow, provided an ancient GBD we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #3 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #2)
> >Reason: 259 at address: 0x3109
>
> Yes that does seem like an alignment disagreement.
>
> I suspect the code is broken for allocation and it is allocatin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #2 from Andrew Pinski ---
>Reason: 259 at address: 0x3109
Yes that does seem like an alignment disagreement.
I suspect the code is broken for allocation and it is allocating unaligned
structs.
Also inside gdb can you do the fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
17 matches
Mail list logo
