From: David Malcolm <dmalcolm@redhat.com>
To: Dibyendu Majumdar <mobile@majumdar.org.uk>
Cc: jit@gcc.gnu.org
Subject: Re: Filed PR jit/66812 for the code generation issue
Date: Thu, 01 Jan 2015 00:00:00 -0000 [thread overview]
Message-ID: <1436469387.24803.150.camel@surprise> (raw)
In-Reply-To: <1436403792.24803.112.camel@surprise>
On Wed, 2015-07-08 at 21:03 -0400, David Malcolm wrote:
> On Wed, 2015-07-08 at 22:54 +0100, Dibyendu Majumdar wrote:
> > Apologies I think the previous description of the flow was incorrect.
> > Here is my second attempt (this is doing my head in so I will stop
> > now):
>
> [snip detailed analysis of bytecode]
>
> Thanks.
>
> So it's basically:
>
> * do a bunch of stuff
> * then set R(1) to boolean false in that last LOADBOOL op
> * then return
>
>
> > 12 [3] LOADBOOL 1 0 0
> >
> > (&L->ci->u.l.base[(int)1])->value_.b = (int)0;
> > (&L->ci->u.l.base[(int)1])->tt_ = (int)1;
> >
> > Above sets the register 1 to false and this is the return value.
>
> I've been poring over the dumps:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/
> and I believe the problem is in pass "fre1"; it's eliminating this
> statement for some reason:
> (&L->ci->u.l.base[(int)1])->value_.b = (int)0;
>
> so
> R1.tt_ = 1 (correct)
> but:
> R1.value_.i = K0.value_.i (incorrect, is int 10, not 0)
>
> The statement is still present at pass 034t.ealias:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.034t.ealias
>
> but is optimized away in pass 035t.fre1:
> https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.035t.fre1
>
> I'll have a more detailed look tomorrow at why fre1 is getting it wrong.
>
> [snip]
I've managed to create a minimal reproducer for this; see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812
where libgccjit miscompiles it, but the C frontend (cc1) handles the
equivalent C code just fine (even at -O3, without needing
-fno-strict-aliasing).
So the next step seems to be to step through the fre1 pass in both
libgccjit and in cc1, and to see what's different.
Yay, progress!
Dave
next prev parent reply other threads:[~2015-07-09 19:24 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-01 0:00 A possible " Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Filed PR jit/66812 for the " David Malcolm
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` [PATCH] PR jit/66812: Candidate fix for for the code generation issue, v1 David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Filed PR jit/66812 for the code generation issue Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` David Malcolm [this message]
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` A possible " David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Filed PR jit/66811: jit jumps aren't compilable as C (Re: A possible code generation issue) David Malcolm
2015-01-01 0:00 ` Filed PR jit/66811: jit dumps " David Malcolm
2015-01-01 0:00 ` A possible code generation issue Dibyendu Majumdar
2015-01-01 0:00 ` PR jit/66783 (Re: A possible code generation issue) David Malcolm
2015-01-01 0:00 ` [PATCH, committed] PR jit/66783: prevent use of opaque structs David Malcolm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1436469387.24803.150.camel@surprise \
--to=dmalcolm@redhat.com \
--cc=jit@gcc.gnu.org \
--cc=mobile@majumdar.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).