On 14/04/2020 19:28, Michael Felt wrote:
> Michael Felt <aixtools@felt.demon.nl> added the comment:
>
> On 14/04/2020 14:54, Batuhan Taskaya wrote:
>> Batuhan Taskaya <batuhanosmantaskaya@gmail.com> added the comment:
>>
>>> With the print statements - it does not crash:
>> I think this isn't directly relevant with prints but about re-compiling? (just guessing).
> I only recompiled the one .c file. With that one file re-compiled -
> wqith fprintf statements it succeeds, restore the original .c file (git
> checkout -- Objects/whatever.c; make - it fails.
>
> Tomorrow I'll search for the option(s) needed to get (complete) assembly
> code listing and try to see (and understand) the difference between what
> xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile
> only this one file using xlc-v13 and see if the make then proceeds normally.
>
>
Many pages of output - and I confess - I do have some difficulty reading
code every now and then.

As the "bug" wherever it may be is related, I am guessing, to compiler
optimization and how to deal with routines with "no return".

Trying to understand the listings - I ran across:

./Include/object.h:typedef void (*destructor)(PyObject *);

Could the error be related to compilers confusing a routine with no
return, versus a routine returning a pointer to a "void"?

recall the code:

static void
gen_dealloc(PyGenObject *gen)

Comments?

Michael

> As Victor commented earlier - very much looking like a compiler bug.
> That said, still do not know what to say/write to software support as a
> complaint.
>
>> ----------
>>
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <https://bugs.python.org/issue40244>
>> _______________________________________
>>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue40244>
> _______________________________________
>