https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #25 from Aleksei Voitylov ---
(In reply to Richard Biener from comment #22)
> Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus
> if you manage to create a testcase for the testsuite failing before, passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #24 from rguenther at suse dot de ---
On Mon, 18 Nov 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
>
> --- Comment #23 from Wilco ---
> (In reply to Richard Biener from comment #22)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #23 from Wilco ---
(In reply to Richard Biener from comment #22)
> Fixed on trunk. Can arm people verify? I checked the DSE dump only. Bonus
> if you manage to create a testcase for the testsuite failing before, passing
> now.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #21 from Richard Biener ---
Author: rguenth
Date: Mon Nov 18 09:44:52 2019
New Revision: 278391
URL: https://gcc.gnu.org/viewcvs?rev=278391=gcc=rev
Log:
2019-11-18 Richard Biener
PR rtl-optimization/92462
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #20 from rguenther at suse dot de ---
On Fri, 15 Nov 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
>
> --- Comment #19 from Wilco ---
> > for this. Which "obviously" doesn't alias with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #19 from Wilco ---
(In reply to Richard Biener from comment #18)
> So I see before DSE1:
>
> (insn 16 15 17 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
> (const_int -8 [0xfff8])) [1 cur+0 S4 A64])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #17 from Aleksei Voitylov ---
(In reply to Andrew Pinski from comment #14)
> Have you tested gcc 7.5.0 that was just released? How about gcc 8.x? Have
> you tried that. There has been aliasing bugs in gcc before and this might
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #16 from Wilco ---
(In reply to Richard Biener from comment #15)
> I can't find PRE doing anything wrong and on 32bit x86_64 the testcase
> executes
> correctly with GCC 7.3 and GCC 9 (when I add the missing return to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #15 from Richard Biener ---
I can't find PRE doing anything wrong and on 32bit x86_64 the testcase executes
correctly with GCC 7.3 and GCC 9 (when I add the missing return to
Bar::cmpxchg).
So -ftree-pre, if it triggers a bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #14 from Andrew Pinski ---
Have you tested gcc 7.5.0 that was just released? How about gcc 8.x? Have you
tried that. There has been aliasing bugs in gcc before and this might already
been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Aleksei Voitylov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Aleksei Voitylov changed:
What|Removed |Added
Attachment #47260|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Aleksei Voitylov changed:
What|Removed |Added
Attachment #47212|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #10 from Alexander Monakov ---
> atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*
I made a typo here, I meant uint32_t rather than uint8_t, and there's no
aliasing violation here as signedness difference is explicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #9 from Aleksei Voitylov ---
(In reply to Alexander Monakov from comment #8)
> The full preprocessed source is provided and it clearly says
>
> typedef unsigned char uint8_t;
>
> in line 10, so it is in fact a character type.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Wilco changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #7 from Wilco ---
(In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #5 from Aleksei Voitylov ---
(In reply to Richard Biener from comment #3)
> Indeed -fno-strict-aliasing might be a workaround (apart from the atomicity
> issue). Also using a character type for the access (uint8_t is _not_ a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Aleksei Voitylov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #2 from Andrew Pinski ---
(In reply to Wilco from comment #1)
> Even if you fix the aliasing bugs, it won't emulate a byte-oriented cmpxchg
> correctly, there are bugs in the logic too.
More than that, it will never be atomic. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
25 matches
Mail list logo
