A possible code generation issue

[Dibyendu Majumdar]

On 4 July 2015 at 22:41, David Malcolm <dmalcolm@redhat.com> wrote:
>> Adding the -fno-strict-aliasing appears to resolve the issue with -O2
>> and -O3 but with this enabled the benchmarks are degraded.
>
> If "-fno-strict-aliasing" resolved this, then that suggests that there
> are various casts in the code that if this were C would take us into
> "undefined behavior" territory, and the optimizer is trying a little too
> hard.   This isn't C, but similar rules apply.  If that's what this is,
> then this is at least a documentation issue with libgccjit; we need to
> document what the rules are.
>
> If this is the case it's normally possible to work around it in C by
> rewriting casts using unions.

I guess if you can help me work out which bit of code is causing a
problem then I can implement a fix.

>
> Of course, it could well be a bug at my end.
>
> In any case, I'm not going to be able to have a proper look at this
> until Monday (it's the July 4th holiday weekend here in the US); sorry.
>

No problem - Monday is fine. I have nearly implemented all the Lua
bytecodes that I have working in LLVM only a few left to do.

Regards
Dibyendu