Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]

[David Malcolm <dmalcolm@redhat.com>]

On Sun, 2020-07-12 at 20:30 -0400, Antoni Boucher via Jit wrote:
> Hello.
> 
> As mentioned in bug 95498, some conversions do not work. After 
> investigation, it turns out that it's caused by multiple casts on an 
> expression where it should do a truncation/extension.

Thanks for investigating this.

> I added a testcase, but for some reasons, the tests only pass when
> ran 
> via `./testsuite/jit/test-cast.c.exe`, not when ran via `make check-
> jit 
> RUNTESTFLAGS="-v -v -v  jit.exp=test-cast.c"`.

That's weird.

It sounds like you're following the instructions on 
https://gcc.gnu.org/onlinedocs/jit/internals/index.html#running-the-test-suite

If you're not specifying LD_LIBRARY_PATH, it might be that when you
run 
  ./testsuite/jit/test-cast.c.exe
directly that the version of libgccjit.so that the exe gets dynamically
linked against might not be the one you expect (e.g. a distribution-
provided libgccjit.so, rather than the one in your build
directory).  Maybe that explains the differences in behavior?  (or
maybe somehow "make check-jit" is using the wrong DSO???).  You could
try exporting LD_DEBUG=files (or somesuch) to get info on which
libgccjit.so is being used in each manner of invoking the test.

There are some notes at the URL above on how to run a test under gdb.

If all else fails, add some printfs and look at the output from "make
check-jit", and look at jit.sum and jit.log (though you don't specify
how the tests fail to pass when run that way)

> Furthermore, some other tests failed, but they also fail on master.

Which tests are failing for you?  (and for what configuration triplet?)

> Also, I was under the impression that adding `STRIP_TYPE_NOPS
> (t_expr);` 
> in `playback::context::build_cast` would be a better fix for this,
> but 
> that doesn't fix the issue.
> Am I missing something?

I'm not sure yet what the best fix would be.  In general I try to mimic
C behavior as much as is reasonable, but off the top of my head I'm not
sure what the C frontend does here.

> It's my first contribution to gcc, so I'd need help for fixing the
> tests 
> and also a confirmation that this is the best way to fix this issue.

Thanks for posting the patch; I hope the above is helpful
Dave