A possible code generation issue

[Dibyendu Majumdar]

On 4 July 2015 at 23:09, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> 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.
>>
>>
>> Of course, it could well be a bug at my end.
>>

Dave,

Attached is a hacked version in C of the dump from the code. I thought
it might be useful to generate code directly using gcc -O3 -S on this
file - from what I can tell the generated code looks different from
what I am getting in libgccjit.

BTW the dump of types is problematic in many ways:
1) types are in wrong order
2) function types are incorrectly output
3) array types are incorrectly output
4) in one case as least a pointer was missing.

It would be useful if the generated dump was correct C so that it can
directly compiled in gcc.

Thanks and Regards
Dibyendu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.c
Type: text/x-csrc
Size: 12320 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/jit/attachments/20150101/45965284/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.s
Type: application/octet-stream
Size: 1959 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/jit/attachments/20150101/45965284/attachment.obj>