https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #29 from Sam James ---
It wasn't clear to me if your case was fixed (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416#c23) or if it needed
reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #28 from Paul Eggert ---
Thanks for the fix. I updated Emacs to no longer work around the bug when GCC
15+ is being used, here:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3d1d4f109ed4115256a08c74eeb704259d91c9f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Known to work||15.0
--- Comment #27 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #26 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f577959f420ae404f99f630dadc1c0370734d0da
commit r15-3070-gf577959f420ae404f99f630dadc1c0370734d0da
Author: Martin Jambor
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #25 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6ed6kntue@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Martin Jambor changed:
What|Removed |Added
Attachment #58724|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #23 from Richard Biener ---
So it's from
return (struct form_time)
{
.form = TIMEFORM_HI_LO,
.time = decode_ticks_hz (specified_time, make_fixnum (1), cform)
};
with
union c_time
{
struct ticks_hz th;
struct t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #22 from Paul Eggert ---
(In reply to Richard Biener from comment #17)
> I suppose this happens even when building without LTO, so can you please
> attach preprocessed source of the TU containing decode_lisp_time
> (preprocessed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #21 from Paul Eggert ---
Created attachment 58740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58740&action=edit
Assembly-language illustrating wrong code
Here is the assembly language output (gzip compressed) of the wrong co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #20 from Paul Eggert ---
Created attachment 58739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58739&action=edit
preprocessed Emacs source code illustrating the bug
Here is the gzip-compressed text of the Emacs source code il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #18)
> (In reply to Martin Jambor from comment #15)
> > Created attachment 58724 [details]
> > simple (wip) fix
> >
> > I'm wondering whether just simply something l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #18 from Richard Biener ---
(In reply to Martin Jambor from comment #15)
> Created attachment 58724 [details]
> simple (wip) fix
>
> I'm wondering whether just simply something like this would not be enough.
> I have looked at total
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #17 from Richard Biener ---
(In reply to Paul Eggert from comment #16)
> (In reply to Richard Biener from comment #13)
> > Paul - can you test if this patch resolves the emacs issue?
>
> Unfortunately not. Although the generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #16 from Paul Eggert ---
(In reply to Richard Biener from comment #13)
> Paul - can you test if this patch resolves the emacs issue?
Unfortunately not. Although the generated code differs, it's still the same bad
pattern. GDB's comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #15 from Martin Jambor ---
Created attachment 58724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58724&action=edit
simple (wip) fix
I'm wondering whether just simply something like this would not be enough. I
have looked at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #14 from Richard Biener ---
(In reply to Richard Biener from comment #13)
> Created attachment 58718 [details]
> patch I am testing
>
> Paul - can you test if this patch resolves the emacs issue?
Using root->grp_same_access_path doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #13 from Richard Biener ---
Created attachment 58718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58718&action=edit
patch I am testing
Paul - can you test if this patch resolves the emacs issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #11 from Paul Eggert ---
(In reply to Richard Biener from comment #10)
> The remaining issue is analyzed to be caused by SRA so you can check whether
> -fno-tree-sra fixes it for you.
Thanks, it does, and I modified the Emacs 'config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #10 from Richard Biener ---
(In reply to akrl from comment #9)
> Hello,
>
> this is apparently affecting Emacs build as well [1].
> I there a suggested way we could work around this bug? Maybe a flag to
> prevent the optimization whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
akrl at gcc dot gnu.org changed:
What|Removed |Added
CC||akrl at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #8 from Andrew Pinski ---
(In reply to Richard Biener from comment #6);
>
> and the value re-interpretation goes off. Martin - we may have dups of this
> but SRA shouldn't do this (it possibly gets confused by the x.d store)?
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #7 from Richard Biener ---
Access trees for x (UID: 2479):
access { base = (2479)'x', offset = 0, size = 128, expr = x.d, type = long
double, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 16 Sep 2013, rguenth at gcc dot gnu.org wrote:
> It looks wrong for DFmode move instructions to not preserve a IEEE defined
> flag. I suppose it would be also wrong to not preserve t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #3 from Uroš Bizjak ---
(In reply to Richard Biener from comment #2)
> where *movdf_internal simply doesn't properly preserve sNaN.
>
> It looks wrong for DFmode move instructions to not preserve a IEEE defined
> flag. I suppose it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
--- Comment #2 from Richard Bie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #1 from H.J. Lu ---
This may be related to PR57484.
29 matches
Mail list logo
